Ephemeral anchors in LN

[yyforyongyu]

A Brief History

Imagine a new output that's different from the LN anchor output that,

• has a smaller witness size, and,
• may use any satoshi value (as opposed to 330 sats).

We then have the original ephemeral anchor, which is a special output that,

• allow the output to have any satoshi value, including zero.
• the witness program is always OP_1 <0x4e73> (bc1pfeessrawgf).

A tx that contains an ephemeral anchor must,

• be a v3 tx itself.
• pay 0 fee.
• have exactly one ephemeral anchor.
• have the ephemeral anchor being spent in the same relay package.

However, as pointed out here, there's no need to restrict ephemeral anchors to v3 transactions, thus the original ephemeral anchor is now split into two proposals,

• ephemeral dust, which is an output that allows any satoshi value.
• P2A output, which is a keyless output.

P2A Output

A new standard output (ANCHOR), pay-to-anchor output has been added to bitcoind v0.28. In this keyless output,

• the witness program is always OP_1 <0x4e73> (bc1pfeessrawgf).
• the witness used to spend it must be empty, which means this output can be spent by anyone.
• the value must be greater than the dust - due to its smaller size, the smallest value is now 240 sats.

For LN, this means we can now replace the local/remote anchor pair with this P2A output as,

• P2A is cheaper to create and spend.
• As long as the package [commitment tx -> anchor tx] is used, the cost to resolve a pinning attack should be capped at 1000 sats, check here for details.

In addition, for simple taproot channels, we can now use a smaller to_local script. Atm we disable the key spending path for to_local to force the disclosure of local_delayedpubkey to make sure the anchor output can be spent by anyone after 16 blocks, which is no longer needed. The to_local output can now have the revocation_pubkey as the internal key.

Ephemeral Dust

Ephemeral dust is still under development, which IMO is orthogonal to P2A as it focuses on the "dust" part, as it allows output to carry any satoshi value, including zero. This means a P2A can be an ephemeral dust, aka a keyless anchor. Or, an ephemeral dust may have a normal witness program, aka keyed anchor.

For LN, this means we can save an extra 240 sats when using anchor output. In addition, this output can behave like a container for trimmed HTLCs, tho I don't see any benefits here.

Why OP_1 <0x4e73>

It's a clever way to make a valid non-taproot witness program,

• BIP141 requires at least two items in the witness program for it to be valid.
• BIP341 only considers OP_1 followed by a 32-byte data as taproot output. When it's version 1 output with a length other than 32 bytes, it's valid but the validation rules are undefined.
• 0x4e73 are "cutesy to spell fees", which I don't quite follow.
• 0x4e73 is also the unicode for nipples in chinese, which I believe is unintended...

3rd Party Sweeping

Although it's not restricted to be used in v3 only, the commitment tx uses P2A output must be a v3 tx to be protected by the TRUC policy, where the anchor spending tx must be a v3 and have a size no larger than 1000 vB, otherwise, it can easily be pinned.

We should also pay attention to the actual satoshi value used in keyless ephemeral anchors. As of today, there are 3rd parties who monitor the blockchain to create sweeping txns that aggregate anchor outputs, which has accidentally created pinning issue for lnd nodes. Given an anyone-can-spend anchor, we can assume the larger the value, the more likely a 3rd party service will try to spend it. To remove such an incentive, we should derive a value such that, without attaching additional UTXOs, the package [commitment tx -> anchor sweep tx] would stay below the min relay feerate, to remove 3rd party's incentive to collect it.

TODO(yy): calculate the details.

[instagibbs]

Great writeup! I hadn't considered the additional savings with taproot channels to_local outputs, makes sense.

. To remove such an incentive, we should derive a value such that, without attaching additional UTXOs, the package [commitment tx -> anchor sweep tx] would stay below the min relay feerate, to remove 3rd party's incentive to collect it.

Assuming TRUC is being used I think the real concern is the counter-party racking up value via circular trimmed HTLCs or something, allowing you to be influenced into funding another child transaction's fees. Trimmed HTLC values is pretty weird today too, I think capping its value is the most direct route.