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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
