1 2019-11-23T00:09:25  *** achow101 has quit IRC
 2 2019-11-23T00:19:15  *** achow101 has joined ##taproot-bip-review
 3 2019-11-23T01:06:33  *** molly has joined ##taproot-bip-review
 4 2019-11-23T01:09:38  *** mol has quit IRC
 5 2019-11-23T01:11:07  *** jonatack has joined ##taproot-bip-review
 6 2019-11-23T03:37:28  <harding> A question about LN as related to https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da : am I correct in understanding that this means routing LN payments will require an extra (TCP/IP) network round trip compare to the current protocol?  E.g., IIUC, the current protocol is Alice sends Bob an `update_add_htlc` message with the details of the output she wants to pay, Bob replies with a `commitment_signed`
 7 2019-11-23T03:37:28  <harding> message containing details of the updated commitment transaction and a signature, then Alice forwards the onion packet to Bob for further processing---1.5 round trips total.  Based on nickler's article, it seems to me the revised protocol would be something like: Alice and Bob pre-share their next nonce commitments; then when routing a payment, Alice sends Bob an `update_add_htlc` message (same as before), Bob replies with a
 8 2019-11-23T03:37:28  <harding> new `commitment_nonce` message with his nonce plus the details of the updated commitment transaction, Alice replies with her nonce, Bob replies with his partial signature.  Alice can then forward the onion packet---2.5 round trips total on the critical path (i.e. ignoring the pre-shared nonce commitments).
 9 2019-11-23T04:01:56  <gmaxwell> That sound likely. The schnorr multisignature requires addition round trip(s)-- how many exactly depends on what presharing you can do, who initiates, etc.
