From lloyd.fourn at gmail.com Wed Dec 18 03:51:56 2019 From: lloyd.fourn at gmail.com (Lloyd Fournier) Date: Wed, 18 Dec 2019 14:51:56 +1100 Subject: [Lightning-dev] Lightning in a Taproot future In-Reply-To: References: <20191217140229.2s5ymucvewgbl5co@erisian.com.au> Message-ID: Hi ZmnSCPxj and Aj, Thanks for starting this discussion ZmnSCPxj. Although transactions with relative lock times are easily distinguishable today, couldn't this situation be improved? Even just a few wallets changing their behaviour to set relative time locks on normal payments would weaken the heuristic. From a design perspective it feels like leaving the improvement vector open would be better. Aj's model of scriptless lightning is more or less what I had in my mind (but with much better detail). On the question of "script based payment points" or "fully scriptless": Why not just do both? Since the tapscript version is faster to the "irrevocably committed" state, you first do that so you can forward the payment as fast as possible. Now that both parties have a commitment tx with a tapscript PTLC, they can (in no hurry) sign the scriptless spending transactions from the PTLC output. I think once they have signatures on their scriptless PTLC transactions they can forget all the tapscript data (to minimize the data they have to store per commitment tx). > But with taproot you can have a script path as well, so you could have a > script: > A CHECKSIGVERIFY B CHECKSIG > and supply a partial signature: > R+X,s,X where s = r + H(R+X,A,m)*a > to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete > log of X, and of course they can sign with B at any time. This is only > half a round trip, and can be done at the same time as sending the "I > want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig > spend. It's an extra signature on the sender's side and an extra verification > on the receiver's side, but I think it works out fine. This is exactly how I thought the "script based payment point" would work where you just replace the hashing with an CHECKSIG and an adaptor sig. Like Z, I don't see how you can get away with just that though. I think you need to do a full tapscript PTLC and revocation (1.5 round trips) before you can forward a payment. Cheers, LL -------------- next part -------------- An HTML attachment was scrubbed... URL: