< BlueMatt> Does the bitcoin core windows installer show you the software license?
< fanquake> iirc you should be able to see it in the installer somewhere
< BlueMatt> can you provide screenshots?
< BlueMatt> or, like, someone with a windowz box
< achow101> BlueMatt: like the MIT license somewhere?
< fanquake> hmm. Just ran through the installer in a VM, didn't see license mentioned anywhere
< BlueMatt> fanquake: thanks
< BlueMatt> achow101: yes
< fanquake> I does get "installed" somewhere though
< BlueMatt> yea
< fanquake> NSIS certainly has options for adding a license page, if that's something we should add
< achow101> the license gets put in C:\Program Files\Bitcoin\COPYING.txt
< achow101> but it isn't ever shown
< BlueMatt> thanks achow101
< achow101> the gui also has "Help" > "About Bitcoin Core" which has a link to the license on opensource.org
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3f68f02db919...eb63b1db2c4d
< bitcoin-git> bitcoin/master aab7fd0 Aaron Clauson: Switch Appveyor CI to VS2019 stable image
< bitcoin-git> bitcoin/master eb63b1d fanquake: Merge bitcoin/bitcoin#22247: Switch Appveyor CI to VS2019 stable image
< bitcoin-git> [bitcoin] fanquake merged pull request #22247: Switch Appveyor CI to VS2019 stable image (master...appveyor-image-stable) https://github.com/bitcoin/bitcoin/pull/22247
< sipa> achow101: does the loading screen show anything about copyright?
< achow101> the copyright line is there, but no mention of the license
< bitcoin-git> [bitcoin] fanquake closed pull request #22241: MacOS Monterey(12.0 beta) support confirmed (master...patch-1) https://github.com/bitcoin/bitcoin/pull/22241
< 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
< glozow> could I ask for a rerun of this CI job please? https://github.com/bitcoin/bitcoin/pull/21800/checks?check_run_id=2821522273
< laanwj> glozow: done
< glozow> laanwj: thank you! :)
< laanwj> we could use some more review for the taproot signing / descriptor support (#22166, #21365) would be nice to get into 22.0
<@gribble> https://github.com/bitcoin/bitcoin/issues/22166 | Add support for inferring tr() descriptors by sipa · Pull Request #22166 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] vasild opened pull request #22250: doc: add basic I2P documentation (master...i2p_doc) https://github.com/bitcoin/bitcoin/pull/22250
< vasild> fanquake: wrt https://github.com/bitcoin/bitcoin/pull/22250#issuecomment-861453715 maybe jonatack meant "can be merged _even_ after FF", i.e. can be merged before or after FF
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22251: [WIP] ci: Use cirrus isolation feature (master...2106-ciTest) https://github.com/bitcoin/bitcoin/pull/22251
< 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
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #22251: [WIP] ci: Use cirrus isolation feature (master...2106-ciTest) https://github.com/bitcoin/bitcoin/pull/22251
< jnewbery_> Hi folks. As a reminder, we have a p2p meeting scheduled for today in around 4 hours time. If you have any topics that you'd like to discuss, feel free to add them to the wiki page here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
< jnewbery_> As always, feel free to update your own priorities at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities to let others know what you're working on
< sipa> has #21528 and #22245 be
<@gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/22245 | [p2p] Stop sending SENDADDRV2 message to block-relay-only peers by amitiuttarwar · Pull Request #22245 · bitcoin/bitcoin · GitHub
< sipa> has #21528 and #22245 been brought up?
<@gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/22245 | [p2p] Stop sending SENDADDRV2 message to block-relay-only peers by amitiuttarwar · Pull Request #22245 · bitcoin/bitcoin · GitHub
< sipa> sorry for double-gribbling
< 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
<@gribble> https://github.com/bitcoin/bitcoin/issues/22144 | Randomize message processing peer order by sipa · Pull Request #22144 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/22147 | p2p: Protect last outbound HB compact block peer by sdaftuar · Pull Request #22147 · bitcoin/bitcoin · GitHub
< ariard> i would be glad to log mines, but i don't have w/ access to this board since it has been moved :/
< ariard> another reminder, transaction relay workshop a hour and half from now on #l2-onchain-support (19:00 utc)
< amiti> sipa: ok! I'll add as a topic and we can discuss or it'll just be a quick update
< provoostenator> Can of worms of the day... #22254
<@gribble> https://github.com/bitcoin/bitcoin/issues/22254 | Boost::ASIO (used by Boost::Process) uses (falsely?) deprecated std::allocator · Issue #22254 · bitcoin/bitcoin · GitHub
< 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
<@gribble> https://github.com/bitcoin/bitcoin/issues/21935 | Enable external signer support by default, reduce #ifdef by Sjors · Pull Request #21935 · bitcoin/bitcoin · GitHub
< achow101> oh, it disables the wallet with --enable-fuzz
< jnewbery_> #startmeeting
< core-meetingbot> Meeting started Tue Jun 15 21:00:16 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
< 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
< amiti> hi
< ariard> yo
< lightlike> hi
< michaelfolkson> hi
< jnewbery_> Hi folks. We have two items on the agenda today: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#15-jun-2021
<@gribble> https://github.com/bitcoin/bitcoin/issues/15 | Option to specify external IP address · Issue #15 · bitcoin/bitcoin · GitHub
< 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.
<@gribble> https://github.com/bitcoin/bitcoin/issues/21527 | net_processing: lock clean up by ajtowns · Pull Request #21527 · bitcoin/bitcoin · GitHub
< jnewbery_> It'd unblock a lot of work to modularize net_processing and enforce clearer interfaces with validation and net
< glozow> hi
< jnewbery_> The PR is languishing a bit and had some pushback from vasild, but I think it's probably the right direction to take
< ariard> doesn't sound to big, i can have a look on it this week
< jnewbery_> Thanks ariard
< amiti> I'm a concept / approach ACK on the pr. I intend to review it, hopefully soon
< michaelfolkson> Seems like vasild can give an ACK (with reservations) from his comments which might help it along too
< jnewbery_> ok, if there aren't any questions on the approach, then we can move on to the next topic
< jnewbery_> #topic Reduce addr blackholes
< core-meetingbot> topic: Reduce addr blackholes
< jnewbery_> (amiti)
< amiti> hi! I brought #21528 out of draft this week, and opened #22245 as a small change I'd like to see in v22
<@gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/22245 | [p2p] Stop sending SENDADDRV2 message to block-relay-only peers by amitiuttarwar · Pull Request #22245 · bitcoin/bitcoin · GitHub
< 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
<@gribble> https://github.com/bitcoin/bitcoin/issues/22245 | [p2p] Stop sending SENDADDRV2 message to block-relay-only peers by amitiuttarwar · Pull Request #22245 · bitcoin/bitcoin · GitHub
< 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)
<@gribble> https://github.com/bitcoin/bitcoin/issues/22245 | [p2p] Stop sending SENDADDRV2 message to block-relay-only peers by amitiuttarwar · Pull Request #22245 · bitcoin/bitcoin · GitHub
< 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?
<@gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
< michaelfolkson> I read the Suhas comments
< amiti> michaelfolkson: still working on it, I'll post an update on the PR when its more concrete
< michaelfolkson> Cool
< amiti> ok, I guess that concludes the Reduce addr blackholes topic
< jnewbery_> thanks amiti
< ariard> w.r.t to erlay, gleb should release the new version of the simulator this week
< ariard> and down to review more minisketch once i'm done with the current package-PRs
< jnewbery_> ariard: good to hear that it's still being worked on!
< jnewbery_> ok, any last updates before we end the meeting?
< 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 Jun 15 21:23:38 2021 UTC.
< prayank> Can we merge this? https://github.com/bitcoin/bitcoin/pull/21157 or if anyone has issues with the changes in PR feel free to comment
< achow101> are we pushing back feature freeze? there are still 15 open prs in the milestone
< bitcoin-git> [bitcoin] theStack opened pull request #22257: test: refactor: use `{From,To}Hex` helpers for msg (de)serialization from/to hex (master...202106-test-refactor-replace_manual_deser_with_fromtohex) https://github.com/bitcoin/bitcoin/pull/22257