< bitcoin-git> [bitcoin] fanquake closed pull request #20928: Create sustainable_wallet (master...patch-1) https://github.com/bitcoin/bitcoin/pull/20928
< achow101> jonasschnelli: 0.21.0 MacOS code signature pls
< jonasschnelli> will do the 0.21.0 signature macOS now
< gleb> sdaftuar: I was reviewing disabletx, and I didn't get why we don't use a positive "sendtx/enabletx" message instead. Since I'm a bit late to the party, I was wondering if this was discussed at some point, so I wanted to ask here instead of adding noise to the PR.
< gleb> Also, in the BIP, "For nearly the past year" ages poorly in the context of the BIP document I think :)
< sipa> gleb: i assume part of the reason is that the positive form is implied now (you can't assume sokeone doesn't want transactions unless they tell you)
< aj> gleb, sipa: here's kindof what i'm thinking re: switching towards something more opt-in https://gist.github.com/ajtowns/9703e8ff518fbf57c381f3eb3d6c2ca1
< gleb> Well, since there is a version change, we can start assuming the opposite starting 70017
< sipa> it's slightly different for a hypthetical equivalent for addr relay... as there it seems we'd like to assume/infer that some peers don't want some types of ip addresses (and having an explicit "i do want ipv17 addresses")
< sipa> gleb: i think that's a fairly strong break with how p2p versions have historically been used (only for enabling new messages, but only negotiate actual behavior change through specific messages)
< sipa> but yes, you could say as of some version everything is default off, and anything you will use must be announced ahead of time
< sipa> that's what aj seema to suggest, actually
< gleb> sipa: Personally I have no problem with breaking that kind of historical behavior (maybe I just don't understand something), but I see why people might want to keep it.
< aj> gleb: it's a bigger change than strictly necessary
< gleb> Good point.
< sipa> gleb: the practical concern would say: say in v70018 a fancy new feature is added to the protocol, which a certain implementation needs... but now they're forced to make a somewhat more invasive change to accomodate this opting in to everything
< aj> sipa: maybe that's a good reason for the opt-in to be 80000; that way opt-in only at version 70018, 19, 20, .. works for a bunch of features in the meantime
< sipa> it's easy to reconcile that though, i think: as long as one feature negotiation message is sent, everyrhing else is iff; if you send none, it is interpreted as some historical defaukt set
< jonasschnelli> gitian builders: 0.21.0 detached signatures are ready. Start your builders.
< sipa> on it
< wumpus> on it too, thanks for pushing the sigs so quickly
< jonasschnelli> As for ##bitcoin-core-gui ... the mode is wrong. It should not be on invite (achow101 luke-jr). Will fix now.
< jonasschnelli> ##bitcoin-core-gui has the correct mode now
< jonatack> jonasschnelli: thanks, it's open again for me
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20931: doc: Add historic 0.21.0 release notes (master...2101-docArchiveRelNotes) https://github.com/bitcoin/bitcoin/pull/20931
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cb2c57845177...ad571bd354cb
< bitcoin-git> bitcoin/master faea902 MarcoFalke: doc: Add historic 0.21.0 release notes
< bitcoin-git> bitcoin/master ad571bd Wladimir J. van der Laan: Merge #20931: doc: Add historic 0.21.0 release notes
< bitcoin-git> [bitcoin] laanwj merged pull request #20931: doc: Add historic 0.21.0 release notes (master...2101-docArchiveRelNotes) https://github.com/bitcoin/bitcoin/pull/20931
< bitcoin-git> [bitcoin] kiminuo opened pull request #20932: Introduce fsbridge::AbsPathJoin(base, p). (master...feature/fs-AbsPathJoin) https://github.com/bitcoin/bitcoin/pull/20932
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20933: [0.21] doc: Archive release notes, Add template for minor release (0.21...2101-docBackport) https://github.com/bitcoin/bitcoin/pull/20933
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ad571bd354cb...29d2aeb4a2b1
< bitcoin-git> bitcoin/master fa75d40 MarcoFalke: fuzz: Introduce CallOneOf helper to replace switch-case
< bitcoin-git> bitcoin/master 29d2aeb MarcoFalke: Merge #20828: fuzz: Introduce CallOneOf helper to replace switch-case
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20828: fuzz: Introduce CallOneOf helper to replace switch-case (master...2012-fuzzCallOneOf) https://github.com/bitcoin/bitcoin/pull/20828
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/95ea54ba0896...7d8a10a6f4d6
< bitcoin-git> bitcoin/0.21 b6d3502 MarcoFalke: doc: Archive release notes, Add template for minor release
< bitcoin-git> bitcoin/0.21 7d8a10a Wladimir J. van der Laan: Merge #20933: [0.21] doc: Archive release notes, Add template for minor re...
< bitcoin-git> [bitcoin] laanwj merged pull request #20933: [0.21] doc: Archive release notes, Add template for minor release (0.21...2101-docBackport) https://github.com/bitcoin/bitcoin/pull/20933
< aj> MarcoFalke: does bitcoin-util/gitian work better if bitcoin-util.cpp has #include <atomic> ?
< MarcoFalke> Haven't tried it. I'll let the build people figure it out :)
< MarcoFalke> fanquake: ^ :)))
< bitcoin-git> [bitcoin] jonatack reopened pull request #20546: policy, wallet, refactor: check for non-representable CFeeRates (master...non-representable-CFeeRate-check) https://github.com/bitcoin/bitcoin/pull/20546
< fanquake> aj: I have the solution for the reloc section issue for you
< jonasschnelli> sipa: does it matter if we draw the poly1305 key or the 3 byte length encryption first from the ChaCha20 metadata stream?
< jonasschnelli> For the implementation, going with the 3 byte length encryption first would be simpler
< aj> jnewbery: what do you think of a "p2p agenda/priorities" page on the devwiki, that's just "current status" rather than an "rss feed/log" like the p2p meeting page is? be a nice place to capture/update todo lists, and could serve as an agenda each week (for both overall priorities and a hashtag-proposedp2pmeetingtopic thing) ?
< Kiminuo> Win64 (https://github.com/bitcoin/bitcoin/pull/20932/checks?check_run_id=1700991165). Can anyone help me understand why building fails (only) for Win64?
< wumpus> provoostenator: please whitelist magnet:?xt=urn:btih:665c5bdc6f49948e47c1098d91ace98bd216150e&dn=bitcoin-core-0.21.0
< wumpus> Kiminuo: strange!
< wumpus> I don't really understand it either
< Kiminuo> wumpus, I have tried to build on a Win64 machine (in MSVS) and it really fails to build
< Kiminuo> So that's probably worse than "Cirrus behaves weird"
< Kiminuo> and something is probably really broken.
< wumpus> I don't see anything in the code change that looks out of place; it could be a linker order issue with libraries in the makefile, but why it doesn't happen for anything else in fs.cpp would be a good question
< Kiminuo> yeah, that confuses me too
< jonatack> Kiminuo: naive question, are backslashes universally ok in the doxygen?
< jnewbery> aj: I think it's a good idea. Do you think it's better to put it on the same page or a different wiki page?
< Kiminuo> jonatack, I did my best to write that doxygen comment but given that I don't have any experience with this type of documentation, I can't answer your question
< Kiminuo> I would love to see the result rendered too
< jonatack> Kiminuo: was just wondering if it could be some esoteric thing throwing off the compiler, i've seen stranger
< Kiminuo> jonatack, I see your point. I can try to remove that comment to see if something changes
< aj> jnewbery: different
< Kiminuo> haha
< Kiminuo> it's INSIDE "#ifndef WIN32"
< Kiminuo> jonatack, time to laugh ;)
< wumpus> 🤦
< wumpus> well at least i'm happy it was simple
< aj> it's hard to make forward progress through your review queue when people reply to your comments :(
< aj> or maybe my problem is it's a review stack and not a review queue!
< jonatack> Kiminuo: great! *unclutches straws
< fanquake> wumpus: congrats on another release 🚀
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/29d2aeb4a2b1...f91587f050d9
< bitcoin-git> bitcoin/master 85cc6be gzhao408: lock annotations for MemPoolAccept functions
< bitcoin-git> bitcoin/master 2f463f5 gzhao408: [doc] for CheckInputsFromMempoolAndCache
< bitcoin-git> bitcoin/master f91587f fanquake: Merge #20834: locks and docs in ATMP and CheckInputsFromMempoolAndCache
< bitcoin-git> [bitcoin] fanquake merged pull request #20834: locks and docs in ATMP and CheckInputsFromMempoolAndCache (master...2021-01-validation-cleanup) https://github.com/bitcoin/bitcoin/pull/20834
< bitcoin-git> [bitcoin] practicalswift reopened pull request #20089: validation: Increase robustness when loading malformed mempool.dat files (LoadMempool) (master...load-mempool-robustness) https://github.com/bitcoin/bitcoin/pull/20089
< bitcoin-git> [bitcoin] practicalswift closed pull request #20089: validation: Increase robustness when loading malformed mempool.dat files (LoadMempool) (master...load-mempool-robustness) https://github.com/bitcoin/bitcoin/pull/20089
< jnewbery> aj: ACK. If you create the first version of the page I can link to it from the p2p meeting page, and I'll add my own priorities
< prusnak> congratulations on the 0.21.0 release!
< vasild> MarcoFalke: https://github.com/bitcoin/bitcoin/pull/20845 -- "incoming onions are also treated as local peers and should thus not be excepted..."
< vasild> there may be "normal" local peers and "onion" peers that look like local, do we want to log all of them with LogPrint(BCLog::NET?
< vasild> both types
< bitcoin-git> [bitcoin] danben opened pull request #20936: build: build fuzz tests by default (master...build-fuzz-tests-by-default) https://github.com/bitcoin/bitcoin/pull/20936
< vasild> from the description it looks to me that the intention is to only LogPrint(BCLog::NET the onion peers
< vasild> but this is not what the patch does
< MarcoFalke> vasild: It probably hurts more to log onion unconditionally than it does to log "normal local peers" with the category only
< MarcoFalke> quote: "log [...] of manual connections too -- though would need to do something cleverer"
< MarcoFalke> Once we have agreement and a solution to log manual connections unconditionally throughout net for misbehavior/disconnect, we can also fine tune for "normal local peers"
< jnewbery> moot?
< jonasschnelli> miit?
< sipa> Beech, oak, chestnut, ash... Good, good, good. Many have come.
< wumpus> #startmeeting
< core-meetingbot> Meeting started Thu Jan 14 19:03:20 2021 UTC. The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< jnewbery> woah don't be so hasty there sipa
< kanzure> hi
< jonatack> hi
< emzy> hi
< jnewbery> hi
< jonasschnelli> hi
< fjahr> hi
< hebasto> hi
< sipa> hi
< wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb 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
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< achow101> hi
< sipa> congrats on 0.21 everyone!
< wumpus> yes, congrats on the release
< jnewbery> congrats everyone!
< emzy> \o/
< MarcoFalke> \o/
< fjahr> \o/
< wumpus> any last-minute topics ?
< MarcoFalke> I'd like to add #20715 to high prio :)
< gribble> https://github.com/bitcoin/bitcoin/issues/20715 | util: Add ArgsManager::GetCommand() and use it in bitcoin-wallet by MarcoFalke · Pull Request #20715 · bitcoin/bitcoin · GitHub
< jonatack> #20391 for me, please
< gribble> https://github.com/bitcoin/bitcoin/issues/20391 | wallet: introduce setfeerate (an improved settxfee, in sat/vB) by jonatack · Pull Request #20391 · bitcoin/bitcoin · GitHub
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< fjahr> #19145 for me please
< wumpus> we weren't there yet :)
< gribble> https://github.com/bitcoin/bitcoin/issues/19145 | Add hash_type MUHASH for gettxoutsetinfo by fjahr · Pull Request #19145 · bitcoin/bitcoin · GitHub
< wumpus> MarcoFalke: replacing #20362?
< gribble> https://github.com/bitcoin/bitcoin/issues/20362 | test: Implicitly sync after generate* to preempt races and intermittent test failures by MarcoFalke · Pull Request #20362 · bitcoin/bitcoin · GitHub
< jnewbery> wumpus: can we move #20557 to high priority bug fixes? PR #16702 broke some aspects of addrman deserialization and it'd be nice to fix them
< gribble> https://github.com/bitcoin/bitcoin/issues/20557 | addrman: Fix new table bucketing during unserialization by jnewbery · Pull Request #20557 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
< MarcoFalke> wumpus: Jup
< jamesob> hi
< wumpus> MarcoFalke jonatack fjahr jnewbery: done
< fjahr> wumpus: thank you!
< jonatack> thanks! (i'd like to either finish up the ongoing feerate sat/B migration and CFeeRate refactoring, or close it out as up for grabs)
< wumpus> at last, something new to review again!
< luke-jr> >implying there was ever a shortage
< wumpus> heh
< jonatack> jnewbery: agree, good choice
< wumpus> any other PRs to add/remove or that are almost ready for merge?
< jamesob> I think #19806 is pretty close to ready. More generally I'm kind of curious with how the g_chainman work is going to interface with the assumeutxo work; the two are going to step on each others' toes I think
< gribble> https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub
< jamesob> (referring to #20749)
< gribble> https://github.com/bitcoin/bitcoin/issues/20749 | [Bundle 1/n] Prune g_chainman usage related to ::LookupBlockIndex by dongcarl · Pull Request #20749 · bitcoin/bitcoin · GitHub
< dongcarl> hi
< wumpus> the g_chainman work is necessary for factoring out the consensus code (libbitcoin_kernel) so fairly important
< dongcarl> jamesob: What parts are you most concerned about? Happy to talk through it and see how we can work it out
< sipa> jamesob, dongcarl: ideally you two figure out how to order things
< jamesob> there are some parts of assumeutxo that add chainstate-related calls to, say, net_processing so we probably need to sequence the changes somehow
< jamesob> I'm pretty flexible but also want to know whether to steel myself for rebase hell :)
< wumpus> maybe that can get rid of the circular dependency as well :)
< jamesob> let's hope
< wumpus> it's really a blemish
< dongcarl> jamesob: I think we can do it in an order or in a way that makes rebase easier, happy to chat offline and plan this out
< jamesob> that's the trouble with validation though - it's pretty challenging to yank parts out of it
< jamesob> dongcarl: sure, sounds good
< wumpus> i wish the utxo load/store stuff was not part of validation but a module in itself but yes it's not easy design
< jamesob> agreed, but it's not trivial to untangle in my experience
< wumpus> right
< wumpus> anyone with another topic suggestion for today?
< wumpus> that's a short meeting then, this time!
< wumpus> #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 Thu Jan 14 19:19:39 2021 UTC.
< jonasschnelli> \o
< jnewbery> short meetings are good meetings. Thanks wumpus!
< sdaftuar> did i miss the congrats on 0.21 part? oops. congrats on 0.21 everyone :)
< luke-jr> XD
< luke-jr> yes
< luke-jr> [19:03:57] <sipa> congrats on 0.21 everyone!
< wumpus> congrats sdaftuar
< wumpus> jnewbery: agree
< midnight> yeah folks, thanks for the effort! \o/
< midnight> also: <3
< bitcoin-git> [bitcoin] dongcarl opened pull request #20937: guix: Make nsis reproducible by respecting SOURCE-DATE-EPOCH (master...2021-01-nsis-sde-reproducibility) https://github.com/bitcoin/bitcoin/pull/20937