ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-10 📝 Original message: Good morning, Another ...
📅 Original date posted:2020-01-10
📝 Original message:
Good morning,
Another point regarding the use of "purely scriptless" (i.e. using pre-signed `nLockTime` and `nSequence`d transactions) is that there are significantly more signatures to be generated cooperatively.
We need to use MuSig for these in order to hide in the much larger 1-of-1 anonymity set.
There are two branches per PTLC (pointlock and timelock), and one of those branches would lead to a revocable output (which has a relative-locktime), thus 3 signatures (just for one HTLC).
It is probably safe to perform the MuSig for all three signatures in one MuSig exchange, and probably for all PTLCs on each commitment transaction as well, plus the revocable `to_self` output.
However the commitment transaction itself would have to be signed *after* all the PTLCs and revocable `to_self` have been signed, so we cannot run the MuSig for this in parallel with the PTLCs and `to_self`.
Now, we know we can hide the timelock branches, as well as the revocable outputs, with other `nLockTime`d and `nSequence`d transactions.
* The timelock branch will be enforced by one of the participants, and will come onchain (if not congested) at the same blockheight indicated by the `nLockTime`.
* The revocable output will be claimed at the end of the revocation grace period, and will come onchain (if not congested) at the relative blocktime indicaated by the `nSequence`.
Both of the above will be indistinguishable from the anti-fee-sniping behavior (once we modify Bitcoin Core to randomly select between absolute and relative anti-fee-sniping), thus hides among the other transactions made by Bitcoin Core.
However, the commitment transaction itself, and the pointlock branch, cannot hide among the anti-fee-sniping behavior.
* The commitment transaction is kept indefinitely, and if there is no activity on the channel, a million blocks may pass since its `nLockTime` and `nSequence` have been fixed.
* Thus, any `nLockTime` or `nSequence` we put in the commitment transaction would be well in the past by the time the commitment transaction appears onchain, and thus they can be identified that way.
* We could just recreate the commitment transaction every time a new block comes in, so that the latest commitment transaction always has an up-to-date `nLockTime` or `nSequence`, but now every block would cause a system shock across the entire Lightning Network as all nodes update their channel states with their peers.
* But what happens if the peer is offline at a new block?
We are forced to keep around a commitment transaction with a past `nLockTime`/`nSequence`.
If the peer remains offline we might then decide to push the commitment transaction, but since the peer is offline, it will have the past `nLockTime`/`nSequence`.
* The pointlock branch is dependent on the commitment transaction above, and encounters the same issues.
So in general it might be better for commitment transactions, as well as scriptless script pointlocks, to not have a fee-sniping-protection-emulation.
But this means we also do not want to have all wallets use fee-sniping-protection.
Another point, and the reason why I pointed out that you need at least two MuSig rounds (the first running all the PTLC and revocable outputs in parallel, the second signing just the commitment hosting them), is that this increases latency of each update.
This is fine if you are on open network, but on e.g. Tor each turnaround is greatly increased, and the multiple MuSig rounds get more delay.
Regards,
ZmnSCPxj
📝 Original message:
Good morning,
Another point regarding the use of "purely scriptless" (i.e. using pre-signed `nLockTime` and `nSequence`d transactions) is that there are significantly more signatures to be generated cooperatively.
We need to use MuSig for these in order to hide in the much larger 1-of-1 anonymity set.
There are two branches per PTLC (pointlock and timelock), and one of those branches would lead to a revocable output (which has a relative-locktime), thus 3 signatures (just for one HTLC).
It is probably safe to perform the MuSig for all three signatures in one MuSig exchange, and probably for all PTLCs on each commitment transaction as well, plus the revocable `to_self` output.
However the commitment transaction itself would have to be signed *after* all the PTLCs and revocable `to_self` have been signed, so we cannot run the MuSig for this in parallel with the PTLCs and `to_self`.
Now, we know we can hide the timelock branches, as well as the revocable outputs, with other `nLockTime`d and `nSequence`d transactions.
* The timelock branch will be enforced by one of the participants, and will come onchain (if not congested) at the same blockheight indicated by the `nLockTime`.
* The revocable output will be claimed at the end of the revocation grace period, and will come onchain (if not congested) at the relative blocktime indicaated by the `nSequence`.
Both of the above will be indistinguishable from the anti-fee-sniping behavior (once we modify Bitcoin Core to randomly select between absolute and relative anti-fee-sniping), thus hides among the other transactions made by Bitcoin Core.
However, the commitment transaction itself, and the pointlock branch, cannot hide among the anti-fee-sniping behavior.
* The commitment transaction is kept indefinitely, and if there is no activity on the channel, a million blocks may pass since its `nLockTime` and `nSequence` have been fixed.
* Thus, any `nLockTime` or `nSequence` we put in the commitment transaction would be well in the past by the time the commitment transaction appears onchain, and thus they can be identified that way.
* We could just recreate the commitment transaction every time a new block comes in, so that the latest commitment transaction always has an up-to-date `nLockTime` or `nSequence`, but now every block would cause a system shock across the entire Lightning Network as all nodes update their channel states with their peers.
* But what happens if the peer is offline at a new block?
We are forced to keep around a commitment transaction with a past `nLockTime`/`nSequence`.
If the peer remains offline we might then decide to push the commitment transaction, but since the peer is offline, it will have the past `nLockTime`/`nSequence`.
* The pointlock branch is dependent on the commitment transaction above, and encounters the same issues.
So in general it might be better for commitment transactions, as well as scriptless script pointlocks, to not have a fee-sniping-protection-emulation.
But this means we also do not want to have all wallets use fee-sniping-protection.
Another point, and the reason why I pointed out that you need at least two MuSig rounds (the first running all the PTLC and revocable outputs in parallel, the second signing just the commitment hosting them), is that this increases latency of each update.
This is fine if you are on open network, but on e.g. Tor each turnaround is greatly increased, and the multiple MuSig rounds get more delay.
Regards,
ZmnSCPxj