Lightning in a Taproot future



Summary:

The discussion revolves around improving transactions with relative lock times, which are currently distinguishable. A suggestion is made to improve the situation by having a few wallets change their behavior to set relative time locks on normal payments in order to weaken the heuristic. The idea of leaving the improvement vector open is also considered. Aj's model of scriptless lightning is discussed, with the suggestion of implementing both "script based payment points" and "fully scriptless" options. It is proposed that tapscript version should be used first because it is faster to the "irrevocably committed" state, after which scriptless spending transactions from the PTLC output can be signed at a later stage. The use of taproot for a script path is suggested, where a partial signature is supplied to allow satisfying "A CHECKSIGVERIFY" if the discrete log of X is known. The concept of a "script based payment point" is also discussed, but it is suggested that a full tapscript PTLC and revocation must be done before forwarding a payment.


Updated on: 2023-06-02T22:12:08.206300+00:00