Good morning list, > 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.
No, sorry, this is insecure, because the "revoked by then" branch still exists, this is daft, lower-level cognition agents proposing this have been reduced in influence in the overall community of sub-agents. So no, we still need relative-locktime here. I would also like to point out that the revelation of relative-locktime requirements would only happen in a unilateral honest closs (they can be hidden in a unilateral dishonest close that is caught and revoked, by using the revocation key as a shard of the Taproot key). Mutual closes can be simple spends in a Taproot future of a Schnorr output, and thus have good privacy. I have not trawled the data yet but I believe unilateral closes are a tiny fraction of mutual closes, so this privacy leak might be acceptable. Against this, however, we might consider that as Lightning becomes more stable, deliberate closure of channels becomes less likely, meaning more closes will be "accidental", e.g. bugs, nodes going offline, etc. Thus unilateral closes may increase in proportion compared to mutual closes in the future, in which case we might want to re-consider privacy for unilateral closes. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
