ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-15 📝 Original message: Good morning list, I ...
📅 Original date posted:2019-12-15
📝 Original message:
Good morning list,
I would like to initiate some discussion on how Lightning could be updated to take advantage of the upcoming taproot update to the base layer.
For now, I am assuming the continued use of the existing Poon-Dryja update mechanism.
Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and its details seem less settled for now than taproot details.
* [ ] We could update the current Poon-Dryja mechanism to use Schnorr signatures.
* [ ] Or we could just keep the current Poon-Dryja mechanism with SegWit v0 only, and only update to Schnorr / SegWit v1 when we can implement Decker-Russell-Osuntokun.
* This brings up the question as to whether we will allow Poon-Dryja to host pointlocked-timelocked contracts (i.e. the Scriptless Script replacement of HTLCs that uses payment points+scalars).
* [ ] We could constrain Poon-Dryja channels to only HTLCs.
* This might be simpler for implementations: implementations could have a completely new module that implements Decker-Russell-Osuntokun with HTLCs and PTLCs, and not touch existing modules for Poon-Dryja with HTLCs only.
* We could "retire" Poon-Dryja constructions at some point and only add new features to Decker-Russell-Osuntokun channels.
* [ ] We could allow hosting PTLCs as well on Poon-Dryja channels, as nothing in the base layer prevents a transaction from providing both SegWit v0 and SegWit v1 outputs anyway.
Poon-Dryja with Schnorr
-----------------------
If we decide to update the current Poon-Dryja mechanism to use Schnorr, there are some wrinkles:
* [ ] We could just drop-in replace the signing algorithm with Schnorr.
* We would define a NUMS point to be used as Taproot internal key, and use a single tapscript that is simply the current script template.
* This is arguably not really taking advantage of the Schnorr and Taproot features, however.
* [ ] Or we could use some sort of MuSig between the two channel participants.
The latter option is probably what we want to use, as it potentially allows a channel close to be indistinguishable from an ordinary SegWit v1 spend of a UTXO.
Even for channels that have been published via gossip, it moves the onus of storing historical data about historically-published channels from base layer fullnodes to nodes that want to surveill the network.
### Digression: 2-of-2 is Obviously Lightning
Existing 2-of-2 outputs have a very high probability of being Lightning Network channels.
Thus, someone who wishes to surveill the Lightning Network can simply query any archive fullnode for historical 2-of-2 outputs and have a good chance that those are Lightning Network channels.
Consider the adage: Never go to sea with two chronometers; take one or three.
https://en.wikipedia.org/wiki/Dual_modular_redundancy
This implies that ordinary HODL usage of transaction outputs will either use 1-of-1, or 2-of-3.
Offchain techniques, on the other hand, are only safe (trustless) if they are n-of-n, and are only usefully multi-participant if n > 1.
https://zmnscpxj.github.io/offchain/safety.html
Thus any n-of-n is likely to be an offchain protocol, with the most likely being the most widespread offchain protocol, Lightning Network.
Thus, the hyperbole "2-of-2 is Obviously Lightning".
However, we can "hide" 2-of-2 in a 2-of-3, which can be done by generating a third point from a NUMS point plus a random tweak generated by both participants.
Better yet, MuSig allows hiding any n-of-n among 1-of-1; we expect 1-of-1 use to dominate in the foreseeable future, thus MuSig usage maximizes our anonymity set.
### End Digression
A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.
In the current Poon-Dryja setup we have, in order to completely sign the commitment transaction held by one participant, we only require sending a completed signature from the remote participant via `commitment_signed`.
Then the local participant issues a `revoke_and_ack` to reassure the remote side that the previous commitment it held is now revoked.
Thus, the signing itself requires only 0.5 round trips.
MuSig requires three rounds to complete the signing protocol.
Since Poon-Dryja only require the complete set of signatures for any particular commitment transaction to be owned by only one participant (i.e. Poon-Dryja commitment transactions are asymmetrical), MuSig only requires 2.5 round trips to sign a Poon-Dryja commitment.
Reducing the round trips is desirable when considering latency, which affects the experienced speed of forwarding, as well as the backwards propagation of failures (but not of successful payments).
Currently, latency on the network is known to be very low, but I observe that most Lightning Network participants today have excellent Internet connectivity, which might not be true in the foreseeable future.
We can reduce the round trips to 1.5 per commitment, except for the initial commitment transaction, by sending the `R` precommitments (the first phase of MuSig) of the *next* signing session while sending the `s` for the *current* signing session.
Finally, we can consider to reduce the use of MuSig via various techniques.
One technique is the use of fast forwards: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
The other involves using Taproot.
The taproot internal pubkey is the MuSig of both participants, but we also add an explicit 2-of-2 as a tapscript (or hide the 2-of-2 in a 2-of-3), i.e. `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG` in a tapscript.
This allows commitment transactions to use the tapscript path and have separate signatures for both participants.
Then, mutual close uses the MuSig keypath spend.
This reduces the changes relative to the current Poon-Dryja implementation: we can continue to use `commitment_signed` messages (or equivalent new ones for Taproot-based Poon-Dryja channels), and only the mutual close ritual needs to be modified to use MuSig.
Thus the options are below, but ***please do not select an option yet***, because further sections greatly affect the tradeoffs of the options below.
* [ ] Latency is not an issue (even in the foreseeable future), just use the 2.5 round trips for MuSig and MuSig-sign every commitment.
* [ ] Pre-send the `R` commitments with the previous `s`.
* This increases the needed storage requirements of both nodes, and possibly complexity of node software, but reduces the round trips to 1.5.
* This usage may need to have larger bounds than what may be naively expected, if we decide to use Multi-`R` composable MuSig (see later section).
* Even *without* this option, at the minimum we still need to store `R` commitments and `R`, at least in memory, until we complete the MuSig ritual.
* [ ] Use fast-forwards.
* This removes the latency of commitment transaction signing from the forwarding and failure-reporting paths.
* *Improved* forwarding and failure-reporting latency compared to today (revocation and signature not needed for forwarding/failure-reporting).
* Latency is still high for commitment transaction signing, but this is less of an issue as it is no longer in the forwarding/failure-reporting path.
* [ ] Explicit 2-of-2 for commitment, MuSig for mutual close.
* No degradation in latency compared to today (0.5 round trips for signature, additional 1 round trip for signalling and revocation).
* No improvement (or degradation) of privacy for unilateral closes compared to today, but improved privacy for mutual closes.
* An argument *for* this option is that unilateral closes (commitment transactions) have special scripts on their outputs anyway, thus still leak their privacy, but see later sections for how Taproot may help reduce the uniqueness of those outputs, thus *not* taking this option may still improve privacy for unilateral closes.
Composable MuSig
----------------
As I describe here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017493.html
In that write-up, I mention the use-case of nodelets.
Another use-case is for redundant hardware signers: https://lists.ozlabs.org/pipermail/c-lightning/2019-December/000172.html
We have the option of allowing for a composable MuSig, probably my multi-`R` proposal, where each participant may send one or more `R` commitments and subsequent `R`s.
* [ ] Not use composable MuSig of any kind, at least for now.
* Possibly we could defer the use of a composable MuSig when a better composable MuSig (with security proofs) has been derived.
* [ ] Use Multi-`R` composable MuSig.
* We need to probably impose some limit on the number of `R` commitments that can be sent: _____ `R`s maximum.
The latter option above affects the previous choice regarding whether to pre-send `R` commitments with the previous `s` sending, as this increases the maximal storage requirement for the pre-sent `R` commitment(s).
Pointlocked Timelocked Contracts
--------------------------------
I would have preferred to keep this in a separate discussion thread, however the exact details of PTLCs may affect our decision on how to sign commitment transactions.
PTLCs are necessary to switch the Lightning Network to payment point+scalar, and indeed one can argue that the entire point of enabling Schnorr and Taproot at the base layer is to allow us to use payment point+scalar at the Lightning layer.
First, I will discuss how to create a certain kind of PTLCs, which I call "purely scriptless" PTLCs.
In particular, I would like to point out that we *actually* use in current Poon-Dryja Lightning Network channels is *revocable* HTLCs, thus we need to have *revocable* PTLCs to replace them.
* First, we must have a sender A, who is buying a secret scalar, and knows the point equivalent to that scalar.
* Second, we have a receiver B, who knows this secret scalar (or can somehow learn this secret scalar).
* A and B agree on the specifications of the PTLC: the point, the future absolute timelock, the value.
* A creates (but *does not* sign or broadcast) a transaction that pays to a MuSig of A and B and shares the txid and output number with the relevant MuSig output.
* A and B create a backout transaction.
* This backout has an `nLockTime` equal to the agreed absolute timelock.
* It spends the above MuSig output (this input must enable `nLockTime`, e.g. by setting `nSequence` to `0xFFFFFFFE`).
* It creates an output that is solely controlled by A.
* A and B perform a MuSig ritual to sign the backout transaction.
* A now signs and broadcast the first transaction, the one that has an output that represents the PTLC.
* A and B wait for the above transaction to confirm deeply.
This completes the setup phase for the PTLC.
* After this point, if the agreed-upon locktime is reached, A broadcasts the backout transaction and aborts the ritual.
* A and B create a claim transaction.
* This has an `nLockTime` of 0, or a present or past blockheight, or disabled `nLockTime`.
* This spends the above MuSig output.
* This creates an output that is solely controlled by B.
* A and B generate an adaptor signature for the claim transaction, which reveals the agreed scalar.
* This is almost entirely a MuSig ritual, except at `s` exchange, B provides `t + r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` first, then demands `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, A) * a` from A, then reveals `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` (or the completed signature, by publishing onchain), revealing the secret scalar `t` to A.
* A is able to learn the secret scalar from the above adaptor signature followed by the full signature, completing the ritual.
Note that the above ritual is "purely scriptless".
It is possible to take advantage of taproot to create a tapscript equivalent to `<agreed locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP <A> OP_CHECKSIG`.
This removes the need to perform a MuSig ritual to sign a backout transaction: A can generate the backout transaction all by itself.
This use is not purely scriptless, as the timelocked branch is controlled by a tapscript that is hidden in the pointlocked branch, meaning that taking the timelocked branch reveals the contract.
The tradeoff is that if we use "purely scriptless" PTLCs:
* If we have purely scriptless PTLCs, then even the timelock branch is potentially indistinguishable from ordinary spends.
* We should note that Bitcoin Core itself already uses the current blockheight plus 1 for `nLockTime` when spending, instead of a 0 or disabled `nLockTime`.
* If the above habit were more widespread (i.e. if all wallets implemented the use of a current `nLockTime` for ordinary onchain spends) then the timelock branch has an anonymity set equal to all Schnorr keypath spends, as the `nLockTime` is always used anyway.
* Other kinds of offchain protocols may also utilize this technique, slightly increasing the anonymity set as well.
Thus, the use of the current blockheight plus 1 for `nLockTime` should be recommended for improved privacy in Bitcoin anyway.
* However, purely scriptless PTLCs require a complete MuSig ritual (2.5 to 3 round trips!) to sign the timelocked branch (the initial backout transaction); this increases the latency of adding new PTLCs.
* Of note is that in the case of Lightning, we may need to add a new PTLC while another PTLC is *still* in-flight; on the new commitment transaction, we need to redo the MuSig rituals to create new backouts and new adaptor signtures for each PTLC.
* This can be amortized such that we redo all the rituals for all existing PTLCs in parallel.
* The use of multi-`R` composable MuSig greatly increases the storage requirements as well!
* Further, the privacy gained in the timelock path is degraded or lost when we consider revocable PTLCs and revocable outputs.
* It is not clear to me as fo now if the MuSig ritual for the backout transaction must complete in full before the MuSig ritual for the claim transaction (the pointlocked branch, which includes sharing an adaptor signature during `s` exchange).
* If we can do these two rituals in parallel, this reduces the latency disadvantage of the purely scriptless PTLC to just 1 round trip compared to the tapscripted timelock branch PTLC.
* Possibly the adaptor signature ritual could stop until B provides the adaptor signature, then full `s` exchange is deferred to after the PTLC 2-of-2 is instantiated onchain/reified in a commitment transaction.
Thus our options are the below, but again, you should defer deciding on the best option until you understand about revocable PTLCs.
* [ ] We can use a purely scriptless PTLC construction.
* Better privacy, but increased latency.
* [ ] We can use a tapscripted timelock branch and a keypath pointlocked branch for the PTLC.
* Lower latency, but possibly reduced privacy advantage in the timelock branch (privacy advantage still exists in the pointlocked branch, which we hope is more common anyway).
Revocable Outputs and PTLCs
---------------------------
Poon-Dryja mechanism is based on revocation of contracts instantiated from previous states.
Thus, all outputs of Poon-Dryja must be made revocable.
At a high-enough level, this only requires the addition of a `(revocation_secret && remote_secret) || (CSV && L)` to the top-level logic (`L`) of a contract.
Of course, the details have the devil.
Now, in Poon-Dryja, each side of the channel has its own commitment transaction.
Thus, contracts on the commitment transaction refer to a "local side" and a "remote side".
The "local side" is whoever is holding the completely-signed commitment transaction, while the "remote side" is the other side.
Revocable outputs always have a CSV-requirement before the output can be spent by whoever "should" own the output, according to the contract details.
The revocation secret is known by the local side, and then when a *new* commitment transaction has been signed, the revocation secret is given by the local side to the remote side, allowing all outputs to be spent directly by the remote side if an old, revoked commitment transaction is published onchain.
There are many ways to implement revocable outputs.
The core idea of revocable outputs, however, is that there must exist some relative-locktime branch on each output that goes to the local side.
This relative-locktime branch can be implemented as "purely scriptless" by using a 2-of-2 of both the local and remote sides, with a relative-locktime `nSequence`, using the same technique as described in the previous section.
However, unlike the absolute-locktime `nLockTime` for the timelock branches of PTLCs, ***there is no current wallet software that uses activated-relative-locktime `nSequence` for ordinary spends***.
Thus, any use of the relative-locktime branch does *not* have a privacy advantage under purely scriptless.
Thus the tradeoffs here are different, and definitely in favor of the tapscripted-relative-locktime technique.
* There is no current wallet software that uses relative locktimes.
* Bitcoin Core uses absolute locktimes with the current blockheight plus 1, and we can hide the use of absolute locktimes by imitating this Bitcoin Core behavior.
* Any use of relative locktimes is a strong signal of some kind of complicated offchain updateable mechanism.
We can note as well that Decker-Russell-Osuntokun also uses relative locktimes.
* The relative-locktime branch in revocable outputs is the **desirable** case, because taking the relative locktime means that the commitment transaction published *was not* a revoked transaction (i.e. it was the latest transaction version).
* Thus, it would be nice if this had good privacy.
* However, this *cannot* have good privacy since there is no current common use of activated relative locktimes for ordinary spends.
The latter point above also biases us towards rejecting purely-scriptless in the *previous* section, in particular:
* The absolute-locktime branch in the PTLC is the **undesirable** case, where the payee B somehow stops responding to A.
* In particular, propagating failure backwards is done by simply deleting PTLCs, thus the absolute-locktime branch does not come into play during payment failure.
* Thus, the privacy increase of hiding absolute-locktime branches is minor, and the privacy breach of revocable outputs (i.e. it leaks the use of relative-locktime, and nearly all uses of relative locktime will be offchain updateable cryptocurrency mechanisms, such as Poon-Dryja or Decker-Russell-Osuntokun) is arguably much larger than the privacy increase of purely-scriptless absolute-locktime.
Of particular not is that if a PTLC is instantiated on the commitment transaction of the payer A, then the absolute-locktime backout transaction must *not* pay to A only, but instead pays to a *revocable output* that will eventually pay to A after the relative locktime.
Thus, the privacy boost of the purely-scriptless backout transaction would be lost by the later revelation of the use of a relative locktime after the revocable output is reclaimed by A.
Again, that use of relative locktime (whether enforced by script, or by scriptless use of a 2-of-2 that is spent with an activated relative-locktime `nSequence`) is a strong indicator of the use of Poon-Dryja or Decker-Russell-Osuntokun or even Decker-Wattenhofer mechanisms, and the logic is that since Lightning Network is the most widespread offchain mechanism, it probably indicates the use of LN.
Thus the decision in the previous section is affected by this reality that we in fact need *revocable* PTLCs, not plain PTLCs, thus the advantage of purely-scriptless backout transactions in the previous section is reduced by the need to make outputs revocable.
Thus:
* Revocable outputs require a relative-timelock branch.
* That branch is the **desirable** branch, i.e. the latest commitment transaction is the one that got published and thus is *not* revoked.
* We thus expect this relative-timelock branch to be the *common* branch.
* No wallet uses relative-timelock for ordinary spends, unlike abolute-locktime where Bitcoin Core always uses absolute-locktime `nLockTime` for ordinary spends.
* Thus, using purely scriptless for the relative-timelock branch of revocable outputs does not in fact hide that we are doing something special.
Conclusion
----------
Others may find further issues or alternative options for the above points.
Further discussion may be warranted before we actually select particular options to implement and evaluate in alpha software.
Regards,
ZmnSCPxj
📝 Original message:
Good morning list,
I would like to initiate some discussion on how Lightning could be updated to take advantage of the upcoming taproot update to the base layer.
For now, I am assuming the continued use of the existing Poon-Dryja update mechanism.
Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and its details seem less settled for now than taproot details.
* [ ] We could update the current Poon-Dryja mechanism to use Schnorr signatures.
* [ ] Or we could just keep the current Poon-Dryja mechanism with SegWit v0 only, and only update to Schnorr / SegWit v1 when we can implement Decker-Russell-Osuntokun.
* This brings up the question as to whether we will allow Poon-Dryja to host pointlocked-timelocked contracts (i.e. the Scriptless Script replacement of HTLCs that uses payment points+scalars).
* [ ] We could constrain Poon-Dryja channels to only HTLCs.
* This might be simpler for implementations: implementations could have a completely new module that implements Decker-Russell-Osuntokun with HTLCs and PTLCs, and not touch existing modules for Poon-Dryja with HTLCs only.
* We could "retire" Poon-Dryja constructions at some point and only add new features to Decker-Russell-Osuntokun channels.
* [ ] We could allow hosting PTLCs as well on Poon-Dryja channels, as nothing in the base layer prevents a transaction from providing both SegWit v0 and SegWit v1 outputs anyway.
Poon-Dryja with Schnorr
-----------------------
If we decide to update the current Poon-Dryja mechanism to use Schnorr, there are some wrinkles:
* [ ] We could just drop-in replace the signing algorithm with Schnorr.
* We would define a NUMS point to be used as Taproot internal key, and use a single tapscript that is simply the current script template.
* This is arguably not really taking advantage of the Schnorr and Taproot features, however.
* [ ] Or we could use some sort of MuSig between the two channel participants.
The latter option is probably what we want to use, as it potentially allows a channel close to be indistinguishable from an ordinary SegWit v1 spend of a UTXO.
Even for channels that have been published via gossip, it moves the onus of storing historical data about historically-published channels from base layer fullnodes to nodes that want to surveill the network.
### Digression: 2-of-2 is Obviously Lightning
Existing 2-of-2 outputs have a very high probability of being Lightning Network channels.
Thus, someone who wishes to surveill the Lightning Network can simply query any archive fullnode for historical 2-of-2 outputs and have a good chance that those are Lightning Network channels.
Consider the adage: Never go to sea with two chronometers; take one or three.
https://en.wikipedia.org/wiki/Dual_modular_redundancy
This implies that ordinary HODL usage of transaction outputs will either use 1-of-1, or 2-of-3.
Offchain techniques, on the other hand, are only safe (trustless) if they are n-of-n, and are only usefully multi-participant if n > 1.
https://zmnscpxj.github.io/offchain/safety.html
Thus any n-of-n is likely to be an offchain protocol, with the most likely being the most widespread offchain protocol, Lightning Network.
Thus, the hyperbole "2-of-2 is Obviously Lightning".
However, we can "hide" 2-of-2 in a 2-of-3, which can be done by generating a third point from a NUMS point plus a random tweak generated by both participants.
Better yet, MuSig allows hiding any n-of-n among 1-of-1; we expect 1-of-1 use to dominate in the foreseeable future, thus MuSig usage maximizes our anonymity set.
### End Digression
A potential issue with MuSig is the increased number of communication rounds needed to generate signatures.
In the current Poon-Dryja setup we have, in order to completely sign the commitment transaction held by one participant, we only require sending a completed signature from the remote participant via `commitment_signed`.
Then the local participant issues a `revoke_and_ack` to reassure the remote side that the previous commitment it held is now revoked.
Thus, the signing itself requires only 0.5 round trips.
MuSig requires three rounds to complete the signing protocol.
Since Poon-Dryja only require the complete set of signatures for any particular commitment transaction to be owned by only one participant (i.e. Poon-Dryja commitment transactions are asymmetrical), MuSig only requires 2.5 round trips to sign a Poon-Dryja commitment.
Reducing the round trips is desirable when considering latency, which affects the experienced speed of forwarding, as well as the backwards propagation of failures (but not of successful payments).
Currently, latency on the network is known to be very low, but I observe that most Lightning Network participants today have excellent Internet connectivity, which might not be true in the foreseeable future.
We can reduce the round trips to 1.5 per commitment, except for the initial commitment transaction, by sending the `R` precommitments (the first phase of MuSig) of the *next* signing session while sending the `s` for the *current* signing session.
Finally, we can consider to reduce the use of MuSig via various techniques.
One technique is the use of fast forwards: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
The other involves using Taproot.
The taproot internal pubkey is the MuSig of both participants, but we also add an explicit 2-of-2 as a tapscript (or hide the 2-of-2 in a 2-of-3), i.e. `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG` in a tapscript.
This allows commitment transactions to use the tapscript path and have separate signatures for both participants.
Then, mutual close uses the MuSig keypath spend.
This reduces the changes relative to the current Poon-Dryja implementation: we can continue to use `commitment_signed` messages (or equivalent new ones for Taproot-based Poon-Dryja channels), and only the mutual close ritual needs to be modified to use MuSig.
Thus the options are below, but ***please do not select an option yet***, because further sections greatly affect the tradeoffs of the options below.
* [ ] Latency is not an issue (even in the foreseeable future), just use the 2.5 round trips for MuSig and MuSig-sign every commitment.
* [ ] Pre-send the `R` commitments with the previous `s`.
* This increases the needed storage requirements of both nodes, and possibly complexity of node software, but reduces the round trips to 1.5.
* This usage may need to have larger bounds than what may be naively expected, if we decide to use Multi-`R` composable MuSig (see later section).
* Even *without* this option, at the minimum we still need to store `R` commitments and `R`, at least in memory, until we complete the MuSig ritual.
* [ ] Use fast-forwards.
* This removes the latency of commitment transaction signing from the forwarding and failure-reporting paths.
* *Improved* forwarding and failure-reporting latency compared to today (revocation and signature not needed for forwarding/failure-reporting).
* Latency is still high for commitment transaction signing, but this is less of an issue as it is no longer in the forwarding/failure-reporting path.
* [ ] Explicit 2-of-2 for commitment, MuSig for mutual close.
* No degradation in latency compared to today (0.5 round trips for signature, additional 1 round trip for signalling and revocation).
* No improvement (or degradation) of privacy for unilateral closes compared to today, but improved privacy for mutual closes.
* An argument *for* this option is that unilateral closes (commitment transactions) have special scripts on their outputs anyway, thus still leak their privacy, but see later sections for how Taproot may help reduce the uniqueness of those outputs, thus *not* taking this option may still improve privacy for unilateral closes.
Composable MuSig
----------------
As I describe here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017493.html
In that write-up, I mention the use-case of nodelets.
Another use-case is for redundant hardware signers: https://lists.ozlabs.org/pipermail/c-lightning/2019-December/000172.html
We have the option of allowing for a composable MuSig, probably my multi-`R` proposal, where each participant may send one or more `R` commitments and subsequent `R`s.
* [ ] Not use composable MuSig of any kind, at least for now.
* Possibly we could defer the use of a composable MuSig when a better composable MuSig (with security proofs) has been derived.
* [ ] Use Multi-`R` composable MuSig.
* We need to probably impose some limit on the number of `R` commitments that can be sent: _____ `R`s maximum.
The latter option above affects the previous choice regarding whether to pre-send `R` commitments with the previous `s` sending, as this increases the maximal storage requirement for the pre-sent `R` commitment(s).
Pointlocked Timelocked Contracts
--------------------------------
I would have preferred to keep this in a separate discussion thread, however the exact details of PTLCs may affect our decision on how to sign commitment transactions.
PTLCs are necessary to switch the Lightning Network to payment point+scalar, and indeed one can argue that the entire point of enabling Schnorr and Taproot at the base layer is to allow us to use payment point+scalar at the Lightning layer.
First, I will discuss how to create a certain kind of PTLCs, which I call "purely scriptless" PTLCs.
In particular, I would like to point out that we *actually* use in current Poon-Dryja Lightning Network channels is *revocable* HTLCs, thus we need to have *revocable* PTLCs to replace them.
* First, we must have a sender A, who is buying a secret scalar, and knows the point equivalent to that scalar.
* Second, we have a receiver B, who knows this secret scalar (or can somehow learn this secret scalar).
* A and B agree on the specifications of the PTLC: the point, the future absolute timelock, the value.
* A creates (but *does not* sign or broadcast) a transaction that pays to a MuSig of A and B and shares the txid and output number with the relevant MuSig output.
* A and B create a backout transaction.
* This backout has an `nLockTime` equal to the agreed absolute timelock.
* It spends the above MuSig output (this input must enable `nLockTime`, e.g. by setting `nSequence` to `0xFFFFFFFE`).
* It creates an output that is solely controlled by A.
* A and B perform a MuSig ritual to sign the backout transaction.
* A now signs and broadcast the first transaction, the one that has an output that represents the PTLC.
* A and B wait for the above transaction to confirm deeply.
This completes the setup phase for the PTLC.
* After this point, if the agreed-upon locktime is reached, A broadcasts the backout transaction and aborts the ritual.
* A and B create a claim transaction.
* This has an `nLockTime` of 0, or a present or past blockheight, or disabled `nLockTime`.
* This spends the above MuSig output.
* This creates an output that is solely controlled by B.
* A and B generate an adaptor signature for the claim transaction, which reveals the agreed scalar.
* This is almost entirely a MuSig ritual, except at `s` exchange, B provides `t + r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` first, then demands `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, A) * a` from A, then reveals `r + h(R | MuSig(A,B) | m) * MuSigTweak(A, B, B) * b` (or the completed signature, by publishing onchain), revealing the secret scalar `t` to A.
* A is able to learn the secret scalar from the above adaptor signature followed by the full signature, completing the ritual.
Note that the above ritual is "purely scriptless".
It is possible to take advantage of taproot to create a tapscript equivalent to `<agreed locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP <A> OP_CHECKSIG`.
This removes the need to perform a MuSig ritual to sign a backout transaction: A can generate the backout transaction all by itself.
This use is not purely scriptless, as the timelocked branch is controlled by a tapscript that is hidden in the pointlocked branch, meaning that taking the timelocked branch reveals the contract.
The tradeoff is that if we use "purely scriptless" PTLCs:
* If we have purely scriptless PTLCs, then even the timelock branch is potentially indistinguishable from ordinary spends.
* We should note that Bitcoin Core itself already uses the current blockheight plus 1 for `nLockTime` when spending, instead of a 0 or disabled `nLockTime`.
* If the above habit were more widespread (i.e. if all wallets implemented the use of a current `nLockTime` for ordinary onchain spends) then the timelock branch has an anonymity set equal to all Schnorr keypath spends, as the `nLockTime` is always used anyway.
* Other kinds of offchain protocols may also utilize this technique, slightly increasing the anonymity set as well.
Thus, the use of the current blockheight plus 1 for `nLockTime` should be recommended for improved privacy in Bitcoin anyway.
* However, purely scriptless PTLCs require a complete MuSig ritual (2.5 to 3 round trips!) to sign the timelocked branch (the initial backout transaction); this increases the latency of adding new PTLCs.
* Of note is that in the case of Lightning, we may need to add a new PTLC while another PTLC is *still* in-flight; on the new commitment transaction, we need to redo the MuSig rituals to create new backouts and new adaptor signtures for each PTLC.
* This can be amortized such that we redo all the rituals for all existing PTLCs in parallel.
* The use of multi-`R` composable MuSig greatly increases the storage requirements as well!
* Further, the privacy gained in the timelock path is degraded or lost when we consider revocable PTLCs and revocable outputs.
* It is not clear to me as fo now if the MuSig ritual for the backout transaction must complete in full before the MuSig ritual for the claim transaction (the pointlocked branch, which includes sharing an adaptor signature during `s` exchange).
* If we can do these two rituals in parallel, this reduces the latency disadvantage of the purely scriptless PTLC to just 1 round trip compared to the tapscripted timelock branch PTLC.
* Possibly the adaptor signature ritual could stop until B provides the adaptor signature, then full `s` exchange is deferred to after the PTLC 2-of-2 is instantiated onchain/reified in a commitment transaction.
Thus our options are the below, but again, you should defer deciding on the best option until you understand about revocable PTLCs.
* [ ] We can use a purely scriptless PTLC construction.
* Better privacy, but increased latency.
* [ ] We can use a tapscripted timelock branch and a keypath pointlocked branch for the PTLC.
* Lower latency, but possibly reduced privacy advantage in the timelock branch (privacy advantage still exists in the pointlocked branch, which we hope is more common anyway).
Revocable Outputs and PTLCs
---------------------------
Poon-Dryja mechanism is based on revocation of contracts instantiated from previous states.
Thus, all outputs of Poon-Dryja must be made revocable.
At a high-enough level, this only requires the addition of a `(revocation_secret && remote_secret) || (CSV && L)` to the top-level logic (`L`) of a contract.
Of course, the details have the devil.
Now, in Poon-Dryja, each side of the channel has its own commitment transaction.
Thus, contracts on the commitment transaction refer to a "local side" and a "remote side".
The "local side" is whoever is holding the completely-signed commitment transaction, while the "remote side" is the other side.
Revocable outputs always have a CSV-requirement before the output can be spent by whoever "should" own the output, according to the contract details.
The revocation secret is known by the local side, and then when a *new* commitment transaction has been signed, the revocation secret is given by the local side to the remote side, allowing all outputs to be spent directly by the remote side if an old, revoked commitment transaction is published onchain.
There are many ways to implement revocable outputs.
The core idea of revocable outputs, however, is that there must exist some relative-locktime branch on each output that goes to the local side.
This relative-locktime branch can be implemented as "purely scriptless" by using a 2-of-2 of both the local and remote sides, with a relative-locktime `nSequence`, using the same technique as described in the previous section.
However, unlike the absolute-locktime `nLockTime` for the timelock branches of PTLCs, ***there is no current wallet software that uses activated-relative-locktime `nSequence` for ordinary spends***.
Thus, any use of the relative-locktime branch does *not* have a privacy advantage under purely scriptless.
Thus the tradeoffs here are different, and definitely in favor of the tapscripted-relative-locktime technique.
* There is no current wallet software that uses relative locktimes.
* Bitcoin Core uses absolute locktimes with the current blockheight plus 1, and we can hide the use of absolute locktimes by imitating this Bitcoin Core behavior.
* Any use of relative locktimes is a strong signal of some kind of complicated offchain updateable mechanism.
We can note as well that Decker-Russell-Osuntokun also uses relative locktimes.
* The relative-locktime branch in revocable outputs is the **desirable** case, because taking the relative locktime means that the commitment transaction published *was not* a revoked transaction (i.e. it was the latest transaction version).
* Thus, it would be nice if this had good privacy.
* However, this *cannot* have good privacy since there is no current common use of activated relative locktimes for ordinary spends.
The latter point above also biases us towards rejecting purely-scriptless in the *previous* section, in particular:
* The absolute-locktime branch in the PTLC is the **undesirable** case, where the payee B somehow stops responding to A.
* In particular, propagating failure backwards is done by simply deleting PTLCs, thus the absolute-locktime branch does not come into play during payment failure.
* Thus, the privacy increase of hiding absolute-locktime branches is minor, and the privacy breach of revocable outputs (i.e. it leaks the use of relative-locktime, and nearly all uses of relative locktime will be offchain updateable cryptocurrency mechanisms, such as Poon-Dryja or Decker-Russell-Osuntokun) is arguably much larger than the privacy increase of purely-scriptless absolute-locktime.
Of particular not is that if a PTLC is instantiated on the commitment transaction of the payer A, then the absolute-locktime backout transaction must *not* pay to A only, but instead pays to a *revocable output* that will eventually pay to A after the relative locktime.
Thus, the privacy boost of the purely-scriptless backout transaction would be lost by the later revelation of the use of a relative locktime after the revocable output is reclaimed by A.
Again, that use of relative locktime (whether enforced by script, or by scriptless use of a 2-of-2 that is spent with an activated relative-locktime `nSequence`) is a strong indicator of the use of Poon-Dryja or Decker-Russell-Osuntokun or even Decker-Wattenhofer mechanisms, and the logic is that since Lightning Network is the most widespread offchain mechanism, it probably indicates the use of LN.
Thus the decision in the previous section is affected by this reality that we in fact need *revocable* PTLCs, not plain PTLCs, thus the advantage of purely-scriptless backout transactions in the previous section is reduced by the need to make outputs revocable.
Thus:
* Revocable outputs require a relative-timelock branch.
* That branch is the **desirable** branch, i.e. the latest commitment transaction is the one that got published and thus is *not* revoked.
* We thus expect this relative-timelock branch to be the *common* branch.
* No wallet uses relative-timelock for ordinary spends, unlike abolute-locktime where Bitcoin Core always uses absolute-locktime `nLockTime` for ordinary spends.
* Thus, using purely scriptless for the relative-timelock branch of revocable outputs does not in fact hide that we are doing something special.
Conclusion
----------
Others may find further issues or alternative options for the above points.
Further discussion may be warranted before we actually select particular options to implement and evaluate in alpha software.
Regards,
ZmnSCPxj