[feature]/sweeeper: add P2A + Ephemeral Dust awareness to BumpFee command

[Roasbeef]

Is your feature request related to a problem? Please describe.

With the latest version of bitcoind, developers have gained some new tools that can be used to have more flexibility w.r.t fee paymetn for transactions, while also mitigating some of the common transaction pinning/recycling vectors:

• P2A:
  • A new standard script template type of: OP_1 <0x4e73>. Can be spent with an empty witness. Meant as a "standard" anchor template. It's small as there's no witness needed to spend it.
• Ephemeral dust:
  • You can have a very dust output (can even be zero value) if the transaction creating the output is actually zero fee. This also MUST be spent by a child to be included within a block. Also only a single child is allowed.
• TRUC:
  • Modified version of BIP 125 (RBF), adds additional restrictinos to protect against unwarranted adversarial transaction replacement.

Many higher-level protocols, including LN want to use some or all of the features above to simplify fee payment. The most common case is having a transaction with zero fee, then using P2A (and others) pay for the fee purely via CPFP.

Today we don't have an easy way of allowing developers to access the above. lnd's sweeping capabilities are rather sophisticated, so it'd be great if we also allowed developers to submit zero fee transactions to be swept.

Adding this capability would also be a stepping stone to enable the new V3 zero fee commitment transaction format as well. In that case, every force close would actually do BumpFee under the scenes.

Describe the solution you'd like

We should extend BumpFee to support this hybrid broadcast and fee bumping concept:

• A new argument that passes in the serialized parent transaction should be added.
• During bumping, if we have this transaction and it has a P2A output (or zero value or below dust), then we assume that the parent transaction is zero fee (we can add an arg for that too if needed):
  • In this case, we'd add it as an input, but with the extra dependancy that each time we broadcast a sweep, we should also broadcast the parent before that.
    • If the backend supports it (may need to require it), then we can use the new submitpackage calls.
    • testmempoolaccept has some cursory support for this type of package, but AFAIK, it isn't a first class feature.
  • We'd then add a new witness type for this output variant, which just uses an empty witness if it's P2A.
  • As an added restriction, we may want to make this an exclusive group (txn too), just so we don't inadvertently violate any of the new policy rules (which don't have great documentation as is, outside of the bitcoind code and integration tests).

We may also need a very basic internal package representation as well, though for now there can only be one parent and one child.

[bhandras]

I'd argue that we should instead consider adding a separate SubmitPackage RPC. The reason is that BumpFee is documented as "bump an input already queued in the sweeper, optionally via CPFP," and broadcasting a zero-fee parent along with its fee-paying child isn’t really a bump. It's a new atomic package broadcast. Calling it SubmitPackage would better reflect what it actually does.

Package-level rules like P2A anchors, ephemeral-dust outputs, and TRUC/v3 relay apply to the entire package rather than individual transactions.

Keeping this logic in a separate RPC allows the sweeper to stay focused on feerate estimation and batching. The new RPC could take care of anchor, dust, and policy validation in one place. Separation would also make it easier to support multi-parent packages in the future.

[bhandras]

If you agree, happy to create a PoC.

[bhandras]

Update: here's a PoC version (still a bit wip): #9784
I think one advantage of having this preliminary work even if we decide to extend BumpFee is that all the plumbing will be done by the time that design is finalized.

[Roasbeef]

The reason is that BumpFee is documented as "bump an input already queued in the sweeper, optionally via CPFP,"

Perhaps the docs you're referring to are out of date? BumpFee as is can be used to sweep any input, and it doesn't need to be queued in the sweeper yet, see this function:

lnd/lnrpc/walletrpc/walletkit_server.go

Lines 1342 to 1347 in 8b413e8

	// sweepNewInput handles the case where an input is seen the first time by the
	// sweeper. It will fetch the output from the wallet and construct an input and
	// offer it to the sweeper.
	//
	// NOTE: if the budget is not set, the default budget ratio is used.
	func (w *WalletKit) sweepNewInput(op *wire.OutPoint, currentHeight uint32,

.

What I describe here would expand this section to recognize P2A:

lnd/lnrpc/walletrpc/walletkit_server.go

Lines 1396 to 1407 in 8b413e8

	var witnessType input.WitnessType
	switch utxo.AddressType {
	case lnwallet.WitnessPubKey:
	witnessType = input.WitnessKeyHash
	case lnwallet.NestedWitnessPubKey:
	witnessType = input.NestedWitnessKeyHash
	case lnwallet.TaprootPubkey:
	witnessType = input.TaprootPubKeySpend
	signDesc.HashType = txscript.SigHashDefault
	default:
	return fmt.Errorf("unknown input witness %v", op)
	}

I'd argue that we should instead consider adding a separate SubmitPackage RPC.

I agree that no matter what, lnd needs to gain the capability to call the submitpackage call on a backend that supports it. I think the difference in approach is if we should expose the low level command to the caller, or make a nicer wrapper around it.

If you consider the neutrino backend, then we don't have any such of RPC to call. However, we could detect the backend, then just publish them one after the other, relying on 1p1c behavior.

Package-level rules like P2A anchors, ephemeral-dust outputs, and TRUC/v3 relay apply to the entire package rather than individual transactions.

Correct, the sweeper will always call testmempoolaccept before trying to publish a transaction. The latest version of this call accepts multiple transactions, which must be passed in using topological order. The new command will then apply the policy rules to decide if a package might be accepted or not.

I think the main difference between exposing a low level SubmitPackage vs this higher level extension to BumpFee is that:

• SubmitPackage requires the caller to do all the signing and input selection needed to construct the fully signed package. As this is done over RPC, it needs to take care to do all the proper book keeping like input locking, etc. The caller then needs to handle progressive fee bumping themselves.
• BumpFee allows the caller to submit only the signed zero fee parent transaction. All the logic we have re adding inputs until an adequate fee rate is reached can be re-used. If the caller wants to increase the fee further, then we're able to automatically RBF that CPFP transaction to increase the fee rate (it can also take advantage of auto fee function bumping, which we'd want for the v3 commitment transactions).