< bitcoin-git> [bitcoin] jamesob opened pull request #22263: refactor: wrap CCoinsViewCursor in unique_ptr (master...2021-06-cursor-unique-ptr) https://github.com/bitcoin/bitcoin/pull/22263
< ariard> #proposedmeetingtopic CoreDev in 2021, a.k.a project might benefit to reconnect with in-person meetings
< bitcoin-git> [bitcoin] vechiv opened pull request #22265: Update wallet.cpp (master...patch-2) https://github.com/bitcoin/bitcoin/pull/22265
< bitcoin-git> [bitcoin] hebasto closed pull request #22265: Update wallet.cpp (master...patch-2) https://github.com/bitcoin/bitcoin/pull/22265
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6bc1eca01b2f...65c4a36e57c5
< bitcoin-git> bitcoin/master 1111457 MarcoFalke: build: Disable deprecated-copy warning only when external warnings are ena...
< bitcoin-git> bitcoin/master 65c4a36 fanquake: Merge bitcoin/bitcoin#22258: build: Disable deprecated-copy warning only w...
< bitcoin-git> [bitcoin] fanquake merged pull request #22258: build: Disable deprecated-copy warning only when external warnings are enabled (master...2106-buildEnableWarnDeprecatedCopy) https://github.com/bitcoin/bitcoin/pull/22258
< bitcoin-git> [bitcoin] fanquake pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/65c4a36e57c5...7c561bea5288
< bitcoin-git> bitcoin/master fc0eca3 Sjors Provoost: fuzz: fix fuzz binary linking order
< bitcoin-git> bitcoin/master 7d94530 Sjors Provoost: refactor: clean up external_signer.h includes
< bitcoin-git> bitcoin/master 5be90c9 Sjors Provoost: build: enable external signer by default
< bitcoin-git> [bitcoin] fanquake merged pull request #21935: Enable external signer support by default, reduce #ifdef (master...2021/05/hww-qt-compile) https://github.com/bitcoin/bitcoin/pull/21935
< achow101> \o/
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7c561bea5288...d50302625e11
< bitcoin-git> bitcoin/master 28a9c9b Carl Dong: Make SHA256SUMS fragment right after build
< bitcoin-git> bitcoin/master 4cc35da Carl Dong: Rewrite guix-{attest,verify} for new hier
< bitcoin-git> bitcoin/master e2c40a4 Carl Dong: guix-attest: Error out if SHA256SUMS is unexpected
< bitcoin-git> [bitcoin] fanquake merged pull request #22182: guix: Overhaul how guix-{attest,verify} works and hierarchy (master...2021-05-guix-attestation-overhaul) https://github.com/bitcoin/bitcoin/pull/22182
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d50302625e11...dd24567a243f
< bitcoin-git> bitcoin/master 754e802 Luke Dashjr: test: check rejected future block later accepted
< bitcoin-git> bitcoin/master dd24567 MarcoFalke: Merge bitcoin/bitcoin#22120: test: p2p_invalid_block: Check that a block r...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22120: test: p2p_invalid_block: Check that a block rejected due to too-new tim… (master...qa_timetoonew_retry) https://github.com/bitcoin/bitcoin/pull/22120
< vasild> amiti: "why are these approach concerns only being raised now?" I wasn't aware of your work before yesterday. I think late concerns are normal annoyance in software development, not specific to Bitcoin Core or decentralized projects (I worked 10 years in Oracle, I know!). In the same way you seem to be unaware of previous attempts to fix the black holdes problem and explicit signaling for address
< vasild> amiti: "In regards to the path forward for #21528 & #22245, it seems like the concerns are all focusing specifically on SENDADDRV2 and the wording of that specific bip" -- no, that's not the case. My biggest concern is changing the meaning of getaddr, addr, addrv2 (and sendaddrv2 if 22245 is considered). I explained that in https://github.com/bitcoin/bitcoin/pull/22245#issuecomment-862539375. My
<@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
< vasild> concern can be split in 2 sub-concerns: 1. these changes (extensions) to the protocol are done without a new BIP or modifying existent ones and 2. even if with BIP, on the technical level, I think assuming that if a node sends one of getaddr,addr,addrv2,sendaddrv2 then they participate in address relay is wrong, some examples: https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-862312851
< sipa> vasild: i don't think that's the right takeaway - we already relay to everyone, there is no assumption right now that everyone participates in addr relay
< sipa> it's a heuristic for identifying situations where the receiver *doesn't* care about relay
< vasild> "*doesn't* care about relay" -- you mean "would not relay to other nodes", right?
< sipa> no, just in the most general sense, for whatever reason, does not care to receive unsolicited addr messages
< vasild> there may be nodes that do care about receiving addr relay but don't relay further
< sipa> whether they want those to relay further, to store in an addrman, to connect to, ...
< sipa> yes, definitely
< vasild> you would classify such nodes as "cares for addr relay"?
< sipa> yes
< vasild> ok
< sipa> i wrote a longer response with my thoughts here: https://github.com/bitcoin/bitcoin/pull/22245#issuecomment-862657075
< vasild> So, now we relay to everyone and the proposed change is to not relay to peers who never sent us getaddr,addr,addrv2,sendaddrv2?
< sipa> i suggest dropping sendaddrv2 from that list, but yes
< sipa> amiti went through a lot of effort to determine if such a change would actually hurt any software - without such an effort my thinking would be that we need an explicit separate bip for opting in/out of gossip
< sipa> and i think we may still want that over time
< sipa> but at the same time, this seems like a strictly better policy for now, absent any formalization
< vasild> What about nodes that "care about relay" (want to receive gossip), but never send getaddr,addr,addrv2 to anybody? Or send those messages occasionally to some random peers but we just don't happen to be amongst the chosen ones?
< sipa> it appears no such software exists
< sipa> but without a bunch of effort to actually go check what various pieces of software do, and posting on ML, ... i agree that would be a concern
< vasild> you mean for the first "never send to anybody" -- I don't object the research, assume no such one exists now, but is it safe to assume that no such one would exist in the future? As for the second type - "Or send those messages occasionally" -- bitcoin core is such.
< sipa> the proposed change is enabling addr relay on outbound non-block-only connections, or incoming connections that ever send (getaddr,addr,addrv2; and maybe sendaddrv2)
< vasild> (I have not read github posts for the last ~14 hours yet)
< sipa> i believe that policy wouldn't affect any bitcoin core versions in the past or those with the proposed change
< bitcoin-git> [bitcoin] endjkv opened pull request #22266: refactor: call GetBestBlock() before NewIterator() (master...master) https://github.com/bitcoin/bitcoin/pull/22266
< sipa> going to sleep now
< sipa> anyway, happy to discuss further to find a solution everyone is comfortable with
< * vasild> reading related code and github posts...
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22267: fuzz: Speed up crypto fuzz target (master...2106-fuzzSpeedCrypto) https://github.com/bitcoin/bitcoin/pull/22267
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22268: fuzz: Add Temporary debug assert for oss-fuzz issue (master...2106-fuzzAssert) https://github.com/bitcoin/bitcoin/pull/22268
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dd24567a243f...6eafa81b32fd
< bitcoin-git> bitcoin/master fa483e9 MarcoFalke: fuzz: Speed up crypto fuzz target
< bitcoin-git> bitcoin/master 6eafa81 MarcoFalke: Merge bitcoin/bitcoin#22267: fuzz: Speed up crypto fuzz target
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22267: fuzz: Speed up crypto fuzz target (master...2106-fuzzSpeedCrypto) https://github.com/bitcoin/bitcoin/pull/22267
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22270: Add missing bitcoin-util help doc and tests (master...2106-utilTestDoc) https://github.com/bitcoin/bitcoin/pull/22270
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6eafa81b32fd...922abe8ca382
< bitcoin-git> bitcoin/master faf1af5 MarcoFalke: fuzz: Add Temporary debug assert for oss-fuzz issue
< bitcoin-git> bitcoin/master 922abe8 MarcoFalke: Merge bitcoin/bitcoin#22268: fuzz: Add temporary debug assert for oss-fuzz...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22268: fuzz: Add temporary debug assert for oss-fuzz issue (master...2106-fuzzAssert) https://github.com/bitcoin/bitcoin/pull/22268
< michaelfolkson> Why did 0.21.1 include the ability to pay to (presumably mainnet) Taproot addresses? Shouldn't it have been just signet, regtest Taproot addresses until activation?
< michaelfolkson> Havent'
< michaelfolkson> Haven't verified that it did but the release notes say it did
< jamesob> this is maybe a weird question but does anyone know of a way to have two nodes sync headers in functional tests without syncing the corresponding blocks?
< _aj_> jamesob: inject the headers via a P2PConnection ?
< jamesob> _aj_: ah good call
< jamesob> i.e. P2PConnection ferries headers from one to the other
< _aj_> jamesob: can't have a single P2PConnection connected to two nodes per se, but yeah
< jamesob> _aj_: see this is why they pay you the big bucks
< jnewbery> jamesob: you could also use the `submitheader` RPC. Might be easier than using P2PConnection: call `getblock` on the source node, take the first 80 bytes, and submit them to the destination node with `submitheader`
< jamesob> jnewbery: also appealing - thanks!
< roconnor> michaelfolkson: Surely Bitcoin Core can pay to any segwit address of any version? That's the whole point of having forward compatable addresses.
< roconnor> I guess 0.21.1 was the first version after Bech32m was designed.
< michaelfolkson> roconnor: It is a safeguard question. If we prevent Taproot descriptors (e.g. #22156) being imported why not also prevent sending to a SegWit v1 address using the RPC until activation?
<@gribble> https://github.com/bitcoin/bitcoin/issues/22156 | Allow tr() import only when Taproot is active by achow101 · Pull Request #22156 · bitcoin/bitcoin · GitHub
< michaelfolkson> I can't see any technical reason for not doing that... just a question of what safeguards are appropriate and what safeguards aren't
< darosior> Importing a descriptor is for your own wallet when you don't validate the rules is a footgun. Sending to a Script with new rules that you don't validate yourself is forward compatibility.
< roconnor> The safeguards are no taproot spending rely and no generation of taproot addresses. But there is no need for my wallet to be taproot upgraded or taproot aware in order for me to pay to your taproot address, and relay of taproot paying transactions are similarly allowed.
< roconnor> Otherwise we get stuck in the segwitV0 address mire were no one starts using segwitv0 wallets because no wallets can pay to such addresses, and services don't upgrate their segwitv0 wallets because there is no demand to be paid.
< michaelfolkson> I was thinking the safeguard could be you can't generate a Taproot mainnet address until post activation height. Or lighter there is a warning when you do. But yeah that does link the RPC to current block height
< michaelfolkson> I'm getting confused what you can and can't do... You can't generate a Taproot address but you can pay to a Taproot address, it just isn't relayed
< sipa> michaelfolkson: the wallet won't let you import a taproot descriptor until after activation
< sipa> i think sending to taproot (or other future address formats) is far less of a risk, because it still falls on the receiver's shoulder
< sipa> someone has to create that address, and give it to the sender with a "pay me here"; if those funds are sent, the sender has paid - the fact that the receiver can get their coins stolen isn't the sender's problem
< sipa> so the protection needs to be at address generation time
< bitcoin-git> [bitcoin] theStack opened pull request #22271: fuzz: Assert roundtrip equality for `CPubKey` (master...202106-fuzz-assert-CPubKey-deser-roundtrip) https://github.com/bitcoin/bitcoin/pull/22271
< michaelfolkson> Ok makes sense, thanks
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/922abe8ca382...7b45c5e875ca
< bitcoin-git> bitcoin/master 8cd8f37 Pieter Wuille: Introduce well-defined CAddress disk serialization
< bitcoin-git> bitcoin/master e2f0548 Pieter Wuille: Use addrv2 serialization in anchors.dat
< bitcoin-git> bitcoin/master f8866e8 Pieter Wuille: Add roundtrip fuzz tests for CAddress serialization
< bitcoin-git> [bitcoin] laanwj merged pull request #20516: Well-defined CAddress disk serialization, and addrv2 anchors.dat (master...202011_disk_addr) https://github.com/bitcoin/bitcoin/pull/20516
< laanwj> #startmeeting
< core-meetingbot> Meeting started Thu Jun 17 19:00:47 2021 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< hebasto> hi
< laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos
< laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
< ariard> hi
< meshcollider> hi
< jamesob> hi
< fjahr> hi
< kvaciral[m]> hi
< laanwj> one proposed meeting topic: CoreDev in 2021 (ariard)
< ariard> yep
< laanwj> for the rest it might make sense to discuss things on the 0.22 milestone https://github.com/bitcoin/bitcoin/milestone/47 (instead of high priority for review)
< MarcoFalke> hi
< jonasschnelli> hi
< laanwj> we've slipped the feature freeze but I think it would make to postpone it https://github.com/bitcoin/bitcoin/issues/20851#issuecomment-863132781 , though not sure by how much
< achow101> hi
< gene> hi
< laanwj> #topic 22.0 milestone
< core-meetingbot> topic: 22.0 milestone
< laanwj> so there are still plenty of PRs that can be seen as a feature tagged for 22.0, many close to being mergable (just need a bit more review), https://github.com/bitcoin/bitcoin/milestone/47
< laanwj> anything to add/remove?
< jonatack> hi
< laanwj> hebasto: yes, that too
< sipa> i can't really pay much attentiin here right now
< laanwj> anyhow I hope people will get around to reviewing the remaining ones soon so they can still make it into 0.22
< sipa> will address review.comments on my prs soon, though
< laanwj> sipa: thanks!
< hebasto> if #21454 is gitian-specific and we moving to guix, maybe remove it?
<@gribble> https://github.com/bitcoin/bitcoin/issues/21454 | gitian: GLIBC_2.29 not found error at bitcoind startup on bionic · Issue #21454 · bitcoin/bitcoin · GitHub
< laanwj> hebasto: I'm not aware guix solves that, it uses the same glibc to build again
< hebasto> ok
< laanwj> hebasto: we need to get rid of these symbols uses somehow https://github.com/bitcoin/bitcoin/pull/22244#issuecomment-860932169
< ariard> i'm keeping an eye on #22147, if re-review is needed :)
< laanwj> "build against the correct glibc" is likely the best option though and more realistic in guix than in gitian
<@gribble> https://github.com/bitcoin/bitcoin/issues/22147 | p2p: Protect last outbound HB compact block peer by sdaftuar · Pull Request #22147 · bitcoin/bitcoin · GitHub
< laanwj> still, it doesn't warrant closing the issue yet
< laanwj> (or unmilestoning it)
< bitcoin-git> [bitcoin] dergoegge closed pull request #21706: log: Mitigate disk filling attacks by globally rate limiting LogPrintf(…) (master...g_log_ratelimiting) https://github.com/bitcoin/bitcoin/pull/21706
< jonatack> ariard: yup same, as well as #20234
<@gribble> https://github.com/bitcoin/bitcoin/issues/20234 | net: dont extra bind for Tor if binds are restricted by vasild · Pull Request #20234 · bitcoin/bitcoin · GitHub
< laanwj> thanks ariard and jonatack
< laanwj> #topic CoreDev in 2021 (ariard)
< core-meetingbot> topic: CoreDev in 2021 (ariard)
< ariard> hi
< ariard> so i was told by a lot of OGs in this projects, that they had the feeling about a decrease in communication quality around the last months, partially due to the lack of in-person meetings
< ariard> and i was lucky to be in Miami, and it was super cool to see a lot of LN devs in-person :)
< ariard> and have far greater understanding of our opposite arguments, which can sometimes be heated
< ariard> so i'm curious about what's folks thinking about in-person meeting again, maybe even in 2021 ?
< jonatack> +
< jonasschnelli> always a good idea...
< jamesob> Would love one, happy to help organize if needed
< jonasschnelli> just make sure you pick a country with minimal restrictions
< jonatack> ^ not in the US though
< ariard> jonasschenelli: i know that's a lot of work, i'm happy to help there
< jonasschnelli> EU people can't travel to the US right now
< ariard> jonasschnelli: yeah i wouldn't advise doing in the US right now, europe start to be more chill
< ariard> but it's really a per-country question
< hebasto> someone cannot travel even in EU now
< jonatack> EU just opened its borders, at least for the summer i guess
< ariard> hebasto: i know gleb has the same issue :/ we might pick a non-eu country
< laanwj> NL is still difficult (though things are clearing up)
< jonasschnelli> EU seems fine. Everyone just needs to have a test (or vac.)
< jonatack> el zonte
< jonasschnelli> Switzerland is fine
< achow101> usually we do coredev before/after another conference, are there any upcoming for this year?
< ariard> achow101: yes maybe LN hacking days, and we'll have a BDK/LDK meeting in europe in autumn (hopefully)
< ariard> a LN hacking day in germany or portugal
< fjahr> I would be happy to, seems a lot more feasible from where I am lately but in several parts of the world things are still very complicated. But fall is probably the best bet.
< jonasschnelli> ariard: I think it is a great idea. Willing to help. We also have coredev funds available for location, food, travel subsidy, etc.
< ariard> yeah i know, we won't be able to get everyone, like australia is pretty closed rn, but more folks, more fun :)
< jonatack> there is a bitcoin conference in biarritz, france (next to spain on the atlantic) end-august
< jonatack> some devs have reached out or are already planning to come for it
< darosior> jonatack: the conference is entire in french though
< ariard> jonasschenlli: awesome, let me send a mail to the OGs who has done the last ones, to have a start on considerations
< jonatack> right, but not core dev :)
< ariard> darosior: well we're still working hard to make french the official LN language, no :p ?
< jonatack> darosior: i wasn't planning to attend the conf itself
< darosior> ariard: haha +1
< ariard> who should i cc as part of the mail jamesob, jonatack, who else wants to help ?
< ariard> i think previous ones have been jonasschnelli, moneyball, schmidty and jnewbery ?
< ariard> *organized by
< jonasschnelli> ariard: yes. see https://coredev.tech/index.html#contact
< darosior> ariard: Happy to help, depending on the location of course i could be less useful..
< ariard> jonasschnelli: i know, i was invited to such coooool kids reunion one day but it did never happen :,(
< jonatack> (here's the conf i mentioned: https://www.surfinbitcoin.com/2021)
< jonasschnelli> August might be a bit tight.. but France might be a good option (especially in summer, tourism keeps it open and easy)
< achow101> I expect things will be more open towards the end of the year
< achow101> maybe we should do it in november and have a taproot activation party at the same time :)
< ariard> achow101: hard to say, most of europe start to be really open, and yes french has a big lobby to re-open most of the things for the season
< laanwj> anywhere in the EU is fine with me (assuming I'm allowed to travel, but as said, things are getting better here now that everyone is getting vaccinated)
< ariard> achow101: too much kharma :p
< jonatack> jonasschnelli: yes, august-early sept is the best time of year there and prices goes way down after august
< jonatack> jonasschnelli: end-aug / all of september and october actually
< sipa> i'm happy to travel wherever i'm allowed.to go for a coredev meetup
< jonasschnelli> I think someone should just pick a date and a location (vague) and see how can attend. If there are enough people, book a venue and finalise the organisation
< bitcoin-git> [bitcoin] steffanjensen opened pull request #22272: Update transaction.cpp (master...master) https://github.com/bitcoin/bitcoin/pull/22272
< ariard> yeah we'll consider carefully the travel bans to pick up a location
< ariard> jonasschnelli: yep, rough consensus :)
< jonasschnelli> ariard: Happy to share my past experience in organising (did SF and Zurich) (and of course I can help with stuff)
< ariard> jonasschenlli: thanks a lot, i'll reach out :)
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #22272: Update transaction.cpp (master...master) https://github.com/bitcoin/bitcoin/pull/22272
< jonasschnelli> always good to have someone near the planed venue
< * jonasschnelli> looking over to jonatack
< jonatack> sgtm
< jonatack> i don't like travelling :)
< ariard> jonatack: have you considered surfing across the atlantic as a travel mean :p ?
< * fjahr> sets meeting location to jon's house
< hebasto> hope being vaccinated will open EU borders for me
< ariard> okay, we'll do the things announced and share back news during next meetings :)
< laanwj> great!
< jonasschnelli> thanks ariard
< laanwj> any other last minute topics?
< jonatack> hebasto: i hope so
< laanwj> #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 Jun 17 19:33:12 2021 UTC.
< jonatack> thanks ariard, great idea
< bitcoin-git> [bitcoin] steffanjensen opened pull request #22273: the banks and bitcon shills don't want this update (master...master) https://github.com/bitcoin/bitcoin/pull/22273
< ariard> jonatack: you'll thank me when we'll all enjoy pain au chocolat in france or elsewhere :)
< bitcoin-git> [bitcoin] sipa closed pull request #22273: the banks and bitcon shills don't want this update (master...master) https://github.com/bitcoin/bitcoin/pull/22273
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #22273: the banks and bitcon shills don't want this update (master...master) https://github.com/bitcoin/bitcoin/pull/22273
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #22273: the banks and bitcon shills don't want this update (master...master) https://github.com/bitcoin/bitcoin/pull/22273
< sipa> ariard: which for unfathomable reason is called a croissant in the US :)
< luke-jr> ariard: jonatack: jonasschnelli: I thought EU is even more restrictive than US?
< jonatack> ariard: here if you ask for that, you'll be corrected. south of bordeaux, pain au chocolat is a chocolatine
< jonasschnelli> luke-jr: depends on what type of restriction
< jonatack> sipa: whoa
< jonasschnelli> luke-jr: example: europeans can't travel to the US right now
< luke-jr> jonasschnelli: last I heard, US folks can't go there at all?
< MarcoFalke> luke-jr: They can with a test or vac IIRC
< jonasschnelli> luke-jr: not sure about france... but I guess switzerland would be no problem.
< jonatack> luke-jr: it was, but things are opening up quickly
< luke-jr> cool
< schmidty> ariard: Im happy to help planning. Some light discussions with Advancing Bitcoin about piggybacking there. But dates getting moved.
< jonasschnelli> US covid case numbers per c. are relatively low
< jonasschnelli> thus most counties have opened borders for US tourists
< luke-jr> it's unlikely I'll be able to make it, but if I can, it'd probably need to be in September :x
< bitcoin-git> [bitcoin] steffanjensen opened pull request #22274: This will be implemented into bitcoin core at one point, with or without you.. your choice. (master...master) https://github.com/bitcoin/bitcoin/pull/22274
< jamesob> ariard: jonatack: thanks for raising the point ariard, will be exciting to have something on the books
< schmidty> What is the best dashboard of international travel restrictions?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #22274: This will be implemented into bitcoin core at one point, with or without you.. your choice. (master...master) https://github.com/bitcoin/bitcoin/pull/22274
< MarcoFalke> can somone pls block this spammer
< gene> ^
< jonasschnelli> As for france... I think US persons have to be vaccinated (no testing option). Which is kinda bad
< luke-jr> (but don't plan around me - like I said, I probably can't make it)
< luke-jr> sipa: what MarcoFalke said
< jonatack> jonasschnelli: i thought it was a also either negative test, or having had covid
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7b45c5e875ca...8cb43077b370
< bitcoin-git> bitcoin/master 9550dff Sebastian Falbesoner: fuzz: Assert roundtrip equality for `CPubKey`
< bitcoin-git> bitcoin/master 8cb4307 MarcoFalke: Merge bitcoin/bitcoin#22271: fuzz: Assert roundtrip equality for `CPubKey`...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22271: fuzz: Assert roundtrip equality for `CPubKey` (master...202106-fuzz-assert-CPubKey-deser-roundtrip) https://github.com/bitcoin/bitcoin/pull/22271
< jonasschnelli> jonatack: I thought so as well,... but than read https://fr.usembassy.gov/covid-19-information/
< jonasschnelli> But I guess you can also get in with a PCR
< sipa> luke-jr: yeah, will do obce i'm home (10 min)
< sipa> i expect tjat in a month or two lots of.covid restrictions will be a lot more relaxed
< jonasschnelli> yes.. I hope so
< sipa> given how vaccination in many places ib europe is going
< jonasschnelli> Looks like france is also okay with a negative PCR test (72h)
< jonasschnelli> (it changed on June 9th)
< jonasschnelli> yeah. france would be awesome. Also great if it is in fall (Nov). Waves are better.. :)
< ariard> schmidty: yep, yep sending mail in the evening, advancing 2020 was a great conf
< jonasschnelli> schmidty: I used https://travelbans.org in the past
< jonatack> fwiw last summer we had a record number of tourists ever and case counts stayed cool
< jonasschnelli> I was one of them... :)
< jonatack> jonasschnelli: yes, best waves are sept/oct as well as best weather
< bitcoin-git> [bitcoin] meshcollider pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/8cb43077b370...5c2e2afe990a
< bitcoin-git> bitcoin/master dbb0ce9 Pieter Wuille: Add TaprootSpendData data structure, equivalent to script map for P2[W]SH
< bitcoin-git> bitcoin/master e77a283 Pieter Wuille: Use HandleMissingData also in CheckSchnorrSignature
< bitcoin-git> bitcoin/master a91d532 Pieter Wuille: Add CKey::SignSchnorr function for BIP 340/341 signing
< bitcoin-git> [bitcoin] meshcollider merged pull request #21365: Basic Taproot signing support for descriptor wallets (master...202102_taproot_sign) https://github.com/bitcoin/bitcoin/pull/21365
< meshcollider> Taproot wallet \o/
< sipa> oh there were a few review comments i wanted to address
< sipa> i'll create a follow-up
< sipa> nothing blocking for release
< achow101> \o/
< bitcoin-git> [bitcoin] amitiuttarwar closed pull request #22245: [p2p] Stop sending SENDADDRV2 message to block-relay-only peers (master...2021-06-sendaddrv2) https://github.com/bitcoin/bitcoin/pull/22245
< ariard> jonasschnelli, jamesob, darosior, schmidty, jonatack: sent on your mail addresses (the ones i found with `git log | grep "$FIRST_NAME $LAST_NAME`)
< ariard> let me know if i you didn't receive or you prefer another mail addr :)
< ariard> if anyone wasn't present to meeting and wants to contribute to the orga, feel free to raise the hand