12019-11-23T00:09:25  *** achow101 has quit IRC
 22019-11-23T00:19:15  *** achow101 has joined ##taproot-bip-review
 32019-11-23T01:06:33  *** molly has joined ##taproot-bip-review
 42019-11-23T01:09:38  *** mol has quit IRC
 52019-11-23T01:11:07  *** jonatack has joined ##taproot-bip-review
 62019-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`
 72019-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
 82019-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).
 92019-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.
102019-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.
112019-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.
122019-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.
132019-11-23T04:11:50  <harding> gmaxwell: sure, but it's an extra 1.5 rtt times the number of hops in payment.
142019-11-23T04:12:01  <harding> payment path*
152019-11-23T04:12:19  <harding> Gah, extra 1.0 rtt*
162019-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.
172019-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
182019-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.
192019-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.
202019-11-23T04:20:35  <gmaxwell> There are proposals that would allow further reducing the musig round count... though at a fairly high cpu cost.
212019-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.
222019-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)
232019-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!
242019-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.
252019-11-23T04:43:43  <sipa> we should have a paper on the topic in a couple of seeks
262019-11-23T04:44:12  <sipa> *weeks
272019-11-23T04:53:17  * gmaxwell is not part of that we
282019-11-23T05:49:35  *** molly has quit IRC
292019-11-23T05:52:56  *** mol has joined ##taproot-bip-review
302019-11-23T09:01:52  *** schmidty has quit IRC
312019-11-23T09:03:40  *** midnight has quit IRC
322019-11-23T09:04:28  *** schmidty has joined ##taproot-bip-review
332019-11-23T09:16:47  *** midnightmagic has joined ##taproot-bip-review
342019-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.
352019-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)
362019-11-23T10:29:27  *** mryandao has quit IRC
372019-11-23T10:30:11  *** mryandao has joined ##taproot-bip-review
382019-11-23T12:16:37  *** mol has quit IRC
392019-11-23T12:59:33  *** jonatack_ has joined ##taproot-bip-review
402019-11-23T13:03:08  *** jonatack has quit IRC
412019-11-23T13:09:00  *** Chris_Stewart_5 has joined ##taproot-bip-review
422019-11-23T13:51:38  *** Chris_Stewart_5 has quit IRC
432019-11-23T13:53:07  *** rottensox has joined ##taproot-bip-review
442019-11-23T14:10:58  *** pinheadmz_ has joined ##taproot-bip-review
452019-11-23T14:13:17  *** pinheadmz has quit IRC
462019-11-23T14:13:17  *** pinheadmz_ is now known as pinheadmz
472019-11-23T14:24:28  *** shesek has quit IRC
482019-11-23T14:24:56  *** shesek has joined ##taproot-bip-review
492019-11-23T14:24:56  *** shesek has joined ##taproot-bip-review
502019-11-23T14:26:02  *** Chris_Stewart_5 has joined ##taproot-bip-review
512019-11-23T14:40:38  *** Chris_Stewart_5 has quit IRC
522019-11-23T14:44:40  *** orfeas has joined ##taproot-bip-review
532019-11-23T15:03:35  *** shesek has quit IRC
542019-11-23T15:06:09  *** shesek has joined ##taproot-bip-review
552019-11-23T15:06:09  *** shesek has joined ##taproot-bip-review
562019-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
572019-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
582019-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.
592019-11-23T16:01:37  *** shesek has quit IRC
602019-11-23T16:02:33  *** rottensox_ has joined ##taproot-bip-review
612019-11-23T16:04:55  *** rottensox has quit IRC
622019-11-23T16:04:56  *** shesek has joined ##taproot-bip-review
632019-11-23T16:04:56  *** shesek has joined ##taproot-bip-review
642019-11-23T16:07:24  *** rottensox_ is now known as rottensox
652019-11-23T16:08:28  *** shesek has quit IRC
662019-11-23T16:08:56  *** shesek has joined ##taproot-bip-review
672019-11-23T16:08:56  *** shesek has joined ##taproot-bip-review
682019-11-23T16:12:28  *** jonatack_ has quit IRC
692019-11-23T16:13:30  *** jonatack_ has joined ##taproot-bip-review
702019-11-23T16:22:22  *** pinheadmz_ has joined ##taproot-bip-review
712019-11-23T16:25:33  *** pinheadmz has quit IRC
722019-11-23T16:25:33  *** pinheadmz_ is now known as pinheadmz
732019-11-23T16:34:18  *** shesek has quit IRC
742019-11-23T16:35:29  *** shesek has joined ##taproot-bip-review
752019-11-23T16:35:29  *** shesek has joined ##taproot-bip-review
762019-11-23T16:52:42  *** jonatack_ has quit IRC
772019-11-23T16:52:58  *** jonatack has joined ##taproot-bip-review
782019-11-23T16:54:18  *** rottensox_ has joined ##taproot-bip-review
792019-11-23T16:56:42  *** rottensox has quit IRC
802019-11-23T17:34:45  *** orfeas has quit IRC
812019-11-23T17:54:19  *** jonatack has quit IRC
822019-11-23T18:31:04  *** andrewtoth_ has quit IRC
832019-11-23T20:55:18  *** shesek has quit IRC
842019-11-23T20:57:29  *** shesek has joined ##taproot-bip-review
852019-11-23T20:57:34  *** pinheadmz has quit IRC
862019-11-23T20:58:21  *** sosthene has quit IRC
872019-11-23T21:04:15  *** pinheadmz has joined ##taproot-bip-review
882019-11-23T21:04:55  *** sosthene has joined ##taproot-bip-review
892019-11-23T21:27:18  *** rottensox_ is now known as rottensox
902019-11-23T21:41:06  *** Chris_Stewart_5 has joined ##taproot-bip-review
912019-11-23T21:56:08  *** Chris_Stewart_5 has quit IRC
922019-11-23T22:44:33  *** b10c has joined ##taproot-bip-review
932019-11-23T22:54:21  *** jonatack has joined ##taproot-bip-review
942019-11-23T23:11:44  *** rottensox has quit IRC
952019-11-23T23:34:51  *** b10c has quit IRC