10 2019-11-23T04:06:45  <harding> Yeah.  Thinking about it some more, I realized that maybe what they'd do in practice is have a taproot branch with 2-of-2 via tapscript so that they can keep the current protocol; then they only do the extra round trips for a mutual close.
11 2019-11-23T04:11:01  <gmaxwell> performance wise though it shouldn't be a problem-- I mean the maximum rtt worldwide on the internet is 250-ish ms... 800ms if you include geosync links maybe.   But it is certantly a software engineering overhead.
12 2019-11-23T04:11:48  <gmaxwell> If it at lest creates the improvement of making non-cooperative closes less distinguishable then it would be eventually worth doing.
13 2019-11-23T04:11:50  <harding> gmaxwell: sure, but it's an extra 1.5 rtt times the number of hops in payment.
14 2019-11-23T04:12:01  <harding> payment path*
15 2019-11-23T04:12:19  <harding> Gah, extra 1.0 rtt*
16 2019-11-23T04:12:27  <gmaxwell> yes, but if all the hops are 30ms paths (presumably more typical), then I still don't think that matters.
17 2019-11-23T04:13:59  <harding> Yeah, maybe.  I was thinking closer to 100 ms, so an extra ~1 second delay, but I have no data on ping times.  /me goes off to ping his own peers now
18 2019-11-23T04:16:12  <gmaxwell> all the way cross the US, from seattle to boston is about 80ms round trip. Thats more or less the highest RTTs you get within a contry in the developed world, excluding sat links and other weirdness.
19 2019-11-23T04:18:36  <harding> No argument.  I'm just not sure people are choosing peers for their low ping times (I don't think there's any incentive for that, not even in the current generation of autopilots), so you would seem to be likely to end up with a fair number of intercontinental channel peers.
20 2019-11-23T04:20:35  <gmaxwell> There are proposals that would allow further reducing the musig round count... though at a fairly high cpu cost.
21 2019-11-23T04:21:25  <harding> Most of my peers seem to be behind NAT, but all the ones I did contact had a rtt of less than 20 ms.  Anecdotal data, but quite different than what I expected.
22 2019-11-23T04:22:02  <gmaxwell> thats consistent with what I expected. (well okay, if you had one/few long ones I wouldn't be surprised)
23 2019-11-23T04:24:38  <harding> In any case, it seems like a non-issue to me now.  I like that they could conceivably use a script-path spend (or maybe the fancy CPU intensive thing) on slow links and musig for additional space savings on fast links.  Thanks!
24 2019-11-23T04:27:55  <gmaxwell> (the cpu intensive thing is to send a ZKP that you generated your nonce faithfully according a specified determinstic procedure.
25 2019-11-23T04:43:43  <sipa> we should have a paper on the topic in a couple of seeks
26 2019-11-23T04:44:12  <sipa> *weeks
27 2019-11-23T04:53:17  * gmaxwell is not part of that we
28 2019-11-23T05:49:35  *** molly has quit IRC
29 2019-11-23T05:52:56  *** mol has joined ##taproot-bip-review
30 2019-11-23T09:01:52  *** schmidty has quit IRC
31 2019-11-23T09:03:40  *** midnight has quit IRC
32 2019-11-23T09:04:28  *** schmidty has joined ##taproot-bip-review
33 2019-11-23T09:16:47  *** midnightmagic has joined ##taproot-bip-review
34 2019-11-23T10:02:22  <nickler> harding: I don't think that it would need an additional roundtrip. In your example, Alice sends her nonce along with the `update_add_htlc` message and Bob can reply with both his nonce and his partial signature in a single message.
35 2019-11-23T10:04:53  <nickler> The scriptless scripts multi-hop locks writeup should clarify how to deal with MuSig rounds https://github.com/ElementsProject/scriptless-scripts/pull/6 (but I'm certainly no expert on the BOLTs)
36 2019-11-23T10:29:27  *** mryandao has quit IRC
37 2019-11-23T10:30:11  *** mryandao has joined ##taproot-bip-review
38 2019-11-23T12:16:37  *** mol has quit IRC
39 2019-11-23T12:59:33  *** jonatack_ has joined ##taproot-bip-review
40 2019-11-23T13:03:08  *** jonatack has quit IRC
41 2019-11-23T13:09:00  *** Chris_Stewart_5 has joined ##taproot-bip-review
42 2019-11-23T13:51:38  *** Chris_Stewart_5 has quit IRC
43 2019-11-23T13:53:07  *** rottensox has joined ##taproot-bip-review
44 2019-11-23T14:10:58  *** pinheadmz_ has joined ##taproot-bip-review
45 2019-11-23T14:13:17  *** pinheadmz has quit IRC
46 2019-11-23T14:13:17  *** pinheadmz_ is now known as pinheadmz
47 2019-11-23T14:24:28  *** shesek has quit IRC
48 2019-11-23T14:24:56  *** shesek has joined ##taproot-bip-review
49 2019-11-23T14:24:56  *** shesek has joined ##taproot-bip-review
50 2019-11-23T14:26:02  *** Chris_Stewart_5 has joined ##taproot-bip-review
51 2019-11-23T14:40:38  *** Chris_Stewart_5 has quit IRC
52 2019-11-23T14:44:40  *** orfeas has joined ##taproot-bip-review
53 2019-11-23T15:03:35  *** shesek has quit IRC
54 2019-11-23T15:06:09  *** shesek has joined ##taproot-bip-review
55 2019-11-23T15:06:09  *** shesek has joined ##taproot-bip-review
56 2019-11-23T15:34:29  <harding> nickler: in the current protocol, as I understand it, Alice might send multiple `update_add_htlc` messages to Bob before Bob returns a signature (see https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation).  Would it be safe to allow Bob to choose which update he generates a partial signature for?  E.g., A & B have a series of pre-shared nonce commitment pairs so that they can use a
57 2019-11-23T15:34:29  <harding> different nonce in each update.  For update_0, Alice sends the message and her nonce, but Bob doesn't reply immediately.  Alice receives another HTLC to route (update_1), sends the message and the next nonce in the series of pre-committed nonces, and now Bob has two messages each with a different nonce from Alice.  Bob can choose either message and its associated nonce, so he can (per your blog post) "choose the message after
58 2019-11-23T15:34:29  <harding> the combined public nonce is known and is therefore able to bias the hash function".  Admittedly, Bob can only choose messages from the values Alice sent him and he gets whatever nonce comes with them (derived from his and Alice's pre-committed nonces), so he's much more limited in his selection than if he was able to brute force locally, but it still feels to me like a variation on the attack you describe.
59 2019-11-23T16:01:37  *** shesek has quit IRC
60 2019-11-23T16:02:33  *** rottensox_ has joined ##taproot-bip-review
61 2019-11-23T16:04:55  *** rottensox has quit IRC
62 2019-11-23T16:04:56  *** shesek has joined ##taproot-bip-review
63 2019-11-23T16:04:56  *** shesek has joined ##taproot-bip-review
64 2019-11-23T16:07:24  *** rottensox_ is now known as rottensox
65 2019-11-23T16:08:28  *** shesek has quit IRC
66 2019-11-23T16:08:56  *** shesek has joined ##taproot-bip-review
67 2019-11-23T16:08:56  *** shesek has joined ##taproot-bip-review
68 2019-11-23T16:12:28  *** jonatack_ has quit IRC
69 2019-11-23T16:13:30  *** jonatack_ has joined ##taproot-bip-review
70 2019-11-23T16:22:22  *** pinheadmz_ has joined ##taproot-bip-review
71 2019-11-23T16:25:33  *** pinheadmz has quit IRC
72 2019-11-23T16:25:33  *** pinheadmz_ is now known as pinheadmz
73 2019-11-23T16:34:18  *** shesek has quit IRC
74 2019-11-23T16:35:29  *** shesek has joined ##taproot-bip-review
75 2019-11-23T16:35:29  *** shesek has joined ##taproot-bip-review
76 2019-11-23T16:52:42  *** jonatack_ has quit IRC
77 2019-11-23T16:52:58  *** jonatack has joined ##taproot-bip-review
78 2019-11-23T16:54:18  *** rottensox_ has joined ##taproot-bip-review
79 2019-11-23T16:56:42  *** rottensox has quit IRC
80 2019-11-23T17:34:45  *** orfeas has quit IRC
81 2019-11-23T17:54:19  *** jonatack has quit IRC
82 2019-11-23T18:31:04  *** andrewtoth_ has quit IRC
83 2019-11-23T20:55:18  *** shesek has quit IRC
84 2019-11-23T20:57:29  *** shesek has joined ##taproot-bip-review
85 2019-11-23T20:57:34  *** pinheadmz has quit IRC
86 2019-11-23T20:58:21  *** sosthene has quit IRC
87 2019-11-23T21:04:15  *** pinheadmz has joined ##taproot-bip-review
88 2019-11-23T21:04:55  *** sosthene has joined ##taproot-bip-review
89 2019-11-23T21:27:18  *** rottensox_ is now known as rottensox
90 2019-11-23T21:41:06  *** Chris_Stewart_5 has joined ##taproot-bip-review
91 2019-11-23T21:56:08  *** Chris_Stewart_5 has quit IRC
92 2019-11-23T22:44:33  *** b10c has joined ##taproot-bip-review
93 2019-11-23T22:54:21  *** jonatack has joined ##taproot-bip-review
94 2019-11-23T23:11:44  *** rottensox has quit IRC
95 2019-11-23T23:34:51  *** b10c has quit IRC