walletrpc: update walletkit.proto to use the new sweep params

lnrpc/walletrpc/walletkit_grpc.pb.go

@@ -179,31 +179,34 @@ type WalletKitClient interface {
 	// the UtxoSweeper, so things may change.
 	PendingSweeps(ctx context.Context, in *PendingSweepsRequest, opts ...grpc.CallOption) (*PendingSweepsResponse, error)
 	// lncli: `wallet bumpfee`
-	// BumpFee bumps the fee of an arbitrary input within a transaction. This RPC
-	// takes a different approach than bitcoind's bumpfee command. lnd has a
-	// central batching engine in which inputs with similar fee rates are batched
-	// together to save on transaction fees. Due to this, we cannot rely on
-	// bumping the fee on a specific transaction, since transactions can change at
-	// any point with the addition of new inputs. The list of inputs that
-	// currently exist within lnd's central batching engine can be retrieved
-	// through the PendingSweeps RPC.
+	// BumpFee is an endpoint that allows users to interact with lnd's sweeper
+	// directly. It takes an outpoint from an unconfirmed transaction and sends it
+	// to the sweeper for potential fee bumping. Depending on whether the outpoint
+	// has been registered in the sweeper (an existing input, e.g., an anchor
+	// output) or not (a new input, e.g., an unconfirmed wallet utxo), this will
+	// either be an RBF or CPFP attempt.
 	//
-	// When bumping the fee of an input that currently exists within lnd's central
-	// batching engine, a higher fee transaction will be created that replaces the
-	// lower fee transaction through the Replace-By-Fee (RBF) policy. If it
+	// When receiving an input, lnd’s sweeper needs to understand its time
+	// sensitivity to make economical fee bumps - internally a fee function is
+	// created using the deadline and budget to guide the process. When the
+	// deadline is approaching, the fee function will increase the fee rate and
+	// perform an RBF.
+	//
+	// When a force close happens, all the outputs from the force closing
+	// transaction will be registered in the sweeper. The sweeper will then handle
+	// the creation, publish, and fee bumping of the sweeping transactions.
+	// Everytime a new block comes in, unless the sweeping transaction is
+	// confirmed, an RBF is attempted. To interfere with this automatic process,
+	// users can use BumpFee to specify customized fee rate, budget, deadline, and
+	// whether the sweep should happen immediately. It's recommended to call
+	// `ListSweeps` to understand the shape of the existing sweeping transaction
+	// first - depending on the number of inputs in this transaction, the RBF
+	// requirements can be quite different.
 	//
 	// This RPC also serves useful when wanting to perform a Child-Pays-For-Parent
 	// (CPFP), where the child transaction pays for its parent's fee. This can be
 	// done by specifying an outpoint within the low fee transaction that is under
 	// the control of the wallet.
-	//
-	// The fee preference can be expressed either as a specific fee rate or a delta
-	// of blocks in which the output should be swept on-chain within. If a fee
-	// preference is not explicitly specified, then an error is returned.
-	//
-	// Note that this RPC currently doesn't perform any validation checks on the
-	// fee preference being provided. For now, the responsibility of ensuring that
-	// the new fee preference is sufficient is delegated to the user.
 	BumpFee(ctx context.Context, in *BumpFeeRequest, opts ...grpc.CallOption) (*BumpFeeResponse, error)
 	// lncli: `wallet listsweeps`
 	// ListSweeps returns a list of the sweep transactions our node has produced.
@@ -687,31 +690,34 @@ type WalletKitServer interface {
 	// the UtxoSweeper, so things may change.
 	PendingSweeps(context.Context, *PendingSweepsRequest) (*PendingSweepsResponse, error)
 	// lncli: `wallet bumpfee`
-	// BumpFee bumps the fee of an arbitrary input within a transaction. This RPC
-	// takes a different approach than bitcoind's bumpfee command. lnd has a
-	// central batching engine in which inputs with similar fee rates are batched
-	// together to save on transaction fees. Due to this, we cannot rely on
-	// bumping the fee on a specific transaction, since transactions can change at
-	// any point with the addition of new inputs. The list of inputs that
-	// currently exist within lnd's central batching engine can be retrieved
-	// through the PendingSweeps RPC.
+	// BumpFee is an endpoint that allows users to interact with lnd's sweeper
+	// directly. It takes an outpoint from an unconfirmed transaction and sends it
+	// to the sweeper for potential fee bumping. Depending on whether the outpoint
+	// has been registered in the sweeper (an existing input, e.g., an anchor
+	// output) or not (a new input, e.g., an unconfirmed wallet utxo), this will
+	// either be an RBF or CPFP attempt.
 	//
-	// When bumping the fee of an input that currently exists within lnd's central
-	// batching engine, a higher fee transaction will be created that replaces the
-	// lower fee transaction through the Replace-By-Fee (RBF) policy. If it
+	// When receiving an input, lnd’s sweeper needs to understand its time
+	// sensitivity to make economical fee bumps - internally a fee function is
+	// created using the deadline and budget to guide the process. When the
+	// deadline is approaching, the fee function will increase the fee rate and
+	// perform an RBF.
+	//
+	// When a force close happens, all the outputs from the force closing
+	// transaction will be registered in the sweeper. The sweeper will then handle
+	// the creation, publish, and fee bumping of the sweeping transactions.
+	// Everytime a new block comes in, unless the sweeping transaction is
+	// confirmed, an RBF is attempted. To interfere with this automatic process,
+	// users can use BumpFee to specify customized fee rate, budget, deadline, and
+	// whether the sweep should happen immediately. It's recommended to call
+	// `ListSweeps` to understand the shape of the existing sweeping transaction
+	// first - depending on the number of inputs in this transaction, the RBF
+	// requirements can be quite different.
 	//
 	// This RPC also serves useful when wanting to perform a Child-Pays-For-Parent
 	// (CPFP), where the child transaction pays for its parent's fee. This can be
 	// done by specifying an outpoint within the low fee transaction that is under
 	// the control of the wallet.
-	//
-	// The fee preference can be expressed either as a specific fee rate or a delta
-	// of blocks in which the output should be swept on-chain within. If a fee
-	// preference is not explicitly specified, then an error is returned.
-	//
-	// Note that this RPC currently doesn't perform any validation checks on the
-	// fee preference being provided. For now, the responsibility of ensuring that
-	// the new fee preference is sufficient is delegated to the user.
 	BumpFee(context.Context, *BumpFeeRequest) (*BumpFeeResponse, error)
 	// lncli: `wallet listsweeps`
 	// ListSweeps returns a list of the sweep transactions our node has produced.