< 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
< 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"?
< 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
< 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>
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?
< 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
< 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
< 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 ?
< 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 #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 :)
< 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
< 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