--- Day changed Wed Jul 15 2020 00:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 01:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds] 02:17 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 02:22 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has joined #bitcoin-core-pr-reviews 02:35 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:03 -!- Amalia36Kub [~Amalia36K@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:08 -!- Amalia36Kub [~Amalia36K@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 03:09 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has quit [Ping timeout: 258 seconds] 03:27 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 04:09 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-pr-reviews 04:26 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 04:37 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 04:40 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 05:30 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds] 05:31 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:13 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 06:14 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection] 06:17 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 264 seconds] 06:18 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:18 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 06:28 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving] 06:29 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:29 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 06:56 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds] 06:58 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-pr-reviews 07:52 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 08:27 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:32 -!- Marianne82Macejk [~Marianne8@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 08:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 08:37 -!- Marianne82Macejk [~Marianne8@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 08:38 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 08:41 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 08:47 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:47 < jnewbery> michaelfolkson: why not do it in the normal wednesday slot? 08:54 < michaelfolkson> When's the next available Wed slot jnewbery? July 29th? 08:54 < michaelfolkson> I was thinking we were booked up a while on the Wed slot and that it would need to be longer than the normal 1 hour slot template 08:55 < michaelfolkson> But Wed would work great too if we can fit it in 08:59 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 09:17 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 09:30 < troygiorshev> we 09:30 < troygiorshev> we'll get started in a half an hour! 09:32 < jnewbery> michaelfolkson: next slot is probably Aug 12 09:35 < jnewbery> I'd recommend against doing a meeting for longer than one hour for a couple of reasons: 1) it's difficult to maintain productive, focussed work for more than an hour, especially if it's over irc. 2) it's difficult for some participants to block out more than an hour. Because of timezones, these meetings can be at any hour of day/night depending on where you're joining from 09:36 < michaelfolkson> I definitely agree generally. But some large PRs like this, doesn't seem reasonable to squeeze it into a hour? Maybe a two parter? 09:38 < michaelfolkson> I'll try to find a host anyway who is willing to do it. I'm assuming it needs to be Pieter, Tim, Jonas? Would you be willing/able to do it jnewbery? 09:40 < michaelfolkson> Looking forward to it troygiorshev ;) 09:42 < jnewbery> I haven't reviewed the PR myself, and don't know my way around libsecp very well 09:44 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 09:52 -!- MarcoFalke_2 [~none@198.12.116.246] has quit [Quit: ZNC 1.7.1 - https://znc.in] 09:52 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 09:52 < michaelfolkson> Cool no problem, I'll see if one of Pieter, Tim, Jonas is willing to do it 09:53 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-pr-reviews 09:54 < sipa> i expect that (very) few people here are familiar with libsecp256k1 internals and design 09:54 < sipa> so if there is a review session on it, maybe it's better to start with something less involved to give familiarity to the codebase first? 09:55 -!- tattered [~tattered@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 09:55 < sipa> i don't have a concrete suggestion, and if there is interest, absolutely no objection 09:58 -!- ecurrencyhodler [68ac287f@cpe-104-172-40-127.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 09:59 -!- fodediop [~fodediop@41.214.84.8] has joined #bitcoin-core-pr-reviews 10:00 < troygiorshev> #startmeeting 10:00 < troygiorshev> hi 10:00 < jnewbery> hi! 10:00 < tattered> hi 10:00 < fodediop> hi 10:00 < felixweis> hi 10:00 < emzy> hi 10:00 < fjahr> hi 10:00 < sipa> hi 10:00 < vasild> hi 10:00 < troygiorshev> welcome to review club everyone! today we'll be talking about implementing the addrv2 message 10:00 < michaelfolkson> hi 10:00 < troygiorshev> notes and questions in the usual spot: https://bitcoincore.reviews/19031.html 10:01 < troygiorshev> who's had a chance to review the pr? (y/n) 10:01 -!- figs [c636814c@static-198-54-129-76.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 10:01 < tattered> y 10:01 < emzy> n 10:01 < fodediop> n 10:01 < felixweis> y 10:01 < jnewbery> y 10:01 < vasild> y :-D 10:01 < amiti> hi 10:01 < wumpus> hi 10:01 < michaelfolkson> y 10:02 < dongcarl> hi 10:02 < troygiorshev> great! 10:02 < troygiorshev> special thanks to vasild for being here :) 10:02 < ecurrencyhodler> Hallo 10:02 < nehan> hi 10:02 < troygiorshev> does anyone want to summarize 19360? 10:03 < michaelfolkson> Anyone here for the first time? 10:03 < dongcarl> me 10:04 * dongcarl has review club set up on his calendar now 10:04 < wumpus> y 10:04 < michaelfolkson> Ok not what I meant :) So extending the existing P2P message type to allow for Tor v3 addresses etc 10:04 < tattered> addr currently only supports 16 byte addresses which limit which endpoints nodes can connect to expanding addrv2 to 32 bytes enables tor v3 addresses and I2P plus yet-reserved addresses 10:05 < tattered> limitations on size and address type are also addressed in the PR 10:05 < jnewbery> 19360 is allowing CService to be [de]serialized without accessing CNetAddr's protected members, specifically ip 10:05 -!- C91 [554012cb@85.64.18.203.dynamic.barak-online.net] has joined #bitcoin-core-pr-reviews 10:06 < vasild> tattered: right, notice that in addrv2 the address size is variable, so it can be 32 for torv3, or 363 for some-fancy-network, or just 4 for IPv4 :) 10:06 * tattered thumbs up 10:06 < troygiorshev> michaelfolkson: tattered: jnewbery: great! 10:06 -!- DamienSomerset [4ca95869@cpe-76-169-88-105.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 10:07 < troygiorshev> we've just about covered this already, but on to the first question 10:07 < troygiorshev> What are the differences between addr and the new addrv2? 10:07 < ecurrencyhodler> Was there a reason why addr was restricted to 16 bytes only? 10:07 < michaelfolkson> Longer addresses, variable length addresses 10:08 < ecurrencyhodler> addr is restricted to 16 byte addresses. v2 address size is variable. 10:08 < sipa> ecurrencyhodler: it was restricted to IPv6 only 10:08 < sipa> ecurrencyhodler: which happens to be 16 bytes 10:08 < ecurrencyhodler> Was there a reason it was restricted to IPv6 only? 10:08 < sipa> and over time, everything just got hacked into a single IPv6 space 10:08 < sipa> ecurrencyhodler: ask satoshi :) 10:08 < michaelfolkson> Extensible too. So maybe we won't ever need addrv3? 10:09 < ecurrencyhodler> Thanks sipa. 10:09 < wumpus> I think because ipv6 seemed futuristic enough at the time, it was hard to imagine a network with larger addresses 10:09 < troygiorshev> ecurrencyhodler: michaelfolkson: exactly, note the addition of the NetworkID field 10:09 < vasild> addr looks like this: https://github.com/bitcoin/bitcoin/blob/cb85af83bb3476323367b480e48ce729714db996/src/test/netbase_tests.cpp#L464-L468, and addrv2 looks like this: https://github.com/bitcoin/bitcoin/blob/cb85af83bb3476323367b480e48ce729714db996/src/test/netbase_tests.cpp#L480-L485 10:09 < sipa> i'd say the biggest change in addrv2 is that it creates separate address spaces for separate networks... which implies also variable length 10:09 < wumpus> it's just that pubkey-based overlay networks need more 10:09 < tattered> ecurrencyhodler IIRC i2P was the only > 16 byte addressing at addr creation time -- but I may be wrong 10:10 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has joined #bitcoin-core-pr-reviews 10:10 < felixweis> the addresses get stored in peers.dat? does the file format allow for longer than 16 byte addresses? 10:10 < sipa> felixweis: no, it needs to change 10:11 < troygiorshev> felixweis: great observation! 10:11 < sipa> felixweis: and that's not really the right question 10:11 < sipa> the question is "does peers.dat permit storing anything else than IPv6 addresses", and the answer is no, because that's what addresses were in bitcoinland up to now :) 10:12 < troygiorshev> ok next question 10:12 < troygiorshev> Do you agree with how PR 19031 is being split up into smaller PRs? Would you rather the “reviewable” PRs be larger and include more commits? What are the advantages and disadvantages of this choice? 10:12 < troygiorshev> there are no wrong answers :) 10:12 < dongcarl> there's a prelude to the larger commits in the PR 10:13 < wumpus> fwiw peers.dat also can't store anything *smaller* than 16 bytes, all IPv4 addresses are padded :) 10:13 < jnewbery> I like small PRs, as long as it's obvious that each PR is beneficial by itself 10:13 < sipa> tattered: i believe so; i tried adding I2P support in 2012, but gave up due to it being very hard/impossible to pack into some ipv6 address space 10:13 < felixweis> i think there is no general answer to this question. depends on the logical complexity of the PR. 10:14 < dongcarl> the prelude commits might not be accepted on their own as pure-refactors, but does stand in this case given that they simplify later commits in the PR 10:14 < ecurrencyhodler> Having a large PR makes it more difficult to review and more likely less people will review it. 10:14 < troygiorshev> felixweis: agreed! 10:14 < michaelfolkson> Personally I like the smaller PRs approach and it works better for PR review clubs. I think Gleb's argument was that there should be cleaner mapping between a BIP and a PR 10:14 < michaelfolkson> And obviously not possible sometimes to break into smaller 10:15 < jnewbery> although it's getting better, we have a codebase organization that means PRs very often conflict. The larger the PR, the more often you need to rebase, which is painful for authors and reviewers 10:15 < tattered> sipa wumpus is it the case that peers.dat only stored ipv6 or that 16 bytes was the cap. meaing v2 onions are padded too in peers.dat, correct? 10:16 < wumpus> tattered: not really, the peers.dat format can change to support variable-length addresses just like the network protocol 10:16 < troygiorshev> great thoughts all around, it's important that we're deliberate when splitting things apart 10:16 < troygiorshev> Do you agree with how addrv2 support is being signaled? What are some alternatives? 10:17 < wumpus> tattered: it should be backward compatible (e.g. new code can still read old peers.dat files), there is no requirement to be compatible the other way around 10:17 < sipa> tattered: so for, "ip address" in bitcoin meant IPv6 address, and nothing else 10:17 < sipa> tattered: so everything, peers.dat, wire protocol, ... all just store IPv6 addresses 10:17 < sipa> which happen to be 16 bytes 10:18 < tattered> ty 10:18 < wumpus> i just mean, the peers.dat format is not an external interface, it can be changed any time 10:18 < vasild> tattered: the serialization code is the same, no matter whether the address is going to the disk or being sent over the network. In the current serialization we represent IPv4 and Torv2 addresses in 16 bytes, encoded as a "fake" IPv6 addresses from some reserved IPv6 networks. 10:18 < sipa> tattered: v2 hidden services are stored using the "onioncat" IPv6 range 10:18 < michaelfolkson> New message during handshake was chosen over alternatives of bumping protocol version and a new network service bit 10:18 < wumpus> michaelfolkson: +1 10:19 < ecurrencyhodler> Are changes in peers.dat included in this PR? 10:19 < troygiorshev> michaelfolkson: what do you think? is that what you would have picked? 10:19 -!- jondoe351 [965000000@2405:8100:8000:5ca1::24d:5ab3] has joined #bitcoin-core-pr-reviews 10:19 < michaelfolkson> Although this does add complexity especially if message arrives after handshake 10:20 < dongcarl> ecurrencyhodler: yup https://github.com/bitcoin/bitcoin/pull/19031/commits/826e17b547a42d1359687a08b8701131c8aca365 10:20 < michaelfolkson> I think it depends on how likely we'll need wider addresses in future? 10:21 < michaelfolkson> I don't really have any insight into that 10:21 < vasild> ecurrencyhodler: yes, the changes are in src/addrman.h 10:21 < wumpus> I picked a protocol version bump first, because I saw it as a protocol update, but a lot of people disagreed with this, but I'm okay with signalling it with a message 10:21 < wumpus> I don't think claiming a service bit for this makes sense, that's the only option I'd really disagree with 10:21 < jnewbery> the latest BIP says that the sendaddrv2 message should be sent after the verack. That means there's a window between receiving the verack and sending the sendaddrv2 message where the peer will send you addr messages 10:22 < troygiorshev> michaelfolkson: "...we'll need wider addresses..." do you mean new wider addresses that don't yet have a networkID assigned? 10:22 < michaelfolkson> Yup 10:22 < vasild> ecurrencyhodler: CAddrMan is what gets serialized into peers.dat 10:22 < wumpus> there is only a limited number of version bits and they're generally used to find peers supporting a certain feature, which is not really relevant here 10:22 < ecurrencyhodler> ty 10:22 < michaelfolkson> The argument against bumping protocol version was strong and convincing 10:22 < dongcarl> michaelfolkson: the bip can be extended to allow for wider addresses, addresses with unknown networkIDs are currently ignored, but there's a sanity check for an absurdly large address 10:23 < michaelfolkson> Haven't decided between new network service bit and new message in my mind 10:23 < wumpus> michaelfolkson: yes, I don't think we'll bump the protocol version ever again 10:23 < wumpus> michaelfolkson: there's not really a sensible reason to require a certain combination of features 10:24 < dongcarl> vasild: I don't remember the conclusion to last discussion about -onlynet=torv3 10:24 < wumpus> only torv3 and I2P peers *really* care about this 10:24 < jnewbery> I think it'd be great if the version message could be extended to include requested/supported features rather than have a new message type for every feature 10:24 < wumpus> IPv4 ones don't and don't need any threshold level to be forced to support it 10:25 < sipa> michaelfolkson: i don't think a service bit makes sense; the way to advertize you're listening on some other network... is by sending out addrv2 messages for your IP on that network; it doesn't need some flag to announce it 10:25 < vasild> dongcarl: me neither 10:26 < michaelfolkson> One of the arguments for new network service bit was SPV clients could find addrv2 nodes by service bit. But you're saying sipa that that would be obvious anyway? 10:26 < wumpus> jnewbery: yes, something that uses named extensions instead of needint to allocate a limited number of extension bits would be nice, some things have been proposed in the past IIRC 10:27 < wumpus> jnewbery: in any case it's not a rquirement for addrv2 10:27 < vasild> fwiw the current implementation will also work if the sendaddrv2 message (which means "I support addrv2, please send me in that format") arrives in the middle of the communication (not necessary the first message after verack) 10:27 < troygiorshev> what approach should we take if addrv2 needs to be expanded to inlude new networkIDs? should we plan for this now? 10:27 < wumpus> vasild: nice! 10:27 < wumpus> troygiorshev: it's mentioned in the BIP: this would need a new BIP per address type 10:28 < vasild> we just flip a peer's flag "this guy supports addrv2" and later when we send to him, if that flag is on, then we use addrv2. 10:28 < troygiorshev> wumpus: agreed, absolutely a new BIP. I mean to ask, how should we signal to peers that we're able to work with the new networkID? 10:28 < wumpus> troygiorshev: peers are not requried to store or forward unknown address types, but they should accept them (and may ignore them) 10:29 < wumpus> troygiorshev: to allow for forward compatibility they should NOT disconnect or ban on receiving unknown address types 10:30 < wumpus> there's no need to signal this to peers 10:30 < wumpus> either you accept them, or you throw them away, the peer doesn't care 10:30 < troygiorshev> wumpus: ah you're right! thanks! 10:30 < michaelfolkson> The arguments for and against the signaling methods were here for the log: https://github.com/bitcoin/bips/pull/907#issuecomment-611924492 10:31 < wumpus> (though *if* you're connected using a certain method, say, I2P, you can implicitly assume the peer will accept addressses for that network) 10:32 < michaelfolkson> And you only care about the one you are connected on right? You don't need to know the alternatives? 10:33 < vasild> gmaxwell made an interesting observation at https://github.com/bitcoin/bips/pull/907 -- if a peer forwards (gossips) a network he does not know about (e.g. networkid=0x07, some obscure data with length=123), then that could be a problem if the node which does the forwarding is old and network 0x07 has actually been added with required length!=123. Then that old node will happen to forward 10:33 < vasild> some bogus data to his peers and may get banned. 10:33 < wumpus> I think that's true in general, though, it's not forbidden either to gossip addresses for networks you're not connected to 10:33 < michaelfolkson> Maybe you are "multi-homed" and have a preference that isn't the one you are currently connected on? 10:34 < wumpus> yes, it's important to distinguish not being connected to a network and not knowing about a network here 10:34 < sipa> so the rules need to be clear that an invalid length known-type network should just be ignored 10:34 < sipa> and should not be treated as misbehavior 10:34 < wumpus> you can forward, say, I2P addresses if you know their format but are not on I2P 10:34 < sipa> and should not result in dropping the entire addrv2 message, just the one entry 10:34 < wumpus> but if there's an *unknown* network ID, which you don't know the formwat of, please ignore it 10:34 < vasild> sipa: ah! 10:35 < tattered> michaelfolkson "only care about the one you are connected on" is that right? Why wouldn't a node want to keep the most comprehensive peer list available? 10:35 < wumpus> you don't know what should be the length or format etc 10:35 < wumpus> it could be total injected garbage 10:35 < vasild> sipa: I would say the other way around - don't forward something you can't validate :) 10:35 < jnewbery> vasild: right, if there are new restrictions on message validity, we shouldn't ban/disconnect if those restrictions are violated, otherwise we end up banning old peers, and may split the network 10:35 < sipa> vasild: yes, but that's not the point i'm making 10:35 < sipa> vasild: you should ignore things you can't validate, but you should NOT ignore the entire addrv2 message it's in 10:36 < sipa> or it could lead to a censorship attack on upgraded nodes 10:36 < wumpus> yes, banning or disconnected on invalid addresses is not described in the BIP at all 10:36 < sipa> vasild: even when you *know* they're invalid 10:36 < michaelfolkson> tattered: I would guess it depends on your preference. If you only use Tor v3 and aren't interested in any of the alternatives? Others would be interested in alternatives I'd guess 10:36 < sipa> (and not just unknown) 10:37 < sipa> vasild: does that make sense? 10:37 < jnewbery> one interesting thing here is that we gossip addresses without doing any validation of them, unlike transactions and blocks, which we'll only relay if we've validated them 10:38 < vasild> yes, this is how the implementation works - it consumes an unknown network id messages and silently ignores them. But if it receives a known-network with wrong length then that is treated as misbehavior - the entire message is dropped (with all addresses) and maybe the peer banned. 10:38 < michaelfolkson> tattered: But then this is an argument for not using message during handshake and using new network service bit instead? I didn't understand sipa's earlier point 10:38 < sipa> vasild: that is wrong 10:38 < wumpus> there's a maximum allowed address length (512 byts) above which the entire addrv2 message is invalid 10:38 < sipa> a known-network with wrong length should equally be ignored 10:38 < fjahr> Is that not a DOS vector if we can send an addrv2 full of garbage and not get penalized for it? 10:39 < sipa> fjahr: you can send garbage any way you like 10:39 < wumpus> as this is not specific per network ID, it can't be used as a backward compatibility attack 10:39 < vasild> sipa: why? what sense does it make to receive IPv4 address with length 5? 10:39 < jnewbery> sipa: even if it's one of the 6 network types in the initial BIP? 10:39 < wumpus> fjahr: you can do the same for addr messages already 10:39 < sipa> vasild: read gmaxwell's comment, he explained the attack 10:39 < sipa> vasild: it's not about IPv4; it's about future networks that may be defined 10:40 < tattered> Does the fact that networkid, and length being unspecified have any marginal decrease in network topology akin to txn relay topology? ( I guess we care more about txn-origination privacy more than peer topology) 10:40 < vasild> sipa: but that is resolved by not forwarding unknown networks, no? 10:40 < sipa> vasild: no 10:40 < sipa> oh 10:40 < sipa> wait! 10:40 * michaelfolkson waiting with anticipation 10:41 < wumpus> tattered: how do you define a 'decrease in network topology'? 10:41 < sipa> i think that's right; either you don't relay unknown networks, or you don't punish for invalid known networks... either one is enough 10:42 < vasild> yes, the code does the former and the BIP will get some rewording 10:42 -!- jondoe351 [965000000@2405:8100:8000:5ca1::24d:5ab3] has quit [Remote host closed the connection] 10:42 < vasild> ... to match the code 10:42 -!- ecurrencyhodler [68ac287f@cpe-104-172-40-127.socal.res.rr.com] has quit [Remote host closed the connection] 10:42 < jnewbery> yes, as long as we don't ever change validity rules for known network types 10:43 < sipa> i'm still a bit hesitant to treat known-but-invalid addr entries as misbehavior; i agree there is no transitive partition risk if unknown types don't get relayed... but it's still scary 10:43 < felixweis> can't cross network type gossiping be used to identity relationships between a nodes on onion and clearnet announcements? 10:43 * troygiorshev thinks back to last week's PR review club 10:44 < sipa> felixweis: maybe... but hopefully the entire network is connected 10:44 < wumpus> felixweis: I don't think so, if nodes gossip other nodes' gossip, there doesn't need to be a direct connection 10:44 -!- DamienSomerset [4ca95869@cpe-76-169-88-105.socal.res.rr.com] has left #bitcoin-core-pr-reviews [] 10:44 < wumpus> ah yes if not tne entire network is connected 10:45 < troygiorshev> please continue this conversation, just want to throw the next question into the mix 10:45 < troygiorshev> Why is Tor v3 being considered? 10:45 < instagibbs> troygiorshev, vs? 10:45 < troygiorshev> instagibbs: not upgrading to it :) 10:45 < wumpus> tor v3 hidden services have better security and privacy than v2 10:46 < dongcarl> v2 is being deprecated too 10:46 < sipa> jnewbery: btw, perhaps the current code even relays not-our-network addresses too little (it relays them to 1 peer instead of 2), as it seems very hard to learn about onion addresses today if you're only connected to ipv4/ipv6 10:46 < felixweis> v2 is broken if facebook can have facebookcorewwwi.onion 10:46 < wumpus> a lot of work has been put into it by the Tor team 10:46 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 10:46 < instagibbs> https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions 10:46 < troygiorshev> dongcarl: i was hoping someone had seen this! 10:46 < tattered> wumpus Sorry I didn't elaborate properly. "decrease in network-topology *privacy*" meaning if a Eve wants to discover more of peer topology she injects a tag into an unspecified peer netid and address and observes where that tag is relayed by other peers. Though it seems if peers strongly drop netid and lengths they don't know about, this topology won't leak out as easily 10:46 < wumpus> (I don't have the link on hand, but they have an entire document describing the advantages of v3) 10:46 < dongcarl> According to the tor-dev mailing list, Tor plans to deprecate v2 with 0.4.4.x (Sept. 15th, 2020) and obsolete it in 0.4.6.x (July 15th, 2021) 10:46 < troygiorshev> the schedule is here https://blog.torproject.org/v2-deprecation-timeline 10:47 < dongcarl> More details here: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html 10:47 < troygiorshev> (exactly one year today!) 10:47 < dongcarl> Right, this is why we should try to get a working,tested addrv2 in a release soon 10:47 < wumpus> tattered: I think that's a valid concern, it shouldn't becomew worse than with the current gossip system 10:47 < instagibbs> TIL dongcarl 10:47 < michaelfolkson> And this was shared on the PR review club page: https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions 10:48 < wumpus> yes TIL that v2 addresses are being deprecated 10:48 < tattered> wumpus ok, that's what I was wondering - is it marginal lower than presently. ty 10:48 < dongcarl> We should also discuss -onlynet bootstrapping at some point, if time permits 10:48 < wumpus> tattered: address gossip is really slow and lossy compared to transaction relay, this will not change 10:49 < dongcarl> I feel like I've visited this topic a few times, but never had the right people in the same place 10:49 -!- jondoe351 [965000000@2405:8100:8000:5ca1::21f:172e] has joined #bitcoin-core-pr-reviews 10:49 < wumpus> dongcarl: you mean bootstrapping using hardcoded seeds is not enough? 10:49 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has left #bitcoin-core-pr-reviews [" bye"] 10:49 -!- jondoe351 [965000000@2405:8100:8000:5ca1::21f:172e] has quit [Remote host closed the connection] 10:49 < instagibbs> just connect to blockstream.info's v3 onion, Done. 10:50 < jnewbery> sipa: relaying to only one peer means that the address won't propogate very far in the network I imagine 10:50 < wumpus> dongcarl: this tended to work for me in the past, FWIW 10:50 < vasild> sipa: there is no strong reason to ban/misbehave a peer who sends us known-network, invalid length address. Other that he sent us something that does not make sense (e.g. IPv4 address with length 5). Maybe make distinction in networks 0x01..0x06 (as currently defined in BIP155) and networks 0x07.. (future ones) - ban on invalid len 1..6 networks and ignore/drop the address on 7.. networks? 10:50 -!- C91 [554012cb@85.64.18.203.dynamic.barak-online.net] has quit [Remote host closed the connection] 10:51 < tattered> torv2 addresses don't have the privacy level most people believe is present 10:51 < dongcarl> wumpus: You're saying in the next release, we'll include hardcoded v3 seeds which run nodes with addrv2 support? 10:51 < sipa> vasild: possibly; the alternative would mean that numbers 1-6 can be reused too if networkid space gets too crowded (who knows, maybe someone one day finds a use for "set top bit in network id to mean X"...) 10:51 < dongcarl> s/which run nodes/which point to nodes/ 10:52 < wumpus> dongcarl: we should, probably 10:52 < troygiorshev> tattered: great point, the improved crypto in v3 will help this 10:53 < tattered> torv3 fixes some tenuous privacy centralization in that's present in torv2 service infrastructure -- meaning bitcoin nodes running tor v3 addressing cant be deanonymized as easily 10:53 < wumpus> dongcarl: only a few (reliable) seed nodes would be enough 10:53 < wumpus> even if it's, say, only my node and instagibbs's :-) 10:53 < tattered> aka we should view supporting torv3 as not a "nice to have" but making node privacy more robust 10:55 < troygiorshev> last question, What are some other protocols that could be added here? Are they all compatible with addrv2, or will we need an addrv3 in the future? 10:55 < troygiorshev> 5 minutes left! 10:55 < dongcarl> wumpus: Right... I guess once 2 nodes (other than the seeds) connect to the seeds, the seeds will connect them through addr relay 10:55 < dongcarl> sipa: Is this guaranteed in the addr relay behaviour currently? 10:55 < wumpus> troygiorshev: my idea was that everything currently existing is compatible with addrv2 (I also asked around on twitter and such) 10:55 < wumpus> troygiorshev: this is one reason the absolute maximum length was increased to 512 bytes per address instead of 32 10:55 < sipa> dongcarl: define "guaranteed" ?) 10:56 < michaelfolkson> I had to look up what Cjdns was 10:56 < vasild> We will never need addrv3! (famous last words) 10:56 < troygiorshev> wumpus: i may or may not be using this question as an excuse to plug AltNet and discuss networks that don't bind well to sockets, etc. :D 10:56 < wumpus> no one knows for sure of course 10:57 < wumpus> maybe quantumnet needs addresses that can't even be represented in classical bits :PPP 10:57 < troygiorshev> wumpus: haha 10:57 < sipa> wumpus: ooooh! 10:57 < dongcarl> sipa: Is there any case where 2 torv3 nodes both connect to a third torv3 node, and the third one doesn't tell the 2 initiators about each other? 10:57 < troygiorshev> anyways, if you found this PR interesting, you'll probably also find ariard's AltNet proposal interesting! You can find it here: https://github.com/bitcoin/bitcoin/pull/18988 10:57 < sipa> dongcarl: since torv3 support does not exist current, i don't know what you're asking about 10:58 < wumpus> troygiorshev: is this a new overlay network, or mesh network? 10:58 < tattered> wumpus lool 10:58 < vasild> well, torv2 and torv3 relaying will be the same, so I guess s/torv3/torv2/ in dongcarl's question 10:59 < troygiorshev> wumpus: it's an attempt to make bitcoin's p2p more modular, such that anyone can write "drivers" for their network that can easily be "plugged" into 10:59 < troygiorshev> (bitcoin's p2p interface more modular) 10:59 < wumpus> the only requirement that addrv2 makes is that addresses an be stored in 512 bytes of data, nothing more, even variable-length "route descriptions" would work (if they fit in that length), unless your network is so postmodern that addresses can't be desrcibed at all, I don't see what would be unsuppore 11:00 < tattered> troygiorshev I think making p2p more modular is super cool! and critical for robustness :]] 11:00 < troygiorshev> that's time! 11:00 < troygiorshev> Thanks everyone! 11:00 < wumpus> thanks troygiorshev 11:00 < jnewbery> Thanks Troy! 11:00 < troygiorshev> And thanks especially to vasild for being here 11:00 < felixweis> ty 11:00 < fodediop> Thank you! 11:00 < nehan> thanks troygiorshev! 11:00 < tattered> ty troygiorshev wumpus vasild 11:00 < vasild> troygiorshev: thanks for hosting! 11:01 < amiti> thanks troy! I learned a lot 11:01 < michaelfolkson> Nice work troygiorshev 11:01 < sipa> thanks troygiorshev ! 11:01 < dongcarl> thanks! 11:01 < fjahr> ty 11:02 < vasild> dongcarl: "Is there any case where 2 torv2 nodes both connect to a third torv2 node, and the third one doesn't tell the 2 initiators about each other?" -- yes, I think that is possible, but I have to look at the code to confirm. 11:02 < troygiorshev> #endmeeting 11:02 -!- fodediop [~fodediop@41.214.84.8] has quit [Quit: WeeChat 2.8] 11:03 < emzy> ty 11:03 < wumpus> so I guess protocols with relative addressing ("this is the list of transit sequences for routing decisions from me to you") would not work with this, but gossip in general only works for global address spaces 11:04 -!- figs [c636814c@static-198-54-129-76.cust.tzulo.com] has quit [Remote host closed the connection] 11:08 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection] 11:15 -!- pinheadmz [~pinheadmz@mobile-107-107-62-99.mycingular.net] has joined #bitcoin-core-pr-reviews 11:24 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 11:41 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 11:56 -!- tattered [~tattered@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds] 12:01 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:24 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 12:37 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:53 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 12:56 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 12:58 -!- pinheadmz [~pinheadmz@mobile-107-107-62-99.mycingular.net] has quit [Ping timeout: 265 seconds] 13:41 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds] 13:58 -!- troygiorshev [~troygiors@72.136.121.38] has joined #bitcoin-core-pr-reviews 13:59 -!- troygiorshev [~troygiors@72.136.121.38] has quit [Client Quit] 14:00 -!- troygiorshev [~troygiors@72.136.121.38] has joined #bitcoin-core-pr-reviews 14:00 -!- Guest31602 [~seven@2a00:ee2:410c:1300:2159:e4c:cdb3:647a] has quit [Read error: Connection reset by peer] 14:00 -!- Guest31602 [~seven@2a00:ee2:410c:1300:9162:8b88:dc09:cc5c] has joined #bitcoin-core-pr-reviews 14:04 -!- troygiorshev [~troygiors@72.136.121.38] has quit [Client Quit] 14:04 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 14:18 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 14:41 -!- vervrvrvervvervr [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 14:41 -!- vervrvrvervvervr [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:57 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 15:07 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 15:07 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds] 15:15 -!- Guest31602 [~seven@2a00:ee2:410c:1300:9162:8b88:dc09:cc5c] has quit [Read error: Connection reset by peer] 15:15 -!- Guest31602 [~seven@2a00:ee2:410c:1300:9162:8b88:dc09:cc5c] has joined #bitcoin-core-pr-reviews 15:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds] 15:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 15:20 -!- Guest31602 [~seven@2a00:ee2:410c:1300:9162:8b88:dc09:cc5c] has quit [Read error: Connection reset by peer] 15:21 -!- Guest31602 [~seven@2a00:ee2:410c:1300:9162:8b88:dc09:cc5c] has joined #bitcoin-core-pr-reviews 15:21 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds] 15:23 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 15:27 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 15:30 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:33 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 15:38 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit] 16:52 -!- Guest31602 [~seven@2a00:ee2:410c:1300:9162:8b88:dc09:cc5c] has quit [Read error: Connection reset by peer] 16:57 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Read error: Connection reset by peer] 16:57 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 17:13 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.7.5 - https://znc.in] 17:14 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined #bitcoin-core-pr-reviews 18:05 -!- nik-j [~nik-j@072-239-128-183.res.spectrum.com] has joined #bitcoin-core-pr-reviews 18:05 -!- nik-j [~nik-j@072-239-128-183.res.spectrum.com] has quit [Remote host closed the connection] 20:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 20:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 20:54 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer] 23:10 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has joined #bitcoin-core-pr-reviews 23:20 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 23:25 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:d55c:34d1:9043:8e0c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 23:33 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 23:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds]