< 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)
< 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
< 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>
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!
< 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.
< 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
< 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/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
< 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
< 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?