TRUC in LN

[yyforyongyu]

TL;DR

After applying TRUC to LN, we'd have the following changes,

• the max number of inflight HTLCs is now 113.
• 1 OP_CHECKSEQUENCEVERIFY can be removed, simplifying the to_remote output in a simple taproot channel.
• update_fee is no longer needed.
• for lnd, we may use a different sweeping strategy for CPFP.
• when there are more than 7 HTLCs, the penalty tx must spend a confirmed commitment tx.

TRUC in LN

BIP431 is one of the few BIPs that are extremely well written so I'd recommend reading it first. To put the TRUC specification in LN's context, it means,

• both the commitment tx and anchor sweeping tx are now TRUC txns and must be submitted in a 1p1c package.
• commitment tx(parent) is limited to have a max size of 10,000 vB.
• anchor sweeping tx(child) is limited to have a max size of 1000 vB.

The anchor sweeping size limit should have no downsize, tho it should be kept in mind that the max number of inputs in this tx is 16 based on this calculator.

Inflight HTLCs

Given a TRUC tx's max virtual size of 10,000 vB, or 40,000 wu, the max number of inflight HTLCs is now decreased.

Anchor Channels

Given the following formula taken from here,

• overall_weight (option_anchors) = 900 + 172 * num-htlc-outputs + 224 weight

The max number of inflight HTLCs is 226, which means only 113 unidirectional HTLCs are allowed. Note that this is different from how the original 483 is calculated here, as the old limit is capped by the penalty tx, while the new limit is capped by the TRUC policy.

Taproot Channels

Since we are using key path spending here for the funding output, the witness size is 66 wu instead of 222 wu,

• num witness: 1 wu
• witness size: 1 wu
• sig: 64 wu

which gives 156 wu (39 vB) extra room that barely holds an extra HTLC.

TODO: using this calculator gives me a different result, that we can hold 230 outputs in this tx, need to double-check.

Penalty Tx

Given now the package [commitment tx->anchor tx] must be spent together, it may become impossible to submit a package [commitment tx->penalty tx] due to the penalty tx exceeding the 1000 vB size limit. In other words, the commitment tx must be confirmed before the penalty tx can be published. This is different from the current behavior - as long as a revoked commitment is published, the penalty tx can immediately be made and published, without waiting for the commitment tx to be confirmed first.

The exception is when the number of HTLCs is no greater than 7, then the package [revoked commitment->anchor tx] can be replaced using [revoked commitment->penalty tx] under TRCU policy.

Removal of 1 OP_CHECKSEQUENCEVERIFY

All the 1 OP_CHECKSEQUENCEVERIFY that's used for preventing pinning attack can now be removed, given that the additional relay fee is capped at 1000 sats when using the default policy.

Based on BIP125 rules, if a malicious attacker decides to pin the commitment tx inside the package [commitment tx->anchor tx], he/she has to pay a higher fee rate and the additional relay fee. If the chosen fee rate is significantly higher, this is essentially a fee bumping attempt, which makes the commitment tx more likely to get confirmed. If the new fee rate is only slightly higher to fulfill BIP125 requirements, due to TRUC policy, the replacement tx in the package [commitment tx->replacement tx] cannot be greater than 1000 vB, making the cost of the next fee bumping attempt via [commitment tx-> anchor tx] being capped at 1000 sats for the honest party.

For simple taproot channels, this means the to_remote output can now use the key spending path, with the remotepubkey as the internal key.

New Sweeping Strategy

The removal of 1 OP_CHECKSEQUENCEVERIFY means we may have outputs behaving like anchors although they are not anchor outputs. For a typical local force close tx where there is at least one HTLC, we now have two ways to sweep it,

1. Submit the package [commitment tx->anchor tx] first, then sweep the HTLC, which is the current way.
2. Make a new child tx which spends both the HTLC and the anchor, and submit this new package.

The second strategy can save us onchain fees since it uses one tx instead of two. However, this tx cannot hold more than 3 outgoing HTLCs or 2 incoming HTLCs due to the 1000 vB limit (TODO: double check the figures when implemented).

NOTE: the second strategy is only possible when the second-level HTLC transactions are also v3 because the SIGHASH_SINGLE also signs the transaction version.

Removal of update_fee

Now that the commitment tx can use below-min-relay-feerate, there's no need to periodically update the commitment tx feerate as long as it's spent via the package [commitment tx->anchor tx].

Make Funding and Closing Txns v3?

• Zero-fee closing transaction: Instead of paying fees in the cooperative closing tx, it can instead be a zero-fee closing tx, and the local/remote node can choose to spend it via a package whenever needed, e.g., fund another channel via package [closing tx->funding tx], which means the funding tx must also be v3.

• Zero-conf channels: the package [funding tx->closing tx] can be submitted if both parties decide to settle, or [funding tx->commitment tx] can be used if force close is needed when the number of HTLCs is no greater than 16. When the commitment tx exceeds 1000 vB the package [funding tx->commitment tx] cannot be made, which is fine as the funding tx itself can be broadcast alone since it has fees.

[yyforyongyu]

A note to myself - I also want to understand its impact on SPV like neutrino.