[Lightning-dev] Lightning in a Taproot future
lloyd.fourn at gmail.com
Wed Dec 18 03:51:56 UTC 2019
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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lightning-dev