< bitcoin-git>
bitcoin/master 317fb96 Rjected: Add search for first blk file with pruned node
< bitcoin-git>
bitcoin/master 8625446 fanquake: Merge #17336: scripts: search for first block file for linearize-data with...
< bitcoin-git>
[bitcoin] fanquake merged pull request #17336: scripts: search for first block file for linearize-data with some block files pruned (master...linearize) https://github.com/bitcoin/bitcoin/pull/17336
< bitcoin-git>
[bitcoin] dongcarl opened pull request #18072: Use `libc++` headers from macOS SDK instead of from clang (master...2020-01-macos-sdk-with-headers) https://github.com/bitcoin/bitcoin/pull/18072
< wumpus>
looks like we got a new "warning: '*((void*)& time_first_key +8)' may be used uninitialized in this function [-Wmaybe-uninitialized]" in wallet.cpp
< wumpus>
(g++ 7.4.0)
< elichai2>
wumpus: I don't see that line in master
< fanquake>
wumpus: Pretty sure there's a pr open to fix that
< sdaftuar>
Is not sending any p2p message between VERSION and VERACK an important thing to do? i was going to add this new wtxidrelay feature negotiation there, but just realized I also would need to change some code that ignores messages received before VERACK, which gave me pause
< promag>
any idea when qt update >= 5.10? not clear from #13478
< sipa>
sdaftuar: how is this different than sendheaders etc?
< sdaftuar>
sendheaders, feefilter, etc all are sent in response to VERACK
< sdaftuar>
but the issue i wanted to avoid is there being a relay failure in between processing a peer's VERACK (allowing announcement of transactions to that peer, generally) and processing that peer's WTXIDRELAY message (changing the relay to be via wtxid)
< sdaftuar>
(of course, with extra bookkeeping there would not necessarily be a failure, but it would be tedious to do that)
< sdaftuar>
it's a pretty minor issue IMO, as it is a very short window that this could happen -- but i did notice a test failure due to this, so i thought it better to fix somehow
< sipa>
sdaftuar: but receiving a message before verack may be a problem for other applications, maybe?
< sdaftuar>
sipa: yeah, i wasn't sure about that. we assign a misbheavior point to a node that gives us an unexpected message before VERACK
< sdaftuar>
jonatack: the test failure i saw when doing this after VERACK was in p2p_permissions i think
< sdaftuar>
(the intermediate commit, where i tried to move this to before VERACK, was totally busted by the way; i pushed a better version a little while ago)
< jonatack>
thanks -- seems safer (in principle) to handle a post-VERACK time gap before WTXIDRELAY, if reasonably feasible
< wumpus>
promag: what do you need that for?
< promag>
wumpus: connect to lambda and kill invoke by slot name
< jonatack>
sdaftuar: in p2p_leak.py it actually states "A node should never send anything other than VERSION/VERACK/REJECT until it's received a VERACK" and test for that
< sipa>
sdaftuar: in the past people have used appending data to the version message for this purpose
< jonatack>
(non-exhaustively apparently)
< sipa>
heh, REJECT was permitted?
< jonatack>
seems so in the test
< jonatack>
(if i'm reading it correctly and it's functioning properly)
< sdaftuar>
cfields: I think you wrote that comment jonatack is referencing, any thoughts?
< sdaftuar>
sipa: extending the version message would be nice and simple, but i assume no one likes these variable length messages that ensue from that approach?
< sipa>
sdaftuar: exactly
< sipa>
some libbitcoin people complained about BIP37 adding an optional field to version
< sipa>
that was also 8 years ago
< sdaftuar>
i guess if there's nothing intrinsically wrong with a design where we throw message in between VERSION and VERACK, that seems most extensible to me
< sdaftuar>
but if software complains, then i am not sure what to do
< sdaftuar>
one option could be to do a bunch more work to support txid or wtxid-based announcements with a peer, so that turning on wtxidrelay on a link is seamless, but that is not clearly worth the effort t ome
< sipa>
sdaftuar: perhaps just do it with a message between version and verack (and gated by version number, i guess?), and when things are more ready, discuss on the ML whether that could cause problems
< sdaftuar>
that is where it's at right now (including gating it on version number, which i bumped)
< sdaftuar>
seems reasonable
< sipa>
i agree that's actually cleanest
< sdaftuar>
possibly i could also just move it to being after VERACK -- in some ways, transaction relay failing between VERACK and negotiation of wtxid relay is no different than transaction relay failing because the connection wasn't set up yet at the time the transaction was announced
< sdaftuar>
eg the test failure i observed could have happened for other reasons
< sdaftuar>
it just happened to have happened because of the thing i could sort of control
< sdaftuar>
anyway i'll leave it for now and revisit, thanks for thinking about this
< luke-jr>
it's not entirely clear to me if this BIP got implemented or not
< luke-jr>
if not, then the ship has sailed, and IMO we should be free to extend this way again :P
< sipa>
it's not because the BIP didn't get adopted that the problem it was trying to address is solved
< luke-jr>
?
< sipa>
BIP60 argued that adding optional fields to the version message was problematic, and suggested a solution; even if that solutions wasn't adopted, that does not imply that its concern (optional fields at the end of version) does not matter
< luke-jr>
sipa: my point is that if the version message is already variable-length, adding another field doesn't chnage that
< sipa>
it still has problems with serialization of deployments (what if two P2P extensions both want to add extra data?)... historically speaking that hasn't been a problem though :p
< bitcoin-git>
[bitcoin] hebasto opened pull request #18077: [WIP] net: Add NAT-PMP port forwarding support (master...20200130-natpmp) https://github.com/bitcoin/bitcoin/pull/18077
< bitcoin-git>
[bitcoin] luke-jr opened pull request #18078: [0.19] psbt: check that various indexes and amounts are within bounds (master...psbt_fix_pr17156-0.19.1) https://github.com/bitcoin/bitcoin/pull/18078
< bitcoin-git>
[bitcoin] luke-jr closed pull request #18078: [0.19] psbt: check that various indexes and amounts are within bounds (master...psbt_fix_pr17156-0.19.1) https://github.com/bitcoin/bitcoin/pull/18078
< bitcoin-git>
[bitcoin] luke-jr opened pull request #18079: [0.19] psbt: check that various indexes and amounts are within bounds (0.19...psbt_fix_pr17156-0.19.1) https://github.com/bitcoin/bitcoin/pull/18079