< laanwj>
NSIS has a possibility to add an EULA, and some projects use that to show the license, but always found it strange to show an open source license as one, you don't need to accept the license to use the software as it doesn't impose any instructions on use
< laanwj>
instructions->limitations
< bitcoin-git>
[bitcoin] S3RK opened pull request #22249: test: kill process group to avoid dangling processes when using `--failfast` (master...test_kill_process_group) https://github.com/bitcoin/bitcoin/pull/22249
< vasild>
laanwj: open source licenses usually contain something like "the author is not liable for any damages due to the use of software"
< laanwj>
yes
< laanwj>
i'm not opposed to showing the license, but treating it as an EULA that you have to agree to before continuing is strange for a FOSS license
< instagibbs_>
elichai2, ok well yes you're going to miss messages like that on block connect with such a low watermark
< fanquake>
vasild: I guess. Documentation can be merged / fixed any time.
< jonatack>
fanquake: vasild: yes, that's what i was trying to say, in case the pull was opened today with urgent intention ;)
< bitcoin-git>
[bitcoin] glozow opened pull request #22252: policy: Trim Packages when transaction with same txid exists in mempool (master...2021-06-mempool-matches) https://github.com/bitcoin/bitcoin/pull/22252
< bitcoin-git>
[bitcoin] glozow opened pull request #22253: [validation/mempool] distinguish between same tx and same nonwitness tx already in mempool (master...2021-06-same-txid-diff-wtxid) https://github.com/bitcoin/bitcoin/pull/22253
< amiti>
hi sipa! I was going to give a quick update about 21528, but didn't put it as a meeting topic. do you wanna discuss? I'm happy to put them both on the agenda
< sipa>
i saw some discussion with laanwj about bip155 changes, so maybe it's useful
< sipa>
(i don't have much to add myself specifically)
< sipa>
i'd like to see #22144 and #22147 in 22.0 too, if people want to discuss those
< provoostenator>
When people start blaming compilers, I start running.
< achow101>
What's the difference between --enable-fuzz and --enable-fuzz-binary?
< provoostenator>
I think --enable-fuzz is what you need to actually fuzz, but then you don't get any of the other binaries.
< provoostenator>
Whereas --enable-fuzz-binary just makes sure you didn't break anything? (it's slow though)
< achow101>
but the fuzz binary built without enable-fuzz doesn't seem to work?
< provoostenator>
(slow to build that is, I think it's not supposed to work)
< sipa>
achow101: it works, it just doesn't fuzz
< sipa>
you need to provide it an input on stdin
< achow101>
oh
< sipa>
rather than finding fuzzing inputs on its own
< bitcoin-git>
[bitcoin] luke-jr opened pull request #22255: [0.21] wallet: Do not iterate a directory if having an error while accessing it (0.21...listwalletdir_iterate_inf-0.19) https://github.com/bitcoin/bitcoin/pull/22255
< achow101>
provoostenator: interestingly, compiling 5c06af49efba407f062fdbf124b6d571fedd73fa from #21935 with --enable-fuzz --disable-external-signer works, but does not with only --disable-external-signer
< jnewbery_>
Does anyone have any last minute topics to add?
< jnewbery_>
ok, let's get started on the topics
< jnewbery_>
#topic locking in net_processing
< core-meetingbot>
topic: locking in net_processing
< _aj_>
hi
< sipa>
hi
< jnewbery_>
#21527 is currently waiting for review. It adds a new lock to PeerMan, which I think later can be used to replace all the usage of cs_main in net_processing.
< amiti>
the biggest concern about 21528 was around compatibility of other software on the network, and I looked at every client I could, opened issues confirming my understanding, posted on mailing list, mentioned it here multiple times... so I feel like its okay to move forward with these changes :)
< sipa>
so the policy is going to be "if you ever send anything addr related, we assume you care about addresses"?
< amiti>
yeah
< amiti>
updated from "we assume you care about addresses regardless"
< amiti>
and then there was a question about BIP155 on #22245, I've posted my thoughts on the PR, but want to give anyone the chance to raise questions / any remaining concerns
< amiti>
ok, if not, this is just an update then :)
< lightlike>
#22245 would make sendaddrv2 kind of non-parallel with the other feature negotiation message wtxidrelay (which must be send regardless of whether we do tx relay)
< lightlike>
not sure if consistency something that is valuable at this spot though
< sipa>
i don't think so
< amiti>
lightlike: why must wtxidrelay be sent regardless of tx relay?
< sipa>
if you don't care about addresses, sending sendaddrv2 is just irrelevant
< lightlike>
"The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack" (BIP 339)
< sipa>
so presumably, someone who doesn't care about addresses at all is not going to send it
< ariard>
sounds more an oddity of bip339
< amiti>
lightlike: ah, gotcha
< sipa>
in order to implement BIP339 you must send wtxidrelay
< sipa>
but you're free not to implement BIP339
< sipa>
someone who doesn't care about addrv2 isn't going to implement BIP155, and thus isn't going to send sendaddrv2 either?
< jnewbery_>
lightlike: that MUST means "you must send it if you want the peer to relay transactions using wtxid". I disagreed with using that language at the time because I thought it was confusing.
< sipa>
(which also applies to anyone who doesn't care about addresses in the first place)
< lightlike>
jnewbery_: ah, ok, then it is not an issue.
< michaelfolkson>
What's the latest on #21061 amiti? Is the new approach finalized/agreed or is it still up in the air somewhat?