Ephemeral Dust

[instagibbs]

A replacement for #29001

Now that we have 1P1C relay, TRUC transactions and sibling eviction, it makes sense to retarget this feature more narrowly by not introducing a new output type, and simple focusing on the feature of allowing temporary dust in the mempool.

Users of this can immediately use dust outputs as:

1. Single keyed anchor (can be shared by multiple parties)
2. Single unkeyed anchor, ala P2A

Which is useful when the parent transaction cannot have fees for technical or accounting reasons.

What I'm calling "keyed" anchors would be used anytime you don't want a third party to be able to run off with the utxo. As a motivating example, in Ark there is the concept of a "forfeit transaction" which spends a "connector output". The connector output would ideally be 0-value, but you would not want that utxo spend by anyone, because this would cause financial loss for the coordinator of the service: https://arkdev.info/docs/learn/concepts#forfeit-transaction

Note that this specific use-case likely doesn't work as it involves a tree of dust, but the connector idea in general demonstrates how it could be used.

Another related example is connector outputs in BitVM2: https://bitvm.org/bitvm2.html .

Note that non-TRUC usage will be impractical unless the minrelay requirement on individual transactions are dropped in general, which should happen post-cluster mempool.

Lightning Network intends to use this feature post-29.0 if available: lightning/bolts#1171 (comment)

It's also useful for Ark, ln-symmetry, spacechains, Timeout Trees, and other constructs with large presigned trees or other large-N party smart contracts.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/30239.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	glozow, theStack
Concept NACK	petertodd
Concept ACK	t-bast, murchandamus, stickies-v, hodlinator, tdb3
Stale ACK	sdaftuar

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #31153 (bench: Remove various extraneous benchmarks by dergoegge)
• #29247 (CAT in Tapscript (BIP-347) by 0xBEEFCAF3)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[DrahtBot]

🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the
documentation.

Possibly this is due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.

Leave a comment here, if you need help tracking down a confusing failure.

_{Debug: https://github.com/bitcoin/bitcoin/runs/25906194302}

[instagibbs]

going to put this into draft until #29496 is merged, since dust checks are completely off when -acceptnonstdtxn=1. which is required for TRUC currently.

[theStack]

Is it an option to be more restrictive and only allow zero-value outputs as ephemeral anchors, for not having to deal with the concept of dust at all? Or, asked differently: what would be the motivation/benefit for users to ever create an anchor output with nValue > 0? (Note that I haven't looked too deep into the concept of ephemeral anchors and the predecessor PR #29001, so very likely I'm missing something obvious here, but I guess the answer could be interesting for other potential reviewers too.)

[instagibbs]

@theStack the primary motivation is to cover cases where non-0 value is attached to handle cases where a smart contract may want to "throw away" a few sats to fees, but otherwise cannot because of the 0-fee requirement of this PR for transactions with ephemeral anchors. If the ephemeral anchor-having transaction had non-0-fee, that would allow endogenous incentives to get it mined on its own, leaving the dust in the utxo set. As an example from the LN spec, [trimmed outputs(https://github.com/lightning/bolts/blob/master/03-transactions.md#trimmed-outputs) are directly added to the commitment transaction fee. Instead, spec writers could have the value flow to the ephemeral anchor, which is then spent to fees by the child transaction. Example spec here: https://github.com/instagibbs/bolts/commits/zero_fee_commitment

It's a fairly narrow motivation, and honestly I don't love the timmed output to fees scheme, but also doesn't make the code anymore complicated, so I think it's worth consideration.

[DrahtBot]

🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the
documentation.

Possibly this is due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.

Leave a comment here, if you need help tracking down a confusing failure.

_{Debug: https://github.com/bitcoin/bitcoin/runs/25953908933}

[instagibbs]

rebased due to s/nVersion/version/ change for transactions causing a silent merge conflict

[instagibbs]

rebased due to conflict with merge of #30592

going to go over all outstanding comments

[instagibbs]

compiling a list of things to do in follow-up, otherwise keeping as-is

[instagibbs]

addrman test failure for win64, assuming unrelated: https://github.com/bitcoin/bitcoin/pull/30239/checks?check_run_id=32868463159

[fanquake]

addrman test failure for win64, assuming unrelated:

Yea this is a Wine issue (see #31071 & the linked issues). I restarted the job.

[glozow]

reACK 5c2e291 via range-diff. Nothing but a rebase and removing the conflict.

[theStack]

re-ACK 5c2e291