--- Day changed Fri Nov 22 2019 00:05 -!- jonatack_ [~jon@37.173.226.226] has quit [Quit: jonatack_] 00:05 -!- jonatack [~jon@37.173.226.226] has joined ##taproot-bip-review 00:52 -!- evoskuil [~evoskuil@c-67-161-88-73.hsd1.wa.comcast.net] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...] 00:56 -!- Aleru [sid403553@gateway/web/irccloud.com/x-uaunxkgpufrmzkyi] has quit [Excess Flood] 00:56 -!- Aleru [sid403553@gateway/web/irccloud.com/x-jessweqstyykwvhy] has joined ##taproot-bip-review 01:04 -!- Aleru [sid403553@gateway/web/irccloud.com/x-jessweqstyykwvhy] has quit [Excess Flood] 01:05 -!- Aleru [sid403553@gateway/web/irccloud.com/x-mlxaoqwcobbmjfex] has joined ##taproot-bip-review 01:33 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 252 seconds] 01:34 -!- aj [aj@cerulean.erisian.com.au] has joined ##taproot-bip-review 02:04 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 245 seconds] 02:27 < nickler> ZmnSCPxj: Interesting attack. I hadn't thought about it before. Seems like proving knowledge of the commitment opening should work in principle, but aggregating them (interactively) seems challenging (what aj said). 02:27 < nickler> The non-transparent variant should be straight forward and is definitely something we want to support in libsecp-zkp. 02:29 < ZmnSCPxj> non-transparent variant...? 02:30 < ZmnSCPxj> If you refer to the "let any participant give any number of `R` commitments and `R` points", is that not "transparent" since it gives an upper bound to the number of members in the aggregate? 02:30 < nickler> non-transparent: where the "outer" musig participants are aware that there are some already MuSig-combined participants 02:31 < ZmnSCPxj> okay, I suppose a disagreement on the exact meaning of "transparent" 02:31 < ZmnSCPxj> Is that distinct from my proposal to just allow multiple `R`s? 02:31 < nickler> no, that's it 02:31 < ZmnSCPxj> yes, it seems straightforward. 02:32 < ZmnSCPxj> Am writing a lengthy article for bitcoin-dev regarding composable MuSig as well as the various variants I considered along the way, mostly just to promote this multiple-`R` extension to the original MuSig protocol. 02:34 < nickler> cool, perhaps you come up with a better name than transparent/non-transparent then :) 02:37 < ZmnSCPxj> multi-`R`? 02:41 < nickler> not bad 02:45 < ZmnSCPxj> Multi-`R`: Random R Redundancy Requirement: Revoking Remote R Repression 02:46 < nickler> ZmnSCPxj: re your privacy application, that seems to work if there's no script spends (otherwise the internal keys will be linkable). If there are no script spends you can directly taproot tweak with without having to add an explicit OP_RETURN tapscript. 02:47 < gmaxwell> FWIW, I knew what transparent ment. :P 02:48 < nickler> Also not clear why needs to have fair contributions because you're trusting every participant anyway for privacy (if everyone knows about their utxos). 02:49 < ZmnSCPxj> I was wondering if there may be Wagnerian attacks possible here, wherein *which* `` is added to *which* transaction might allow one of the participants to actively subvert the protocol and redirect funds to itself alone. 02:49 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review 02:50 < ZmnSCPxj> Basically, this is a CoinJoinXT, so some of the TXOs will be spent by other transactions that will themselves have aggregate-controlled UTXOs 02:50 < ZmnSCPxj> the `` added in a later transactions might be used to Wagner-attack earlier transaction TXOs. 02:51 < ZmnSCPxj> is what I was thinking 02:51 < ZmnSCPxj> Wow, Wagner attack is so dangerous 02:53 < nickler> ah, I don't know about the specifics of CoinJoinXT, but controlling a taproot tweak doesn't enable any (known) wagner attack on taproot outputs. 02:54 < ZmnSCPxj> Yes, but what about transaction outputs that spend other transaction outputs? I admit I have not thought very clearly here, and decided to just be as paranoid as possible and force fair contribution of `` 02:56 < nickler> transaction outputs that spend transaction outputs? 02:56 < ZmnSCPxj> yes 02:57 < ZmnSCPxj> transaction outputs of transactions that spend other transactions outputs --- I mean. 02:57 < ZmnSCPxj> Hmm 02:57 < ZmnSCPxj> However, that is a message 02:57 < nickler> ah 02:58 < ZmnSCPxj> And supposedly if we do the MuSig properly and select `h(R)` and `R` *after* the message is selected, it should be OK, right? 02:59 < nickler> It should be okay. If there was a wagner attack if contributions to random weren't fairly that would be quite surprising. I guess I need to read up on coinjoinxt. bbl 03:01 < ZmnSCPxj> Eh.... belt-and-suspenders, I guess 03:03 -!- molly [~molly@unaffiliated/molly] has joined ##taproot-bip-review 03:05 < orfeas> Hi all, I couldn't find where BIP66 mentions the inherent ECDSA vulnerability (which it should according to the "Motivation" of bip-schnorr). Can someone point me to that mention please? 03:06 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 03:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 03:19 < gmaxwell> orfeas: BIP66 is specific to DER encoding, the malleability related implications are discussed in BIP62 (which is referenced in BIP66) 03:19 < orfeas> gmaxwell: Thanks. Then why do we link to BIP66 in bip-schnorr? 03:22 < gmaxwell> presumably because it got cited by someone who didn't go read BIP66. BIP66 itself only discusses the implementation-definedness criteria, which is also a motivation for bip-schnorr but not one the current text really discusses (though I did open an issue on that) 03:23 -!- ZmnSCPxj [9258463b@146.88.70.59] has quit [Remote host closed the connection] 03:23 < gmaxwell> BIP 146 would be a better reference there. 03:24 < gmaxwell> though I believe it's redundant with BIP62. 03:24 < gmaxwell> too. 03:26 < gmaxwell> BIP66 essentially talks about the fact that there is no guarentee that two distinct ECDSA implementations with the same curve will accept and reject exactly the same signatures. This makes it unusable in a consensus system (without additional restrictions). 03:27 < gmaxwell> (same issue exists for many other production digital signature systems, not just ECDSA) 03:28 < orfeas> I just read the corresponding issue: https://github.com/sipa/bips/issues/110 03:29 < orfeas> I agree that if there is a design target to have everyone reject and accept the same thing, it should be explicitly stated. and a reference to BIP66 is relevant there 03:29 < orfeas> But it isn't relevant where it is now, I think 03:30 < gmaxwell> ( https://github.com/sipa/bips/issues/110 ) 03:33 < gmaxwell> There is some context on 66 that isn't in the BIP too... OpenSSL was, at the time, introducing an exploitable consensus vulnerablity in Bitcoin which BIP66 closed by restricting the DER encodings the software would accept. 03:33 < gmaxwell> (The vulnerablity was that the set of signatures openssl accepted as valid depended on sizeof(long int) or some other typedef that differed on supported platforms) 03:34 < gmaxwell> (so even though all bitcoin nodes used openssl they could be caused to fall out of consensus) 03:34 < gmaxwell> So even though encoding malleability was a big thing that BIP66 helped with, it hardly got discussed in it because our main motivation was making the consensus rules independant of openssl. 03:46 < waxwing> is Zmn's scheme he's describing here, on the mailing list somewhere? i feel like i have to read the initial overall idea before understanding what's been discussed in the scrollback. 03:51 < orfeas> another thing: in "Implicit Y coordinates" we find "(option 2 in the previous design choice)" is there maybe a relevant link, e.g. a past commit? Or the parenthesis is mostly historical cruft that could be removed entirely? 04:20 < waxwing> orfeas, it's referring to the section just above "Encoding R and public key Point P" 04:21 < orfeas> that's much simpler than I thought then! Maybe rephrase it to "(option 2 in the list above)"? At least one person was confused by the current phrasing :P 04:26 -!- jonatack [~jon@37.173.226.226] has quit [Read error: Connection reset by peer] 04:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 05:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 05:44 -!- davterra [~dulyNoded@91.132.136.84] has joined ##taproot-bip-review 06:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 06:24 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 06:24 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 06:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 08:21 -!- jonatack [~jon@37.173.226.226] has joined ##taproot-bip-review 08:26 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 08:29 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 08:31 -!- jonatack_ [~jon@37.165.5.42] has joined ##taproot-bip-review 08:34 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 08:34 -!- jonatack [~jon@37.173.226.226] has quit [Ping timeout: 245 seconds] 08:53 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 09:08 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 09:09 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:09 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:09 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 250 seconds] 09:16 -!- mol [~molly@unaffiliated/molly] has joined ##taproot-bip-review 09:16 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:16 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:16 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:19 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 09:20 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 09:21 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 09:21 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 09:24 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:24 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:26 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 09:29 -!- mol [~molly@unaffiliated/molly] has joined ##taproot-bip-review 09:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 09:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Excess Flood] 09:42 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:42 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:42 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 09:49 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:49 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:49 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 09:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 09:58 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:58 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:58 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:59 < raj_149> just a quick question.. what does it mean to negate a point? In the case where is_square_y() is not true for a point, the musig_aggregate_nonce_point is negated. Is it simply reflecting the point about x axis? what field operation i can do on the y-coordinate to get the negated point? 10:03 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 10:06 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 10:06 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 10:06 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 10:09 < sipa> raj_149: the negative of point (x,y) is simply the point (x,-y) 10:10 < sipa> if you treat coordinates as integers, then negating (x,y) gives (x,p-y), where is the field size (2^256 - 2^32 - 977) 10:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 10:11 < raj_149> ok clear, thanks :) 10:13 < raj_149> also does that mean multiplying the point with (p-1) gives the same result? 10:14 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 10:14 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 10:14 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 10:20 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 10:25 < sipa> raj_149: no, but multiplying with (n-1) does (where n is the curve order) 10:25 -!- jonatack_ [~jon@37.165.5.42] has quit [Quit: jonatack_] 10:25 -!- jonatack [~jon@37.165.5.42] has joined ##taproot-bip-review 10:25 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection] 10:26 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 10:26 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 10:26 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 10:27 < raj_149> okay.. that makes sense.. 10:29 < sipa> raj_149: note that in general it is not true that a*(x,y) = (x,a*y); that is only the case for a=-1 10:30 < sipa> but because scalars you multiply with points are modulo n, and coordinates are modulo p, the -1 outside is equal to n-1, and the -1 inside is equal to p-1 10:30 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 10:32 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 10:32 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 10:32 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 10:33 < raj_149> oh thats pretty neat. Is it always true that the scalars we multiply points with are modulo n? i cant multiply with m > n? 10:34 < raj_149> oh right. in that case it will simply wrap back up with modulo n. 10:36 < sipa> you can multiply with any integer, but multiplying with a, or a-n, or a+n, ... is all the same 10:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 10:37 < sipa> (ignore this if this is too much... there also exist numbers L and B such that L*(x,y) = (B*x,y)) 10:40 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 10:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 276 seconds] 10:48 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 10:48 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 10:48 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 10:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds] 10:55 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:00 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds] 11:02 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:02 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:02 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 11:12 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:12 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:12 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 11:22 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:22 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:22 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 11:30 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:30 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:30 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds] 11:37 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:37 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:37 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:39 -!- jonatack [~jon@37.165.5.42] has quit [Read error: Connection reset by peer] 11:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 11:45 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:45 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:45 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 250 seconds] 11:52 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 11:52 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 11:52 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 11:56 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 12:00 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 12:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 12:10 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 12:10 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 12:10 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 12:15 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 12:18 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 12:18 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 12:18 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 12:23 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 12:25 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 12:25 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 12:25 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 12:30 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 12:33 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 12:33 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 12:33 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 12:38 < devrandom> nickler: why is musig-in-musig relevant to Lightning? so that the funding tx goes to a plain key? 13:00 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds] 13:04 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 13:04 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 13:04 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 13:08 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 13:11 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 13:11 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 13:11 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 13:14 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 13:15 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 13:16 < nickler> devrandom: fundign tx should go to a plain key even without musig-in-musig in a post-schnorr world. It's only a 2-of-2. One application of musig-in-musig I was thinking of is to use a 2-of-(2-of-2) for the lightning funding. 13:17 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 13:17 < nickler> so you can run different lightning implementations in parallel and both have to sign for an update (transparently, without telling the other node that you're doing that) 13:18 < nickler> also ZmnSCPxj's nodelet proposal on the mailing list (which I did not look into yet) 13:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 252 seconds] 13:41 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 13:41 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 13:41 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 13:43 -!- jkczyz [~jkczyz@135.84.132.250] has quit [Quit: leaving] 13:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 13:48 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 13:48 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 13:48 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 13:53 -!- jkczyz [~jkczyz@135.84.132.250] has joined ##taproot-bip-review 13:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 13:58 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 13:58 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 13:58 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 14:00 < devrandom> right, that's what I was also thinking in https://medium.com/@devrandom/securing-lightning-nodes-39410747734b 14:01 < devrandom> nickler: but could keep the outer level a normal on-chain multisig if the nested musig is proving difficult 14:02 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 250 seconds] 14:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 14:03 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 14:03 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 14:03 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 14:08 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 14:13 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 14:13 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 14:13 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 14:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 14:20 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 14:20 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 14:20 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 14:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds] 14:30 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 14:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 14:38 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 14:38 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 14:38 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 14:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 14:45 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 15:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 16:09 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 265 seconds] 16:19 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-bip-review 17:06 -!- molly [~molly@unaffiliated/molly] has joined ##taproot-bip-review 17:09 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:11 -!- jonatack [~jon@37.171.25.26] has joined ##taproot-bip-review 19:37 < 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` 19:37 < 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 19:37 < 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). 20:01 < 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. 20:06 < 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. 20:11 < 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. 20:11 < gmaxwell> If it at lest creates the improvement of making non-cooperative closes less distinguishable then it would be eventually worth doing. 20:11 < harding> gmaxwell: sure, but it's an extra 1.5 rtt times the number of hops in payment. 20:12 < harding> payment path* 20:12 < harding> Gah, extra 1.0 rtt* 20:12 < gmaxwell> yes, but if all the hops are 30ms paths (presumably more typical), then I still don't think that matters. 20:13 < 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 20:16 < 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. 20:18 < 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:20 < gmaxwell> There are proposals that would allow further reducing the musig round count... though at a fairly high cpu cost. 20:21 < 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. 20:22 < gmaxwell> thats consistent with what I expected. (well okay, if you had one/few long ones I wouldn't be surprised) 20:24 < 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! 20:27 < gmaxwell> (the cpu intensive thing is to send a ZKP that you generated your nonce faithfully according a specified determinstic procedure. 20:43 < sipa> we should have a paper on the topic in a couple of seeks 20:44 < sipa> *weeks 20:53 * gmaxwell is not part of that we 21:49 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds] 21:52 -!- mol [~molly@unaffiliated/molly] has joined ##taproot-bip-review