[Lightning-dev] Lightning in a Taproot future

[David A. Harding]

On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote:
> Hi ZmnSCPxj and Aj,
> 
> Thanks for starting this discussion ZmnSCPxj. Although transactions with
> relative lock times are easily distinguishable today, couldn't this
> situation be improved? Even just a few wallets changing their behaviour to
> set relative time locks on normal payments would weaken the heuristic. 

As mentioned in ZmnSCPxj's post, some wallets (most notably Bitcoin
Core) provide partial anti-fee-sniping protection by setting their
nLockTime to the next-block height[1].  In line with your idea to do the
same with nSequence, I think it would be possible to suggest to the
Bitcoin Core project that they also set nSequence to the block age of
the UTXO being spent (if possible[2]).  I think this could slightly
enhance existing anti-fee-sniping by limiting a sniper's ability to
rearrange ancestor transactions.  For example, imagine we have two
transactions both created by Bitcoin Core on the best block chain:

                      tx0               tx1
                       |                 |
          [ ]---------[ ]-------[ ]-----[ ]----
    Block 600,000    ..01      ..02    ..03

Let's assume tx0 and tx1 were both confirmed quickly, so their nLockTime
equals their block height.  That means a fee sniper's reorg can't move
either transaction further back in the chain, burying them under
addition PoW.  Let's also assume that tx1 is a child of tx0 and sets its
nSequence to 2 blocks.  Now tx0 also can't be moved further forward in
the chain without also moving tx1 further forward, meaning any reduction
in the amount of PoW covering one transaction would also reduce the
amount of PoW covering any of its descendant transactions (if they
opt-in to this scheme).

Bitcoin Core obviously has the information necessary to add an
appropriate nSequence to its transactions because it has a copy of the
UTXO set, but *every* wallet should be keeping track of its transaction's
confirmation scores, so every wallet should know the nSequence delta to
use to allow its transactions to be confirmed in the next block but no
earlier block.

My question here would be whether this change would be useful in providing
privacy for the scheme ZmnSCPxj described.  IIUC, the pre-signed
transactions Zmn described wouldn't need to use both relative locktime
(nSequence) and absolute locktime (nLockTime) at the same time, so it
would be possible to set nLockTime to an appropriate value when using
nSequence for security.  This might not blend in perfectly with
anti-fee-sniping (especially to relay nodes) but perhaps Bitcoin Core's
fuzzing[1] could be increased to help compensate.

-Dave

[1] I think Bitcoin Core implements low-probability fuzzing of the
nLockTime to help cover for wallets that send transactions while still
syncing to the tip.  E.g. an instance fully synced to the current chain
tip might set 1-in-100 of its transactions nLockTime to some past block
height so that spy nodes can't tell whether that transaction was
transmitted by a fuzzing node or one of the nodes that just happened to
be IBD syncing from them at that moment.

[2] nSequence can only encode up to a max of 65,535 for the block
distance; see BIP68.  Also, obviously, if the parent transaction is
unconfirmed at the time one of its outputs is spent, the child can't
have a relative lock-height unless you want to delay its confirmation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200105/42a10c0d/attachment.sig>