Good morning David, and list, It seems to me possible (though potentially undesirable) to have a "maximally private" channel that uses *only* absolute locktimes.
For maximum privacy, you would need to sign new pairs of commitment transactions at every block anyway. And if you sign a new pair "too late", you run the risk that a block will arrive and then make your transaction obviously not match the Bitcoin Core anti-fee-sniping behavior, thus distinguishable, thus non-private, so to preserve the privacy of your channels you would have to drop onchain as soon as a block arrives but your counterparty is not responding quickly enough to sign a new commitment transaction (and all the dreary other transactions needed to make the commitment transaction actually contain the contracts you want, in Scriptless Script form) *and* revoke the previous commitment transaction. So suppose you start at block height N. You and your counterparty sign commitment transactions that have an `nLockTime` of N+2. The consideration here is that if those commitment transactions are unrevoked as of block height N+2, then one or the other commitment transaction ***will*** be dropped onchain, because if not then the transaction will be "out of place" in the block and obviously is not a Bitcoin Core anti-fee-sniping transaction. Now, for a commitment transaction to be revocable, the outputs that are owned by the holder of the commitment transaction must be revocable. Typically, that is implemented by adding a relative-timelock, and a branch that allows immediate revocation. Both branches can be actually be implemented in Scriptless Script: relative-locktime by pre-signing an `nSequence`d transaction, immediate revocation by revealing your share of the pubkey. But note that we have a strong promise that this commitment transaction will appear at block height N+2 (unless revoked by then), because privacy. So we know as well that the "relative-locktime" branch will appear at block height N+2+R, where R is the relative-locktime. Since we already know what *absolute* blockheight we want it to appear in, we could just use an absolute-locktime `nLockTime` requirement, with the pre-signed N+2+R for that transaction that spends the commitment transaction. So the relative-locktime times needed here can instead be transposed to absolute locktimes, i.e. `nLockTime`d transactions that are indistinguishable from Bitcoin Core anti-fee-sniping transactions. So no need to modify the Bitcoin Core to use `nSequence` as well for anti-fee-sniping. Why is the commitment transaction set up with an `nLockTime` of N+2? Because if a block arrives, the block height is now N+1. So now the participants have to create a pair of commitment transactions at N+3 and revoke their held N+2 transactions. If not, then they have to drop the N+2 commitment transaction *now* so that miners can include them in the *next* block at height N+2. (We could switch to N+3 instead, that at least gives a one-block-duration limit for the other side to respond in and update their transactions) Of course, the drawbacks are: * If this is widespread, there will be bursts of activity on the Lightning network at every block. * The use of MuSig Schnorr signing means a good amount of turnarounds, which is bad for high-latency connections like Tor hidden services, further compounded by the need to perform such signing rituals at each block. * As soon as your counterparty drops offline, the channel between you will now be at high risk of simply being dropped onchain right now, i.e. closing. But note the extreme privacy! Now there is no need for relative locktimes, just absolute ones, and we already have a plausible anonymity set for absolute-locktime transactions (Bitcoin Core anti-fee-sniping). With Schnorr and Scriptless Script, and the above technique of "just sign new commitments at every block", even a unilateral close is indistinguishable from normal spends by Bitcoin Core, and if you still use an unpublished channel (perish the thought!) they are no longer obvious to onchain analysis as Lightning Network channels. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
