ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-12 📝 Original message: Good morning David, > On ...
📅 Original date posted:2020-01-12
📝 Original message:
Good morning David,
> On Tue, Jan 07, 2020 at 12:26:05AM +0000, ZmnSCPxj wrote:
>
> > For `nSequence` relative-locktime transactions that protect the
> > security of the channel mechanism, these are used in unilateral
> > closes. The issue is that a unilateral close might occur far, far in
> > the future. Thus, any non-0 `nLockTime` you signed up for at the time
> > the commitment transaction was signed, will likely be obsolete.
>
> As long as there's no conflict created by using both relative and
> absolute locktimes in the same transaction, I don't think there's any
> problem. Multiple versions of a commitment transaction may be signed,
> each with different nLockTimes but all other parts of the transaction
> the same (including any relative timelocks). This obviously requires a
> tiny bit of extra CPU plus modest amounts of extra bandwidth and
> storage, but it seems within reason for people who want better privacy.
Yes, but how many `nLockTime` candidates are enough?
If there is not enough granularity, then you will be forced to use an `nLockTime` that is in the past, and if the blockchain layer is not congested then, it is a smoking gun of such pre-signed transactions.
Either that or you wait for the next available `nLockTime`.
Further, there must always exist some limit on the largest-`nLockTime` commitment transaction you keep.
If the largest-`nLockTime` commitment transaction is now approaching, and the counterparty goes offline, then you have a Morton fork:
* Drop the commitment transaction at the correct blockheight now.
* You regret this later if the counterparty comes online, since now your channel is in a closed state.
* Keep the channel open.
* You regret this later if the counterparty remains offline, since now your commitment transaction is badly out-of-date and you lose privacy if you drop it.
We see this already with `update_fee` disagreements, if the funder gives an apparently-lowball fee estimate, do you drop now (and lose possible revenue), or do you wait (and risk that later, that lowball fee estimate is even lower for the current situation).
Due to user complaint we have gone the "wait and maybe suffer later" route but that is the choice that leaks privacy in the above fork.
>
> > Instead, what Bitcoin Core would have to do would be something like:
> >
> > - Toss a coin:
> > - If it is heads, use a non-relative-locktime `nSequence` and an `nLockTime` of the next block (i.e. current behavior).
> > - If it is tails, use a relative-locktime `nSequence` equal to the confirmations of the output being spent, and an `nLockTime` of 0.
> >
> > Then we would hide the Lightning relative-locktime transactions with an `nLockTime` of 0.
>
> Commitment transactions for current two-party LN have at least two
> outputs; the chance of both outputs being spent with an nLockTime of 0
> is 25% (assuming every non-LN onchain transaction uses the above
> scheme). That's a fairly significant bias that can be combined with
> other indicators to identify LN transactions for analytics or censorship.
Hmm?
Assuming both counterparties have a balance on the channel, then at least one of the outputs must be spendable (disregarding the revocation branch) with a relative lock time, so if we select between "0 `nLockTime` but enabled `nSequence`" vs "current blockheight plus one `nLockTime`" at 50%, and there are only the two "main" outputs and no PTLCs, then you get exactly 50% of the outputs being spent with one policy and 50% being spent with the other policy.
Basically, on every Poon-Dryja commitment transaction, assuming there are no PTLCs/HTLCs and both sides have money in the channel, then:
* one output will be directly spendable by the remote side.
* one output will be spendable by the local side, but only after a relative locktime from the commitment transaction.
So if the remote side uses an `nLockTime`-enabled transaction, and the local side uses a `nSequence`-enabled transaction to scriptlessly implement relative locktime, then we match the 50% coin toss.
Unless you are referring to something else?
Regards,
ZmnSCPxj
📝 Original message:
Good morning David,
> On Tue, Jan 07, 2020 at 12:26:05AM +0000, ZmnSCPxj wrote:
>
> > For `nSequence` relative-locktime transactions that protect the
> > security of the channel mechanism, these are used in unilateral
> > closes. The issue is that a unilateral close might occur far, far in
> > the future. Thus, any non-0 `nLockTime` you signed up for at the time
> > the commitment transaction was signed, will likely be obsolete.
>
> As long as there's no conflict created by using both relative and
> absolute locktimes in the same transaction, I don't think there's any
> problem. Multiple versions of a commitment transaction may be signed,
> each with different nLockTimes but all other parts of the transaction
> the same (including any relative timelocks). This obviously requires a
> tiny bit of extra CPU plus modest amounts of extra bandwidth and
> storage, but it seems within reason for people who want better privacy.
Yes, but how many `nLockTime` candidates are enough?
If there is not enough granularity, then you will be forced to use an `nLockTime` that is in the past, and if the blockchain layer is not congested then, it is a smoking gun of such pre-signed transactions.
Either that or you wait for the next available `nLockTime`.
Further, there must always exist some limit on the largest-`nLockTime` commitment transaction you keep.
If the largest-`nLockTime` commitment transaction is now approaching, and the counterparty goes offline, then you have a Morton fork:
* Drop the commitment transaction at the correct blockheight now.
* You regret this later if the counterparty comes online, since now your channel is in a closed state.
* Keep the channel open.
* You regret this later if the counterparty remains offline, since now your commitment transaction is badly out-of-date and you lose privacy if you drop it.
We see this already with `update_fee` disagreements, if the funder gives an apparently-lowball fee estimate, do you drop now (and lose possible revenue), or do you wait (and risk that later, that lowball fee estimate is even lower for the current situation).
Due to user complaint we have gone the "wait and maybe suffer later" route but that is the choice that leaks privacy in the above fork.
>
> > Instead, what Bitcoin Core would have to do would be something like:
> >
> > - Toss a coin:
> > - If it is heads, use a non-relative-locktime `nSequence` and an `nLockTime` of the next block (i.e. current behavior).
> > - If it is tails, use a relative-locktime `nSequence` equal to the confirmations of the output being spent, and an `nLockTime` of 0.
> >
> > Then we would hide the Lightning relative-locktime transactions with an `nLockTime` of 0.
>
> Commitment transactions for current two-party LN have at least two
> outputs; the chance of both outputs being spent with an nLockTime of 0
> is 25% (assuming every non-LN onchain transaction uses the above
> scheme). That's a fairly significant bias that can be combined with
> other indicators to identify LN transactions for analytics or censorship.
Hmm?
Assuming both counterparties have a balance on the channel, then at least one of the outputs must be spendable (disregarding the revocation branch) with a relative lock time, so if we select between "0 `nLockTime` but enabled `nSequence`" vs "current blockheight plus one `nLockTime`" at 50%, and there are only the two "main" outputs and no PTLCs, then you get exactly 50% of the outputs being spent with one policy and 50% being spent with the other policy.
Basically, on every Poon-Dryja commitment transaction, assuming there are no PTLCs/HTLCs and both sides have money in the channel, then:
* one output will be directly spendable by the remote side.
* one output will be spendable by the local side, but only after a relative locktime from the commitment transaction.
So if the remote side uses an `nLockTime`-enabled transaction, and the local side uses a `nSequence`-enabled transaction to scriptlessly implement relative locktime, then we match the 50% coin toss.
Unless you are referring to something else?
Regards,
ZmnSCPxj