--- Day changed Wed Jun 17 2020 00:02 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 00:06 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 00:06 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 00:07 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 00:07 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 00:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 00:34 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 00:35 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 00:58 -!- nobody123 [~nobody123@dslb-094-217-173-069.094.217.pools.vodafone-ip.de] has quit [Remote host closed the connection] 01:17 -!- jonatack [~jon@213.152.161.69] has joined #bitcoin-core-pr-reviews 01:28 -!- jonatack [~jon@213.152.161.69] has quit [Ping timeout: 260 seconds] 01:30 -!- jonatack [~jon@37.171.126.207] has joined #bitcoin-core-pr-reviews 01:34 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 01:44 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 01:45 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 01:50 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 258 seconds] 02:00 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 02:00 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 02:16 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 02:23 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 240 seconds] 02:23 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 02:35 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 246 seconds] 02:40 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 02:41 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 02:45 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 02:45 -!- reallll is now known as belcher 03:05 -!- Alejandrin50Kohl [~Alejandri@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:30 -!- Alejandrin50Kohl [~Alejandri@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 258 seconds] 03:30 -!- furunodo [~furunodo@185.134.22.207] has joined #bitcoin-core-pr-reviews 03:50 -!- furunodo [~furunodo@185.134.22.207] has quit [Quit: This computer has gone to sleep] 04:12 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 04:30 -!- jonatack [~jon@37.171.126.207] has quit [Read error: Connection reset by peer] 04:40 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 04:45 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 265 seconds] 04:46 -!- jonatack [~jon@104.254.90.243] has joined #bitcoin-core-pr-reviews 05:24 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 05:28 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 258 seconds] 06:08 -!- jonatack [~jon@104.254.90.243] has quit [Quit: jonatack] 06:30 -!- tralfaz [~tralfaz@89.46.114.17] has joined #bitcoin-core-pr-reviews 06:34 -!- furunodo [~furunodo@185.134.22.207] has joined #bitcoin-core-pr-reviews 06:36 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 256 seconds] 06:38 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 06:57 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 07:36 -!- slivera [~slivera@103.231.88.22] has quit [Remote host closed the connection] 08:00 -!- Prayank [849a3aec@132.154.58.236] has joined #bitcoin-core-pr-reviews 08:04 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 08:06 -!- Prayank [849a3aec@132.154.58.236] has quit [Ping timeout: 245 seconds] 08:07 -!- lightlike [~lightlike@p200300c7ef145c00441b578045803dca.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 08:08 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 246 seconds] 08:17 -!- train [~train@c-73-0-216-24.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews 08:19 -!- train [~train@c-73-0-216-24.hsd1.fl.comcast.net] has quit [Client Quit] 08:30 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 08:52 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 09:01 < jnewbery> We get started in an hour. Notes and questions: https://bitcoincore.reviews/18242.html 09:02 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 265 seconds] 09:07 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:15 < furunodo> this will be my first Bitcoin Core PR review... I'm gonna to try to follow, while updating some wiki pages such as https://en.bitcoin.it/wiki/Pull_request and https://en.bitcoin.it/wiki/Development_process 09:20 < michaelfolkson> Cool, this should be helpful https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core 09:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 09:23 -!- tralfaz [~tralfaz@89.46.114.17] has quit [Quit: Leaving] 09:24 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 09:24 -!- vasild_ is now known as vasild 09:27 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 09:41 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 09:46 < thomasb06> For Fermat's little theorem, I know another algorithm 09:50 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Quit: ERC (IRC client for Emacs 26.3)] 09:52 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 09:52 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 09:52 -!- SirRichard [~SirRichar@cpe-24-29-169-110.cinci.res.rr.com] has joined #bitcoin-core-pr-reviews 09:53 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:53 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 09:54 < thomasb06> For Fermat's little theorem, I know another algorithm 09:54 -!- figs [566a792d@86.106.121.45] has joined #bitcoin-core-pr-reviews 09:55 < ariard> raj_149: fyi, real_or_random raised the point that our chacha20poly1305 isn't defined enough in the BIP 09:55 < thomasb06> do you see my messages, maybe I broke something... 09:55 < ariard> wrt to decryption method, ChaCha20Poly1305AEAD::Crypt handles decryption too 09:56 < jnewbery> thomasb06: we see your messages 09:56 < thomasb06> jnewbery: hey! Nice to read you... 09:58 < thomasb06> the other Fermat's algorithm is computing squarres successively, and using only those needed 09:58 < sipa> thomasb06: that's known as an exponentiation ladder, and that's indeed what we use 09:59 < raj_149> ariard: yes i noticed. But i guess the draft provides enough pointer for a reference implementation? Though i still havent been able to digest the goto stuffs. There must be a better way to do it. 10:00 < thomasb06> sipa: it seemed you where using Euclid algorithm... 10:00 < jnewbery> #startmeeting 10:00 < sipa> thomasb06: the python code uses euclid's algorithm; the C++ code has an exponentiation ladder that computer a^(p-2) mod p 10:00 < jnewbery> hi 10:00 < SirRichard> hi 10:00 < andrewtoth> hi 10:00 < willcl_ark> hi 10:01 < thomasb06> hi 10:01 < lightlike> hi 10:01 < ariard> hi 10:01 < raj_149> hi 10:01 < emzy> hi 10:01 < jnewbery> today's notes and questions are here: https://bitcoincore.reviews/18242.html 10:01 < troygiorshev> hi 10:01 < jnewbery> ariard is our host. Over to you, ariard! 10:01 < ariard> thanks jnewbery! 10:02 < ariard> so to get started, usual question who has reviewed the PR ? 10:02 < raj_149> y 10:02 < willcl_ark> y 10:02 < SirRichard> y 10:02 < ariard> that's great! have you left any comment on it ? 10:02 < raj_149> y 10:02 < willcl_ark> no :( 10:03 < emzy> n 10:03 < nehan> hi 10:03 < SirRichard> n 10:03 < nehan> y 10:03 -!- tarboss [~tarboss@p54a03b4a.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 10:03 < jnewbery> n 10:04 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:04 < ariard> okay what was your process to review a PR implementing a BIP ? 10:04 < ariard> did you read the BIP or code first ? or dig into context around the BIP, like reading old mail threads ? 10:05 < willcl_ark> The context to me seems pretty rational from the BIP 10:05 < raj_149> 1. read the bip. 2. read on missing gaps that i dont understand yet 3. read the code. 4. tally the code with the BIP. 10:05 < willcl_ark> (i read the BIP first) 10:05 < ariard> raj_149: quick reply, it's hard to be sure you have enough pointer without a second implementation not hurting wrinkles 10:06 < ariard> willcl_ark: what seems you rational here ? what this BIP is trying to achieve? 10:06 < emzy> I read the BIP first. 10:06 < ariard> raj_149: what were the missings gaps? 10:07 < willcl_ark> ariard: we want to prevent kinds of MITM attacks which are easy on unencrypted traffic. 10:07 < raj_149> ariard: depends on individual's previous knowledge. for me i didn't knew chacha20, poly1305 and AEAD details. so had to read them up first. 10:08 -!- YianniG87 [59244134@89.36.65.52] has joined #bitcoin-core-pr-reviews 10:08 -!- thomasb0` [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 10:09 < raj_149> willcl_ark: it seems this doesn't necessarily solves all forms MITM, i guess the draft also mentions this somewhere. if i am not mistaken. 10:09 < ariard> willcl_ark: in Bitcoin context, why it makes sense to encrypt traffic ? Most of data is already public like blocks, headers 10:10 < ariard> raj_149: yes generally you have to, it's pretty lengthy reviewing this kind of PR when it involves cryptographic primitives 10:10 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds] 10:10 < ariard> have you been through the process to assert this pick up of cryptographic primitives compare to alternative ? 10:10 < jnewbery> (anyone can feel free to answer any of these questions) 10:11 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Ping timeout: 256 seconds] 10:11 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 10:11 < pinheadmz> encrypted traffic obscures the fact that you even have abitcoin node running 10:11 < raj_149> ariard: for start it stops traffic analysis and IP to publickey linkage. In general all sorts of privacy leaks that can occur by monitoring network traffic of a node. 10:11 < pinheadmz> and withou, people can snoop on the network connectivity graph, TX propogation and maybe resolve the origin of a ne TX 10:12 < ariard> pinheadmz: obscures to whom? not if you're running on port 8333 10:12 < pinheadmz> who says I am? :-) 10:12 -!- populate [~populate@178.162.222.42.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:12 < pinheadmz> I dunno, oppressive regimes 10:12 < willcl_ark> if you can tamper with messages, you can get legitimate (truthful) peers banned 10:12 < ariard> no I mean your ISP can still learn you're running bitcoin if you're using port 8333 10:13 < pinheadmz> ariard I understand but you dont have to use port 8333 and if my ISP sees a bunch of encrypted blobs coming into port 9000, that is at least plausible denyability 10:13 < jnewbery> and even if you're not using port 8333, bitcoin p2p traffic has an unmistakable pattern 10:13 < ariard> pinheadmz: with tx propogation for sure it obfuscates tx origin for on-path attacs, now spy peers can still observe origin by connecting to you 10:14 < pinheadmz> certainly for SPV or Neutrino, there is privacy leaked with plaintext mesages 10:14 < pinheadmz> but that privacy is leaked to the full node you connect to anyway 10:14 < ariard> raj_149: which publickey you're pointing to ? what kind of privacy leaks you can think of beyond tx origin ? 10:14 -!- thomab07 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has joined #bitcoin-core-pr-reviews 10:15 < pinheadmz> Im not sure if theres an attack vector around this, but you mightbe abe to tell where a node is in the sync process by reading their traffic 10:15 < ariard> jnewbery: that's a huge concern, even tx propagation may still leak being interactive and we don't do padding 10:16 < emzy> it's not only good to secure the p2p trafic from your ISP eyes, it's also good agains state level surveillance. 10:16 < pinheadmz> ariard do you know - i asked this on the BIP draft - why not use Noise Protocol for the key exchange the way Lightning does? 10:16 < ariard> pinheadmz: if you assume attacker knows about 1) block announcement 2) listen for transactions flooding 3) can map encrypted blob size to transactions received? 10:17 < raj_149> ariard: i am not exactly sure on the kind of possible leaks that can happen over clear text data. I read somewhere by monitoring network traffic and some kind of triangulation observer can link origin transactions with IP addresses, without connecting to me as a node. Would like to know about other possible leaks that i dont know about. clearly there should be some over encrypted data. 10:17 < jnewbery> pinheadmz: you surely can tell if a node is in IBD, even if you used a stream cipher to encrypt the messages 10:17 < populate> regarding the entropy of encrypted information with strong time entropy: https://en.wikipedia.org/wiki/Traffic_analysis 10:18 < ariard> pinheadmz: I'm not sure but I would say historical reasons, Noise Protocol wasn't fully spec out when BIP 151 was first submitted 10:18 < emzy> also in flight modification of the data is easy posible without MAC 10:19 < sipa> pinheadmz, ariard: there is some interaction with development of a private authentication protocol we've been working on 10:19 < sipa> noise's authentication relies on revealing identities, which is something we want to avoid 10:19 < willcl_ark> if you wanted to eclipse someone, tampering with their current peers' messages (and having them disconnected) seems like a good start 10:19 < willcl_ark> maybe this PR doesn't quite solve that though 10:19 < ariard> raj_149: see https://arxiv.org/pdf/1812.00942.pdf on in-protocol leaks 10:20 < ariard> emzy: but what about a MitM attacker intercepting communications from both side? there is no authentication with BIP324 10:21 < sipa> the full functionality obviously needs encryption + authentication 10:21 < willcl_ark> ONe thing I noticed it this BIP (and lightning) vs "standard" ChaCha20 Poly1305 is that we encrypt the packet length, why is this? 10:21 < sipa> but authentication is very easy to add in a modular way once we have encryption 10:21 < jnewbery> willcl_ark: if you can tamper with traffic you can get a peer disconnected, but not banned. The terminology is a bit confusing currently, but the disconnected peer is allowed to reconnect 10:21 < willcl_ark> jnewbery: ok, thanks for the clarification 10:22 < emzy> ariard: Right, but it's only posible at first connection attempt. A running session is save from MitM attack. So it is better then not. 10:22 < jnewbery> of course, if you're able to tamper with messages, you could just continue to do that to get them disconnected again, or just block all traffic 10:22 < willcl_ark> even a "ban" is always temporary (some length of time) also I think, right? 10:22 < raj_149> ariard: thanks. 10:22 < ariard> sipa: but we could have reuse a Noise pattern with ephemeral key pairs? It doesn't mandate how you exchange key pairs? 10:22 < jnewbery> willcl_ark: 24 hours by default 10:22 < willcl_ark> yes 10:22 < sipa> ariard: right, that could work, using noise purely with ephemeral keys 10:23 < ariard> willcl_ark: good question, to make dumb traffic analysis harder?, see real_and_random and my posts on the BIP 10:23 < pinheadmz> would it make sense to have static keys for "precious" nodes ? 10:23 < sipa> though i expect even in that case we'd want our own "vendored" version, with secp256k1 keys etc 10:23 < pinheadmz> for example, connecting my personal SPV to my remote Full Node 10:23 < sipa> pinheadmz: yes, that's called authentication! 10:23 < sipa> pinheadmz: and of course that's the eventual goal 10:23 < willcl_ark> ariard: Oh i didn't see the comments at the end of the BIP! 10:23 < pinheadmz> i thought you meant authentication like message integirty 10:24 < sipa> pinheadmz: ah, no 10:24 < sipa> pinheadmz: history is that we original had BIP150/BIP151 for auth and enc 10:24 < sipa> BIP151 was replaced with BIP324 10:24 < pinheadmz> eevntual goal, so nodes would have @IP:port kind of hostnmaes like lightning ? 10:24 < ariard> jnewbery: I was verifying just before is this really what we do in AcceptConnection 10:24 < ariard> pinheadmz: please not permanent pubkeys like in LN 10:25 < sipa> pinheadmz: perhaps that's getting off-topic, but the idea is that there wouldn't be any *observable* identities (for obvious reasons) 10:25 < sipa> but if you *know* the identity of a peer you're connecting to, you can private determine whether it's them 10:25 < pinheadmz> excellent 10:25 < sipa> (without them even knowing that authentication succeeds) 10:25 < sipa> https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b (a bit outdated, but the writeup is mostly right still) 10:26 < ariard> emzy: right, but in practice if you assume ISP-capabilities like attackers they would be in place for intercepting at any moment of the session 10:27 < willcl_ark> ariard: so am I right after reading the comments in thinking we only encrypt the packet length, but still don't MAC it (not re-read the code changes)? 10:27 < sipa> willcl_ark: that's right 10:27 < ariard> sipa: right does Noise make it mandatory to use Curve25519? 10:27 < sipa> ariard: i honestly don't know 10:27 < emzy> ariard: If you have a long running node, the time window is very narrow. 10:28 < ariard> willcl_ark: yes we don't MAC it, BOLT8 does it, I spent few hours yesterday trying to find even theoritical attacks on modifying a length field MAC 10:29 < sipa> ariard: secp256k1 isn't supported by the noise framework, but it'd be possible to of course use a noise protocol that we instantiate ourselves 10:29 < willcl_ark> slightly off topic, but I appreciated the short command ID improvement here 10:29 < sipa> though at that point i think the advantages are rather small 10:29 < ariard> and found nothing, so likely too minor 10:29 < sipa> at a high conceptual level, bip324 is effectively that 10:29 < willcl_ark> ariard: sipa, thanks 10:30 < raj_149> sipa: can you through some pointer on what do you mean by noise framework? 10:30 < raj_149> *throw 10:30 < sipa> raj_149: https://noiseprotocol.org/ 10:30 < raj_149> thanks.. 10:30 < ariard> used by whatsapp or lightning among others 10:32 < raj_149> feels like kinda same thing BIP324 is doing? 10:32 < ariard> sipa: yes I slightly agree, does anyone have done at least of properties comparison between a Noise pattern with ephemeral keys vs BIP324 ? 10:32 < sipa> raj_149: bip324 is encryption only, no auth 10:33 < sipa> (it's authenticated encryption, but that's detecting tampering, not identity of the peer) 10:33 < ariard> emzy: I'm not sure the time window matters here, internet infrastructure is quite static 10:33 < ariard> okay let's move to next question 10:33 < raj_149> sipa: got it. ariard: no but seems interesting exercise. 10:34 < ariard> BIP324 introduces a new message structure, notably with short command ID, what do you think about it ? 10:34 < raj_149> loved it. :D 10:34 < ariard> especially the new short command ID? is it worth the complexity vs bandwidth saving argued ? 10:34 < ariard> raj_149: haha please explain 10:34 < raj_149> thougb currently it seems hardcode. Not p2p agrrement. is that correct? 10:35 < ariard> raj_149: yes no p2p agreement for now 10:35 < ariard> which makes sense bip324 is already big enough, it can be done in future specifications 10:35 < willcl_ark> I saw some discussion over Cap'n'proto (for the GUI), was there a concious choice not to also leverage that here? 10:35 < troygiorshev> At this level it seems just fine to have the compact IDs 10:35 < willcl_ark> (but very happy to see bandwidth reductions!) 10:35 < raj_149> ariard: well if we only have a finite set of command lists, it makes sense to map them into numbers instead of transmiting them as chars. 10:36 < sipa> willcl_ark: i don't see how those are related at all 10:36 < sipa> the P2P protocol is not an RPC protocol (it's message based, not function call based), and capnproto doesn't do encryption 10:36 < willcl_ark> well the short IDs are basically a protocol spec? 10:36 < willcl_ark> hmmm ok, seemed like defining a protocol for messages to me 10:37 < sipa> you could probably route capnproto over the encrypted stream bip324 defines 10:37 < sipa> but they're fundamentally a very different layer 10:37 < willcl_ark> as in, analagous to how Protobufs encode messages according to a .proto file 10:37 < willcl_ark> sipa: OK 10:37 < sipa> willcl_ark: it's like asking why not use HTTP instead of SSL 10:38 < ariard> raj_149: can you envision what nodes would negotiate a different set of mappings? 10:38 < ariard> *why 10:39 < raj_149> ariard: honestly i couldn't come up with any reason. maybe for some they just need a subset of those so dont wanna assign all the numbers? not sure if its worth the effort though. 10:39 < willcl_ark> sipa: it just seemed to me that e.g. Protobuf kind of does what that massive `if else` statment does, but with a well-defined proto file 10:40 < willcl_ark> but will research it more :) 10:40 < sipa> willcl_ark: bitcoin already has a p2p protocol, we're not proposing to replace it with something else entirely 10:40 -!- davterra [~davterra@209.95.56.84] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 10:40 < ariard> raj_149: well we may have experimentation with new P2P messages, like LN custom messages, I can see people trying to communicate through P2P to their wallets 10:40 < sipa> (or at least, no reason to do that simultaneously with introducing encryption) 10:41 < ariard> especially if we add authentication 10:41 < willcl_ark> sipa: yes I gues you can't just do it for a single part (command) 10:41 < willcl_ark> anyway I'm very much in favour of some bandwidth reductions on this front! 10:41 < ariard> next question: why ChaCha20/Poly1305 were chosen ? have you read implementation 10:41 < lightlike> it could lead to confusion when there are several bips that introduce new p2p messages (that need new numbers). e.g. BIP 157 messages that are merged are not assigned a number yet. 10:42 < sipa> lightlike: a new bip can introduce short numbers for newly introduced messages 10:42 < raj_149> ariard: yes they can use negotiations to add extra *special* messages between them. But these messages still needs to be defined in the protocol right? So they can as well be assigned with short_id there? 10:42 < sipa> so that there doesn't need to be coordination 10:42 < troygiorshev> lightlike: agreed. Might not be too hard to say "just give this the next available number" though 10:42 < willcl_ark> ariard: faster than AES on most CPUs 10:44 < willcl_ark> I think it's better for chips without AES-NI, right? 10:44 < ariard> raj_149: if they are negotiated and protocol is custom, your bandwidth savings priorities may not be equivalent to the default ones 10:45 < ariard> willcl_ark: right for software implementations 10:45 < raj_149> ariard: I am not seeing how bandwidth saving is different in a negotiated short_id than a hardcoded one. 10:46 < raj_149> ariard: on poly1305, why are we using goto in the code? isn't there any better way to do it? for example the donna implementation doesn't seem use it. 10:46 < luke-jr> hi 10:48 < ariard> raj_149: let's say I have my own range of custom messages which make 80% of my traffic, there is no room left in the default short command ID table, by negotiating I can overrules with my own maps and thus save traffic? 10:48 < willcl_ark> ariard: is there another reason that better (faster) performance on average across different CPUs? 10:48 < willcl_ark> than* 10:49 < sipa> raj_149: i assume it's based on the openssh code 10:49 < sipa> https://github.com/openssh/openssh-portable/blob/master/poly1305.c 10:49 < sipa> (i haven't checked) 10:49 < raj_149> ariard: why there wont be any room left in default table if the protocol itself defines the short_ids while defining the command? 10:49 < ariard> willcl_ark: yes it's design have been vetted as more conservative than AES and less prone to cryptographic breakage 10:49 < ariard> *its 10:50 < sipa> ariard: chacha more conservative than aes? 10:50 < ariard> see cryptanalysis table at the end of Salsa20 paper, though I've not compare to ones on AES 10:50 < sipa> i wouldn't say that 10:50 < sipa> it's just faster and more modern, and well-studied 10:50 < sipa> (aes being a block cipher has inherent complexity, which is unnecessary for stream encryption) 10:51 < ariard> sipa: it's claimed by Bernstein in the ChaCha paper, "Salsa20/20 is amore conservative design than AES, and the community seems to have rapidlygained confidence in the security of the cipher." 10:51 < ariard> which should be taken with carefulness 10:51 < sipa> ariard: such claims by the author should be taken with a grain of salt, i think :) 10:51 < sipa> but i guess i see what he means 10:52 < ariard> I completly agree and why I said I've not read cryptanalysis AES to compare 10:52 < sipa> but i wouldn't claim that chacha is more well-analyzed than AES 10:52 < willcl_ark> perhaps, "good enough" (and faster)? 10:53 < troygiorshev> modern and well-analyzed (if not-quite-as-well-analyzed) seems notable 10:53 < willcl_ark> was the alternative AES + CBC? becuase it would seem prefereable over that 10:53 < sipa> AES-GCM would be the typical alternative 10:54 < willcl_ark> ah ok 10:54 < sipa> or AES-CTR-GCM more precisely 10:54 < sipa> AES-CTR is a stream cipher like ChaCha20; GCM is a MAC like Poly1305 10:54 < ariard> raj_149: which protocol are you talking about ? If I experiment with my custom one, it won't be supported by the default implementation 10:55 < willcl_ark> sipe: thanks. I have much cryptography to learn! 10:55 < ariard> next question: how testing can be improved ? what failure cases should be tested? 10:55 < jnewbery> 5 minutes left! 10:55 < raj_149> ariard: ah i see that now. 10:57 < troygiorshev> it's great that fuzzing is already in 10:57 < troygiorshev> a parallel implementation in python could be nice 10:57 < raj_149> ariard: we definitely need functional tests once its fully getched. So far it only implements en/decryption, which seems to be adequately tested in unit test. 10:58 < raj_149> *fetched 10:58 < ariard> troygiorshev: have you looked on fuzz scope ? what kind of cases could be missed by fuzzer? 10:58 < ariard> \ 10:58 < willcl_ark> I couldn't get the fuzz tests to work on MacOS 10.15 :( 10:59 < troygiorshev> ariard: not deeply enough, no. definitely worth doing! 10:59 < willcl_ark> I couldn't see any tests for the re-keying process, but maybe missed them! 10:59 < ariard> last question: could the serialization/deserialization code be better documented or simplified ? have you look on data struct and algorithm choice ? 11:00 < raj_149> i have taken up an issue which will force me to look deeper into fuzzing. Planning to fuzz this once i get there. 11:00 < ariard> willcl_ark: I think the re-keying is still WIP, or at least we need to think about some of its implications 11:00 < willcl_ark> ariard: ah ok 11:01 < jnewbery> that's time! 11:01 < willcl_ark> thanks ariard very interesting discussion 11:01 < jnewbery> Next week's meeting is on 18468, hosted by sipa. Notes will be posted soon: https://bitcoincore.reviews/18468.html. 11:01 < raj_149> thanks ariard, nice review session. 11:01 < thomasb0`> thanks ariard 11:01 < troygiorshev> thanks ariard! 11:01 < jnewbery> See you all there! 11:01 < ariard> great, I invite anyone who hasn't review yet the PR to do it with questions in mind :) 11:01 < emzy> thanks ariard! 11:01 < ariard> yw 11:01 < populate> thanks ariard 11:02 < SirRichard> Thanks ariard great discussion 11:02 < andrewtoth> thanks ariard! very interesting discussion 11:02 < furunodo> thanks! 11:02 -!- SirRichard [~SirRichar@cpe-24-29-169-110.cinci.res.rr.com] has quit [Quit: SirRichard] 11:02 -!- tarboss [~tarboss@p54a03b4a.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 11:03 -!- lightlike [~lightlike@p200300c7ef145c00441b578045803dca.dip0.t-ipconnect.de] has quit [Quit: Leaving] 11:03 < thomasb0`> sipa: what I was thinking about was to pick a random and compute either Euclide, theStack's pow, or the exponential ladder. What do you think? 11:03 < sipa> ... why? 11:03 < thomasb0`> to use several algorithms 11:03 < sipa> why wouldn't you always use the fastest 11:04 < thomasb0`> to track down bugs 11:04 < sipa> the tests already do both 11:04 < thomasb0`> then, no need for change 11:06 -!- figs [566a792d@86.106.121.45] has quit [Remote host closed the connection] 11:07 < furunodo> what's a good place to start for getting into the python test code, beyond bitcoin/test/functional/README.md? say if I wanted to start (or work on) a parallel test implemtation in python? 11:08 < furunodo> (as suggested by troygiorshev) 11:08 < thomasb0`> sipa: btw I was talking about python, only... 11:10 < thomasb0`> furunodo: it looks like you need to be confident to make relevant modifications by yourself 11:10 < sipa> furunodo: that would be the place to start 11:11 < sipa> all the functional python tests are in test/functional (with lots of utilities in test/functional/test_framework) 11:16 -!- surbhi [b757715b@183.87.113.91] has joined #bitcoin-core-pr-reviews 11:20 -!- surbhi [b757715b@183.87.113.91] has quit [Remote host closed the connection] 11:21 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 11:27 -!- surbhi [b757715b@183.87.113.91] has joined #bitcoin-core-pr-reviews 11:29 -!- surbhi [b757715b@183.87.113.91] has quit [Remote host closed the connection] 11:52 -!- populate [~populate@178.162.222.42.adsl.inet-telecom.org] has quit [Quit: populate] 12:00 -!- thomasb0` [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Ping timeout: 258 seconds] 12:00 -!- thomab07 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has quit [Ping timeout: 260 seconds] 12:04 < jnewbery> today's meeting log is posted: https://bitcoincore.reviews/18242.html 12:08 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:13 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 12:13 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:17 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 12:18 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 12:26 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:34 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 12:34 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Client Quit] 12:57 -!- furunodo [~furunodo@185.134.22.207] has quit [Quit: This computer has gone to sleep] 13:10 -!- aqua42 [~aqua42@amsterdam3.jp.net] has joined #bitcoin-core-pr-reviews 13:10 -!- fjahr_ [sid374480@gateway/web/irccloud.com/x-rttuizyvrxqquuxg] has joined #bitcoin-core-pr-reviews 13:10 -!- Landryl6 [~Landryl@ns528256.ip-192-99-10.net] has joined #bitcoin-core-pr-reviews 13:11 -!- jamesob_ [sid180710@gateway/web/irccloud.com/x-zqvulwiyybduvnkg] has joined #bitcoin-core-pr-reviews 13:13 -!- ryanofsky_ [russ@jumpy.yanofsky.org] has joined #bitcoin-core-pr-reviews 13:13 -!- nehan_ [~nehan@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-pr-reviews 13:18 -!- kcud_dab [~arthur@2001:bc8:c087:1001::1] has joined #bitcoin-core-pr-reviews 13:18 -!- Netsplit *.net <-> *.split quits: aqua422, Landryl, fjahr, Jackielove4u, bad_duck, nehan, ryanofsky, jamesob 13:18 -!- jamesob_ is now known as jamesob 13:18 -!- Landryl6 is now known as Landryl 13:18 -!- fjahr_ is now known as fjahr 13:24 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-goiomqmbxxkzsbmd] has joined #bitcoin-core-pr-reviews 13:36 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 246 seconds] 13:36 -!- felixweis [sid154231@gateway/web/irccloud.com/x-lltapfrlamgfxrnm] has quit [Ping timeout: 272 seconds] 13:37 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 13:38 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-axwjvfwwthppwdgd] has quit [Ping timeout: 246 seconds] 13:44 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-qxkrpcnnakptdxdo] has quit [Ping timeout: 260 seconds] 13:52 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-rqanmiudywlppynt] has quit [Ping timeout: 244 seconds] 13:53 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 14:16 -!- furunodo [~furunodo@185.134.22.207] has joined #bitcoin-core-pr-reviews 14:36 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-vfkoqkwnbgxbpgjt] has joined #bitcoin-core-pr-reviews 14:40 -!- felixweis [sid154231@gateway/web/irccloud.com/x-suspeprsccnintnc] has joined #bitcoin-core-pr-reviews 14:40 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-litrsqchavjgbqvk] has joined #bitcoin-core-pr-reviews 14:42 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-orcxygljjkiomkiq] has joined #bitcoin-core-pr-reviews 14:47 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 14:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 14:59 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 15:04 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds] 15:10 -!- yianni [~yianni@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has joined #bitcoin-core-pr-reviews 15:10 -!- yianni is now known as yiannix 15:14 -!- yiannix [~yianni@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has quit [Client Quit] 15:17 -!- YianniG87 [59244134@89.36.65.52] has quit [Remote host closed the connection] 15:28 -!- yiannix [~yiannix@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has joined #bitcoin-core-pr-reviews 15:30 -!- yiannix [~yiannix@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has quit [Client Quit] 15:32 -!- yiannix [~yiannix@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has joined #bitcoin-core-pr-reviews 15:46 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:50 -!- furunodo [~furunodo@185.134.22.207] has quit [Quit: This computer has gone to sleep] 15:58 -!- yiannix [~yiannix@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has quit [Quit: Leaving] 15:59 -!- yiannix [~yiannix@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has joined #bitcoin-core-pr-reviews 16:00 -!- yiannix [~yiannix@2a01:4b00:850f:4500:d50a:4ec9:873c:607a] has quit [Remote host closed the connection] 16:26 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has joined #bitcoin-core-pr-reviews 16:50 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 16:50 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 17:01 -!- slivera [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews 17:11 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 17:12 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 17:41 -!- slivera_ [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews 17:44 -!- slivera [~slivera@103.231.88.10] has quit [Ping timeout: 260 seconds] 17:49 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 17:53 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 256 seconds] 17:56 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 18:14 -!- davterra [~davterra@107.182.233.63] has joined #bitcoin-core-pr-reviews 18:18 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 258 seconds] 18:20 -!- Beta_ [~davterra@107.182.233.63] has joined #bitcoin-core-pr-reviews 18:23 -!- davterra [~davterra@107.182.233.63] has quit [Ping timeout: 256 seconds] 18:34 -!- Beta_ [~davterra@107.182.233.63] has quit [Remote host closed the connection] 18:34 -!- davterra [~davterra@107.182.233.63] has joined #bitcoin-core-pr-reviews 19:15 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 19:16 -!- shesek [~shesek@5.22.128.126] has joined #bitcoin-core-pr-reviews 19:16 -!- shesek [~shesek@5.22.128.126] has quit [Changing host] 19:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 20:16 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 20:42 -!- slivera_ [~slivera@103.231.88.10] has quit [Remote host closed the connection] 21:01 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 21:05 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 21:05 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 21:10 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 258 seconds] 21:21 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 21:24 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 21:24 -!- vasild_ is now known as vasild 21:35 -!- davterra [~davterra@107.182.233.63] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 21:38 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 21:41 -!- davterra [~davterra@107.182.239.139] has joined #bitcoin-core-pr-reviews 22:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 22:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 22:41 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection] 22:41 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 22:46 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds] 22:48 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews 22:52 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 256 seconds] 23:48 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews