< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/13d27b452d4b...67a359313f79
< bitcoin-git> bitcoin/master f2f2541 Sebastian Falbesoner: remove executable flag for src/net_processing.cpp
< bitcoin-git> bitcoin/master 67a3593 fanquake: Merge #21728: remove executable flag for src/net_processing.cpp
< bitcoin-git> [bitcoin] fanquake merged pull request #21728: remove executable flag for src/net_processing.cpp (master...2021-remove-exec-flag-from-net_processing) https://github.com/bitcoin/bitcoin/pull/21728
< bitcoin-git> [bitcoin] fanquake pushed 9 commits to master: https://github.com/bitcoin/bitcoin/compare/67a359313f79...a839303edc8a
< bitcoin-git> bitcoin/master 70cdf67 Kiminuo: Move StripRedundantLastElementsOfPath before ArgsManager class.
< bitcoin-git> bitcoin/master 1add318 Kiminuo: Move GetDataDir(fNetSpecific) implementation to ArgsManager.
< bitcoin-git> bitcoin/master 1cb52ba Kiminuo: Modify "util_datadir" unit test to not use gArgs.
< bitcoin-git> [bitcoin] fanquake merged pull request #21244: Move GetDataDir to ArgsManager (master...feature/2021-02-get-data-dir-args) https://github.com/bitcoin/bitcoin/pull/21244
< bitcoin-git> [bitcoin] ajtowns closed pull request #21378: Convert taproot to flag day activation (master...202103-taproot-flag-day) https://github.com/bitcoin/bitcoin/pull/21378
< aj> fanquake: ping re: #20353?
< gribble> https://github.com/bitcoin/bitcoin/issues/20353 | configure: Support -fdebug-prefix-map and -fmacro-prefix-map by ajtowns · Pull Request #20353 · bitcoin/bitcoin · GitHub
< fanquake> aj: good call. Will ACK/merge this arvo
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/a839303edc8a...de77cbc9d855
< bitcoin-git> bitcoin/master fad4167 MarcoFalke: test: Check that no versionbits are re-used
< bitcoin-git> bitcoin/master faec1e9 MarcoFalke: test: Address outstanding versionbits_test feedback
< bitcoin-git> bitcoin/master fa8eaee MarcoFalke: test: Run versionbits_sanity for all chains
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21691: test: Check that no versionbits are re-used (master...2104-testVersionbits) https://github.com/bitcoin/bitcoin/pull/21691
< wumpus> is the merge bot broken?
< wumpus> oh nm
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/de77cbc9d855...906ecb87c8c7
< bitcoin-git> bitcoin/master 84f3939 Pieter Wuille: Remove support for subdescriptors expanding to multiple scripts
< bitcoin-git> bitcoin/master a917478 Pieter Wuille: refactor: move population of out.scripts from ExpandHelper to MakeScripts
< bitcoin-git> bitcoin/master 4441c6f Pieter Wuille: Make DescriptorImpl support multiple subscripts
< bitcoin-git> [bitcoin] laanwj merged pull request #21238: A few descriptor improvements to prepare for Taproot support (master...202102_descriptor_prepare_taproot) https://github.com/bitcoin/bitcoin/pull/21238
< MarcoFalke> looks like ci is red
< MarcoFalke> There was a silent merge conflict
< MarcoFalke> script/descriptor.cpp:498:16: error: parameter 'script' not found in the function declaration [-Werror,-Wdocumentation]
< wumpus> strange, i did build locally
< MarcoFalke> Maybe Wdoc only works on a specific compiler?
< MarcoFalke> wumpus: Obviously not blaming you. It is impossible to find all silent merge conflicts.
< wumpus> my compiler (clang 13) does accept the flag, no idea if it does anything with it
< wumpus> right it's just that i try to be careful to avoid them by always running the build + tests locally, but definitely cannot do so for every platform / compiler combo
< wumpus> anyhow i'll do a PR...
< bitcoin-git> [bitcoin] laanwj opened pull request #21736: doc: Fix doxygen comment silent merge conflict in descriptor.cpp (master...2021-04-parameter-documentation) https://github.com/bitcoin/bitcoin/pull/21736
< wumpus> it looks like my compiler does have the warning enabled, it is just not fatal, i've had bad experiences with Werror in the past (due to divergence between compiler versions) but will try enabling --enable-suppress-external-warnings --enable-werror locally maybe it is better now
< aj> wumpus: those options work for me fwiw
< wumpus> aj: i don't doubt they work :) the problem is that the set of warnings very much differs between compilers, it is often that new gcc has some new warnings
< wumpus> or clang for that matter (thinking of the locking annotation warnings)
< aj> wumpus: yep
< wumpus> so it is not a guarantee in any case, there might be local failures due to this that do not arise in the CI and the other way around
< aj> wumpus i took the release cadence date stuff to be referring to 23.0 not 22.0 fwiw
< wumpus> let's discuss that at the time we are planning the 23.0 date then, that will only be after the 22.0 release
< aj> wumpus: yeah
< wumpus> definitely agree with the principle that planning a release around xmas is a bad idea
< wumpus> december tends to be a really quiet month in bitcoin dev
< MarcoFalke> yeah, it might be good to aim for October (or earlier) as a release month, as November might often delay into December
< MarcoFalke> Also branch-off right at the start of the new year might not be good either. Better wait till February (or later) to give reviewers some time to make up for the lack of review during December
< wumpus> october seems really early for 0.23?
< wumpus> or do you mean for 22, that doesn't make sense to me either (postpone it by two months?)
< MarcoFalke> Could aim for February 2022?
< MarcoFalke> No need to change the 0.22 timeline
< MarcoFalke> I think that is already set pretty much
< wumpus> feb for 0.23 that would make sense (but as said, let's discuss 0.23 timeline when we get there)
< MarcoFalke> sure, just wanted to mention that 0.22+6 months collides with December ;)
< fanquake> yea -Wdocumentation requires --enable-suppress-external-warnings to be enabled
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/906ecb87c8c7...572b36d4ff99
< bitcoin-git> bitcoin/master e5faec6 W. J. van der Laan: doc: Fix doxygen comment silent merge conflict in descriptor.cpp
< bitcoin-git> bitcoin/master 572b36d MarcoFalke: Merge bitcoin/bitcoin#21736: doc: Fix doxygen comment silent merge conflic...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21736: doc: Fix doxygen comment silent merge conflict in descriptor.cpp (master...2021-04-parameter-documentation) https://github.com/bitcoin/bitcoin/pull/21736
< MarcoFalke> reset all failed ci builds from the last two hours
< wumpus> harding: your taproot activation write-up seems very clear to me, i'll leave it on the wiki for a few days so people can make corrections if they think that is necessary, then add it to the release notes on the 0.21 branch
< bitcoin-git> [bitcoin] hebasto closed pull request #19213: util: Get rid of RecursiveMutex in Get{Blocks,Data}Dir (master...200608-path-mx) https://github.com/bitcoin/bitcoin/pull/19213
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21738: test: Use clang-12 for ASAN, Add missing suppression (master...2104-asan) https://github.com/bitcoin/bitcoin/pull/21738
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/572b36d4ff99...30a86bb814e3
< bitcoin-git> bitcoin/master de17d24 dplusplus1024: Re-add command to install vcpkg
< bitcoin-git> bitcoin/master 30a86bb MarcoFalke: Merge bitcoin/bitcoin#21733: build: Re-add command to install vcpkg
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21733: build: Re-add command to install vcpkg (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21733
< ShapeShifter499> hi
< ShapeShifter499> so I have a question about the client. I'm on linux and I'm wondering does it matter what Berkeley Database Bitcoin is compiled against if I want to recover old wallets?
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/30a86bb814e3...018045347110
< bitcoin-git> bitcoin/master db4d2c2 Jon Atack: cli: create AddrinfoRequestHandler class
< bitcoin-git> bitcoin/master 5056a37 Jon Atack: cli: add -addrinfo command
< bitcoin-git> bitcoin/master bb85cbc Jon Atack: doc: add cli -addrinfo release note
< bitcoin-git> [bitcoin] laanwj merged pull request #21595: cli: create -addrinfo (master...addressinfo) https://github.com/bitcoin/bitcoin/pull/21595
< wumpus> hebasto: sorry for only noticing this now in #21694 btw while i commented on the gitignore before :)
< gribble> https://github.com/bitcoin/bitcoin/issues/21694 | build: Use XLIFF file to provide more context to Transifex translators by hebasto · Pull Request #21694 · bitcoin/bitcoin · GitHub
< hebasto> wumpus: does this mean that src/qt/locale/bitcoin_en.xlf should be a part of the repo?
< wumpus> hebasto: if it is what you want transifex to read, yes
< hebasto> wumpus: thanks for explanation
< wumpus> e.g. the auto-update URL for 0.21.x right now in the transifex interface is : https://raw.githubusercontent.com/bitcoin/bitcoin/master/src/qt/locale/bitcoin_en.ts
< wumpus> oh i should change that to the branch
< wumpus> thanks for making me check, it is not good if it keeps updating from master and the translations diverge
< hebasto> wumpus: nice that everything is ok now
< wumpus> btw; do we still need bitcoin_en.ts *at all* now? i think its only goal was to provide it to transifex? or is it used for other things as well?
< wumpus> hmm i guess it is embedded in the binary but is effectively a no-op]
< hebasto> is it used to generate `bitcoin_en.qm` for `QObject::tr()`?
< hebasto> yes. in en_US locale it is no-op :)
< wumpus> that seems a very useless thing to do :) but sure it might anyway
< wumpus> but yeah, let's leave it like that for this PR, no need to touch that
< hebasto> ok
< wumpus> i hope we'll still get .ts translations back from transifex with tx pull
< hebasto> we'll find out :)
< wumpus> if not the maintainer-tools/update-translations.py script will need to convert too
< wumpus> we'll find out for 22.0 i suppose (no good reason to backport this)
< hebasto> agree
< bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/018045347110...90e0faaa442b
< bitcoin-git> bitcoin/master 2045e4c Hennadii Stepanov: build: Use XLIFF file to provide more context to Transifex translators
< bitcoin-git> bitcoin/master f959b75 Hennadii Stepanov: build: Add Qt lconvert tool to depends
< bitcoin-git> bitcoin/master 99686b6 Hennadii Stepanov: qt [experimental]: Add a translation comment and a disambiguation string
< bitcoin-git> [bitcoin] laanwj merged pull request #21694: build: Use XLIFF file to provide more context to Transifex translators (master...210415-xliff) https://github.com/bitcoin/bitcoin/pull/21694
< wumpus> btw we might want to do future translation-related changes in the gui repository
< hebasto> because they will touch the qt/ directory only?
< wumpus> yes, and because translation is only done for the GUI
< wumpus> i guess the exception is messages from bitcoind that get translated as well, but i mean changes that only affect src/qt sources yes
< hebasto> #21463, for example, is mixed qt and non-qt
< gribble> https://github.com/bitcoin/bitcoin/issues/21463 | doc: Address feedback from Transifex translator community by hebasto · Pull Request #21463 · bitcoin/bitcoin · GitHub
< wumpus> yes, agree
< jeremyrubin> Would anyone be opposed to adding an address type for OP_RETURN?
< jeremyrubin> I don't think they should be universally available, but it can be kind of annoying working in generic code that you can't get an address for an OP_RETURN output
< jeremyrubin> I guess this is better suited for mailing list...
< luke-jr> addresses define a recipient. OP_RETURN doesn't have a recipient.
< jeremyrubin> then why can I pay a P2SH OP_RETURN and that has an address?
< luke-jr> furthermore, OP_RETURN should not be used except to represent something else more specific; that something else perhaps might need an address, which would then be impeded by a generic OP_RETURN address by folks who think there should only be one possible address per script
< luke-jr> there is no such thign as a P2SH OP_RETURN
< jeremyrubin> Howso?
< jeremyrubin> i can create a p2sh op_return quite easily
< luke-jr> OP_RETURN as a transaction type is defined as a scriptPK that begins with OP_RETURN
< jeremyrubin> That's beside the point
< jeremyrubin> [4/20/21 08:13] <luke-jr> addresses define a recipient. OP_RETURN doesn't have a recipient.
< luke-jr> you can't prove on-chain that a P2SH contains an OP_RETURN, and such an output will enter the database
< belcher> you could create it but why would you? op_return is used for embedding data but if that data is hashed behind a p2sh then it cant even do that(?)
< luke-jr> belcher: it's supposed to only be used for embedding hashes; one extra layer doesn't impede that
< luke-jr> but the P2SH does impede being able to prune it
< jeremyrubin> i'm less worried about the pay-to support, more worried about the parsing of data generically
< pinheadmz> jeremyrubin could propose to define a segwit version `16` (for example) that decodes to <OP_RETURN> <data>
< luke-jr> and prunability is what distinguishes OP_RETURN from other unspendable outputs
< luke-jr> jeremyrubin: it sounds like your undefined use case really ought to use raw scripts, not addresses
< jeremyrubin> not really
< jeremyrubin> I want to split out "is this something we know about" or "is this some custom thing entirely"
< luke-jr> there's no distinction in this case
< luke-jr> OP_RETURN is some custom thing entirely
< jeremyrubin> Every p2sh is also some custom thing
< jeremyrubin> because a p2sh can contain an OP_RETURN <blah>
< luke-jr> beside the point
< jeremyrubin> That is the point
< luke-jr> anyway, I think I've gone over the reasons not to do it afaik.
< jeremyrubin> If i can try to explain it back...
< jeremyrubin> We should only have addresses or descriptors for things we know exactly what they are, and also for things that represent something that is not only payable but also potentially spendable.
< jeremyrubin> OP_RETURN, being unspendable and usually proprietary in purpose, should not have an address
< jeremyrubin> Is that a correct restatement of your concern?
< bitcoin-git> [bitcoin] dongcarl closed pull request #18963: [WIP] rebase: Call ProcessNewBlock() asynchronously (master...2020-05-async-pnb) https://github.com/bitcoin/bitcoin/pull/18963
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/90e0faaa442b...bca00942ed27
< bitcoin-git> bitcoin/master f02ca7a Aaron Clauson: Update msvc build to use Qt5.12.10 binaries.
< bitcoin-git> bitcoin/master bca0094 MarcoFalke: Merge bitcoin/bitcoin#21731: Update msvc build to use Qt5.12.10 binaries.
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21731: Update msvc build to use Qt5.12.10 binaries. (master...msvc_qt5.12.10) https://github.com/bitcoin/bitcoin/pull/21731
< jnewbery> Hi folks. Reminder that we have a p2p irc meeting in about 3.5 hours. Feel free to share your priorities here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities and add suggested topics here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
< jnewbery> We currently have two suggested topics: Reduce addr blackholes (PR 21528) (Amiti)
< jnewbery> Moving forward with asmap (gleb)
< jeremyrubin> Out of curiosity; is it possible to construct a Script as hex which is also an address?
< jeremyrubin> AFAIK, in binary it should be possible, but not as hex
< hebasto> wumpus: re "oh i should change that to the branch" -- I received Transifex notification about updated content. Is this it?
< ariard> jnewbery: yeah would like to propose "irc meetings on better L2s onchain support" as a topic but don't have the rights on wiki :/
< bitcoin-git> [gui] hebasto merged pull request #263: Revamp context menus (master...210330-context) https://github.com/bitcoin-core/gui/pull/263
< bitcoin-git> [bitcoin] hebasto pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/bca00942ed27...f385ad765174
< bitcoin-git> bitcoin/master 1398a65 Hennadii Stepanov: qt, refactor: Make AddressBookPage::deleteAction a local variable
< bitcoin-git> bitcoin/master 963e120 Hennadii Stepanov: qt: Drop menu separator that separates nothing
< bitcoin-git> bitcoin/master 7931175 Hennadii Stepanov: qt: Do not assign Alt+<KEY> shortcuts to context menu actions
< amiti> ariard: added it for you
< ariard> amiti: thanks!
< jnewbery> #startmeeting
< core-meetingbot> Meeting started Tue Apr 20 21:01:33 2021 UTC. The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< amiti> hi
< ajonas> hi
< jnewbery> hi folks
< ariard> hi
< gleb> Hi
< lightlike> hi
< jnewbery> As a reminder, everyone is free to share their p2p priorities here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
< promag> hi
< jnewbery> We also have three proposed topics for today's meeting: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#20-apr-2021
< gribble> https://github.com/bitcoin/bitcoin/issues/20 | JSON-RPC callback · Issue #20 · bitcoin/bitcoin · GitHub
< jnewbery> - Reduce addr blackholes (PR 21528) (Amiti)
< jnewbery> - Moving forward with asmap (gleb)
< jnewbery> - irc meetings on better L2s onchain support (ariard)
< jnewbery> Does anyone have any other proposed topics to add?
< jnewbery> oops, forgot
< jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
< jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< jnewbery> alright, let's get into the first topic
< jnewbery> #topic Reduce addr blackholes (amiti)
< core-meetingbot> topic: Reduce addr blackholes (amiti)
< amiti> hi!
< amiti> I want to discuss #21528
< gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
< amiti> I've mentioned it in a few different places, but I'll start with an overview of goals & motivation
< amiti> The goal is to reduce addr blackholes- aka relaying self advertisements to peers who are unlikely to continue relaying it to the network. Doing so would be a standalone improvement for addr propagation, and also, in my opinion, help with the disabletx project.
< amiti> The PR serves as a proof of concept for how this can be implemented in Bitcoin Core, but is currently in a draft because I have been trying to build confidence that this wouldn’t harm other software on the network.
< amiti> I wrote to the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018784.html, and have not gotten any responses there
< amiti> I’ve also looked at the implementations of every other client I’ve heard of =P and been recording that here: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430
< amiti> looks like almost all other clients are definitely ok. the only one I was very confused about is bitcore, so I'm hoping someone will respond to the issue I opened
< amiti> so, my main question for today is- do people think its reasonable for me to move forward with these changes? aka bring the PR into a "ready for review" state ?
< ariard> does it document bitcoinj, it's still maintained afaik?
< gleb> It looks like the stuff I attempted to do around a year ago, and at the time I also concluded it won't hurt other software.
< amiti> bitcoinj is not on the list. will look & add
< jnewbery> Yes, concept ACK
< amiti> gleb: what did you attempt?
< amiti> oh, another link is to a previous bitcoin-dev meeting where we discussed: http://www.erisian.com.au/bitcoin-core-dev/log-2021-03-25.html#l-954
< gleb> amiti: stop forwarding addr to nodes when it's useless.
< amiti> gleb: what did you try? did you PR?
< ariard> imo that's okay to move "ready for review", if no one yells on the ml and main bitcoin libraries are behaving like core
< gleb> amiti: I had a PR #17194, a core meeting discussion and several ML posts.
< gribble> https://github.com/bitcoin/bitcoin/issues/17194 | p2p: Avoid forwarding ADDR messages to SPV nodes by naumenkogs · Pull Request #17194 · bitcoin/bitcoin · GitHub
< amiti> gleb: thanks! I didn't realize :)
< gleb> The PR is only covers a subset of stuff I was suggesting
< gleb> I'll take a look and probably close mine, in case your work auguments it.
< amiti> cool, I'll check it out
< sipa> amiti: where did you land on sending/nonsending to non-relay peers? i remember you had some comments for sdaftuar_
< sipa> *from
< jnewbery> gleb: your PR disables addr relay based on the service bits sent by the peer. amiti's enables addr relay based on previous addr/getaddr messages received from the peer
< amiti> I'm still exploring the approach of not sending to non-relay peers
< amiti> sdaftuar expressed concern that if there is other software that doesn't send addr/getaddr messages but are relying on addr messages to discover peers, this change could make them vulnerable to a poor addrman / eclipse attacks
< sipa> but that's what the PR does?
< amiti> sipa: what?
< lightlike> I think an important difference is that the new PR would prevent sending to peers for whom we are their block-relay-only peer.
< sipa> amiti: not announcing to (assumed to be) non-relaying peers
< amiti> sipa: correct
< amiti> sipa: sorry, I don't understand your question
< sipa> amiti: just wanted to make sure i was up to date on the approach
< jnewbery> sipa: does "non-relaying peers" = "inbound block-relay-only peers" ?
< amiti> some context for the group: an alternative approach would be to identify "potential blackholes" and then add redundancy if those are selected. eg if you intend to relay to 2 peers but select a "potential blackhole", additionally relay to another peer
< sipa> jnewbery: an alternative approach would be still sending addr messages to everyone, but treat some subset as non-relaying (and thus not counting towards the 1 or 2 relay slots)
< jnewbery> sipa: ah. Got it. Thanks
< sipa> jnewbery: which would less risky for the network, but in my opinion weakly exploitable
< jnewbery> 'for the network' seems vague
< sipa> if we're confident this won't break anything, the current approach has my preference
< amiti> that is also my preference :)
< jnewbery> it'd be less risky for peers that want to receive addrs but don't ask for addrs, or am I missing some transitive behaviour?
< sipa> jnewbery: software that doesn't getaddr or send addrs, but still relies on receiving addresses
< sipa> jnewbery: i don't expect such software to exist, but it's also hard to be certain
< jnewbery> sipa: yep, that's my understanding
< amiti> I don't see much indication we will break things. I'll check bitcoinj and hope to hear back from bitcore, but beyond that I don't think there's much else I can do from my end
< sipa> ok
< jnewbery> I think amiti is doing a good job at analyzing the possible risk here: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430
< ariard> at least ml + libraries inquiry let's build confidence, do we have other methods to improve such opinion?
< sipa> no, there is only so much we can do
< jnewbery> Great. Anything else on that, or shall we move to next topic?
< amiti> just to conclude -
< amiti> I'll continue moving forward. if anyone has outstanding concerns, please let me know :)
< amiti> thanks!
< jnewbery> amiti: great. Thank you!
< jnewbery> #topic Moving forward with asmap (gleb)
< core-meetingbot> topic: Moving forward with asmap (gleb)
< gleb> We (me and sipa) want to move asmap forward and the main question is how to enable it by default. So far one priority is to help the maintainer to keep track of the BGP topology state updates.
< gleb> Basically, the maintainer would have to re-generate the compressed BGP topology map (asmap) for distribution and make sure it’s valid.
< gleb> There’s also testing of the existing tools and code in the Core, feel free to help:
< gleb> Once these tools are ready and stable, we will be able to enable it by default I think. Let me know if you have any thoughts or suggestions for other TODO to make progress here, otherwise I’m done.
< ariard> Who is maintainer here ? bitcoin core or asmap tooling one?
< gleb> Bitcoin Core maintainers, every core release probably should get a new asmap file
< gleb> To maintain the best p2p robustness of the nodes.
< jeremyrubin> hi
< sipa> one critical component i think is tooling to produce human-readable diffs between asmap files
< sipa> because they can't be deterministically produced
< gleb> Yeah, everyone should be able to check the diff between the two easily.
< ariard> so it's about finishing asmap-rs as a functional bitcoin-asmap ?
< gleb> I think sipa still doesn't like rust, so we might end up using smething different...
< gleb> But basically yes, improving the tools.
< ariard> i think language choice is ultimately decided by who is maintaining the tool :p
< sipa> i certainly don't mind having good tooling in another language than one i'm familiar with, if it"s maintained
< gleb> I think I can commit to maintaining asmap-rs, but then, should we also translate sipa/asmap (compression part) into it?
< gleb> No need to answer now, I'll think about it after the meeting.
< ariard> gleb: nah you can link *.c/*.cpp in rust, we can talk about it in rust-bitcoin if you wanna
< gleb> alright, i'll check how nasty that is :)
< jnewbery> ariard: I don't think that's the problem. The question seems to be whether we should add some dependency on maintaining a rust tool to our release process.
< sipa> the only thing we neef reusable or usable from within Bitcoin Core is decoding/querying support, and we have that
< sipa> sure, it'd be nice if some tool shipped with core and possibly built from shared sources could do encoding too and other things, but i don't think that's a critical requirement
< ariard> jnewbery: yes as i'm planning to have rust dependency for altnet, if you think that's a real issue to have dependency in rust, let's have a discussion during main meeting?
< ariard> i think it was a subject a year ago
< sipa> those things just need to be available and usable
< jnewbery> ok, anything else on this topic, or move on?
< gleb> i think we can move on
< sipa> yeah
< jnewbery> #topic irc meetings on better L2s onchain support (ariard)
< core-meetingbot> topic: irc meetings on better L2s onchain support (ariard)
< ariard> hi!
< ariard> it has been a recurring topic among LN devs how to improve second-layer protocol layer by the base layer
< glozow> hi
< ariard> as current tx-relay and fee-bumping aren't really accurate
< ariard> we have the idea last year to do a share meeting between ln/core dev in 2021, but it doesn't seem it's going to be a thing even this year
< ariard> so instead, i'm working on setting up a bunch of irc meeting to talk about stuff like dust, full-rbf, package relay, standardness, coordinated security disclosures
< ariard> started a new repo about problem space there : https://github.com/ariard/L2-zoology
< ariard> and will do an announcement on the ml latter this week about process
< ariard> feel free to contribute if you're interested by those topics :)
< gleb> ariard: i think to motivate people to come, you (or any coordinator) should be really clear on how this is going to be useful, what are the possible useful outcomes, and why this stuff is blocker for L2 protocols.
< sipa> i think it would be useful if this was more concrete
< ariard> gleb: yes how this is going to be useful is described in threats/ performance/ section of new repo, possible useful outcomes are changes like full-rbf or package-relay
< ariard> but sure we'll make this really clear in ml post
< glozow> i'd be interested in seeing some simulations of attacks
< sipa> people (ariard in particular) oftrn brings up issues of unreliability or certain lack of guarantees offered by the p2p protocol and its current implementations, but it's hard to discuss thst in general as there simply can't be any guarantees really, and other layers need to be aware of that... bit that doesn't mean we can't have useful discussions about specific features or so
< ariard> glozow: yes we can try them on signet or mainet, main issue is having a realistic mempool, with sudden spikes
< sipa> so it would be much more interesting to me at least to discuss specific features or proposals for the p2p protocol
< ariard> sipa: i know this non-reliability point would be the starter point for such irc meetings
< sipa> rather than "fee bumping is insufficient"
< ariard> like there is quite a divide among L1 and L2 devs, and afaik matt or rusty I'm leaning toward more reliability expectations
< ariard> sipa: ultimately if we release something like package relay we have a question on the L2-side, is how much stability we can expect of such mechanism
< sipa> ariard: yeah the vbyte thing wasn't done as well as it could have been
< sipa> ariard: you can't expect transactions to be relayed, period
< sipa> they're likely to be, and we can discuss what will work in non-adverserial settings likely
< ariard> sipa: i agree, the best you can hope is an economic compatible tx-relay policy widely deployed on the network like bip125
< sipa> i'm afraid that economic compatibility is very hard without something like partial blocks
< sipa> because network bandwidth costs are ultimately in contradiction with always relaying the economically optimal final state
< ariard> sipa: by stability I didn't mean "every-full-node on the network must support it" more Core devs are not going to deprecate future or introduce api change break without some release process
< ariard> sipa: i don't know about partial blocks?
< sipa> oh, certainly
< glozow> er, what does economic compatible tx relay mean?
< sipa> glozow: say a tx is bumped by 1 satoshi in fee
< ariard> glozow: let's define better as incentive-compatible, apply this policy will increase your mempool feerate
< sipa> it won't get relayed by bitcoin core, because it's below the marginal feerate (the cost of relaying over the network is considered larger than what it's paying extra
< jnewbery> ariard: I don't think that's even it. incentive-compatible would mean that this policy increases the total fee of the top block's worth of transactions in your mempool
< sipa> glozow: but it is economically still better for miners to get that transaction; miner want it, but the network has no incentive to relay it
< sipa> that's a conflict, and the only general solution for it i know of is partial blocks
< ariard> jnewbery: i think accepting higher-feerate replacement transaction increase the odds to mine a higher fee block in the future?
< amiti> what is the goal from today's discussion?
< sipa> where miners broadcast partial solutions to PoW over the network (say at 1/10th the difficulty) to prove to the network "there is likely a significant portion of PoW working on this block"
< sipa> that would provide a natural incentive to switch mempools to the contents of such a blocm
< glozow> sipa: i see, thank you
< jnewbery> ariard: that's not incentive compatible for a miner. They only care about the contents of the next block.
< ariard> amiti: getting the feedbacks of folks here if they would like to participate to such meetings, once we have a clear scope :)
< glozow> oh cool, similar to like mining pool partial solutions for reward shares
< jnewbery> ariard: when are you planning to do this irc meeting?
< glozow> like broadcasting "this is the block i'm working on" before finding the solution
< sipa> glozow: indeed
< ariard> jnewbery: depends of your miner model? even if they loss the race to mine next block, they are still willingly to optimize fee of following blocks
< jnewbery> any final topics before we wrap up?
< ariard> jnewbery: end of may/june
< jnewbery> ariard: thanks!
< ariard> i'm done, thanks for your feedbacks :)
< sipa> glozow: and partial PoW means a natural rate limit for such partial blovks
< glozow> ariard: I'm interested in such a meeting if you're able to coordinate a time
< glozow> apart from that, I'll keep an eye on the docs in your repo, and am interested in turning some of them into functional tests or simulations for a more concrete measure of the attacks
< ariard> glozow: coool let me get back to you to do simulation of attacks!
< amiti> I'd be happy to participate if there was a clear scope, agenda & goals. I agree with sipa that its hard to make much progress in a purely abstract conversation.
< amiti> (around p2p guarantees)
< darosior> ariard: (re-mentioning here) happy to participate too
< ariard> amiti: that's the reason of braindumping in a repo to avoid abstract conversation (and working on attacks simulation)
< amiti> cool!
< jnewbery> seems like that's all. Thanks everyone!
< jnewbery> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Tue Apr 20 21:56:09 2021 UTC.
< glozow> thanks jnewbery
< bitcoin-git> [gui] RandyMcMillan closed pull request #147: splash: New layout (master...splash) https://github.com/bitcoin-core/gui/pull/147
< bitcoin-git> [gui] RandyMcMillan closed pull request #208: docs: update README notes for /interfaces (master...interfaces-notes) https://github.com/bitcoin-core/gui/pull/208
< bitcoin-git> [gui] RandyMcMillan closed pull request #231: splash: new layout and new icon (master...new-icon) https://github.com/bitcoin-core/gui/pull/231