Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 4832 bytes --]

On Mon, Nov 06, 2023 at 06:45:21PM +0000, Antoine Riard wrote:
> > I think you are misunderstanding a key point to my OP_Expire proposal:
> because
> > the ability to spend the preimage branch of the HTLC goes away when the
> refund
> > branch becomes available, replacing cycling or any similar technique
> becomes
> > entirely irrelevant.
> 
> > The situation where Carol prevents Bob from learning about the preimage
> in time
> > simply can't happen: either Carol collects the HTLC with knowledge of the
> > preimage, by spending it in a transaction mined prior to the expiration
> time
> > and ensuring that Bob learns the preimage from the blockchain itself. Or
> the
> > HTLC expires and Bob can use the refund branch at his leisure.
> 
> I think I understand the semantic of the OP_Expire proposal overall
> correctly, however I'm not sure it prevents replacing cycling or any
> similar adversarial technique, as the forwarding node might be the attacker
> in some scenario.

<snip>

> Assuming this advanced scenario is correct, I'm not sure the OP_Expire
> proposal is substantially fixing all the adversarial replacement cycling
> situations.

What you are describing here is a completely different problem than what
OP_Expire aims to solve.

The problem that OP_Expire aims to solve is the fact that Carol could prevent
Bob from learning about the preimage in time, while still getting a chance to
use the preimage herself. OP_Expire thoroughly solves that problem by ensuring
that the preimage is either broadcast in the blockchain in a timely fashion, or
becomes useless.

The problem you are describing, as Zmm points out below, doesn't actually exist
in Bitcoin right now. But it could exist if we adopted v3 package relay, which
as I've pointed out elsewhere, is inferior to using RBF.


On Tue, Nov 07, 2023 at 03:44:21PM +0000, Antoine Riard wrote:
> Hi Zeeman,
> 
> > Neither can Bob replace-recycle out the commitment transaction itself,
> because the commitment transaction is a single-input transaction, whose
> sole input requires a signature from
> > Bob and a signature from Carol --- obviously Carol will not cooperate on
> an attack on herself.
> 
> The replacement cycling happens on the commitment transaction spend itself,
> not the second stage, which is effectively locked until block 100.
> 
> If the commitment transaction is pre-signed with 0 sat / vb and all the
> feerate / absolute fee is provided by a CPFP on one of the anchor outputs,
> Bob can replace the CPFP itself. After replacement of its child, the
> commitment transaction has a package feerate of 0 sat / vb and it will be
> trimmed out of the mempool.
> 
> This is actually the scenario tested here on the nversion = 3 new mempool
> policy branch  (non-deployed yet):
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
> 
> As of today commitment transactions might not propagate if dynamic mempool
> min fee is above pre-signed commitment transaction, which is itself unsafe.
> I think this behavior can currently be opportunistically exploited by
> attackers.

Yes, obviously it can be. For starters, you can easily end up in a situation
where the commitment transaction simply can't get mined, an obvious problem.

> In a post-package relay world, I think this is possible. And that
> replacement cycling attacks are breaking future dynamic fee-bumping of
> pre-signed transactions concerns me a lot.

Well the answer here is pretty clear: v3 package relay with anchors is broken.

My suggestion of pre-signing RBF replacements, without anchor outputs, and with
all outputs rendered unspendable with 1 CSV, is clearly superior: there are
zero degrees of freedom to the attacker, other than the possibility of
increasing the fee paid or broadcasting a revoked commitment. The latter of
course risks the other party punishing the fraud.

This does have the practical problem that a set of refund transactions will
also need to be signed for each fee variant. But, eg, signing 10x of each isn't
so burdensome. And in the future that problem could be avoided with
SIGHASH_NOINPUT, or replacing the pre-signed refund transaction mechanism with
a covenant.

Using RBF rather than CPFP with package relay also has the advantage of being
more efficient, as no blockspace needs to be consumed by the anchor outputs or
transactions spending them. Of course, there are special circumstances where
BIP125 rules can cause CPFP to be cheaper. But we can easily fix that, eg by
reducing the replacement relay fee, or by delta-encoding transaction updates.


As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing both it
and OP_Expire could make sense.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]