Borrower coin selects before deciding on the fee

[luckysori]

Very early on in the design of the loan protocol we decided to let the borrower control the transaction fee, since they are the party contributing the bitcoin to the loan transaction (Liquid transaction fees can only be paid with bitcoin).

Specifically, the borrower gets to choose the amount of satoshis per vbyte for the fee, and once the loan transaction is constructed that value is used to calculate the actual fee.

The borrower also selects some inputs to pay for the collateral they put up, but they do so before the actual fee is calculated. This can be problematic if they forget to account for this yet-to-be-calculated fee during coin selection. Requiring users of the library to understand how the protocol works and that they must provide inputs covering the collateral amount + an undefined fee is not good UX.

I see a few alternatives to solve this problem (if we want to solve it), but there could be more:

1. Let the borrower commit to a fee earlier on, so that they can account for the concrete value when coin selecting. Calculating a reasonable fee would be the borrower's responsibility, but without knowing the exact structure of the transaction, which is something that we currently take advantage of here:

   baru/src/loan.rs

   Lines 1104 to 1106 in 4bc7525

   	let tx_fee = Amount::from_sat(
   	estimate_virtual_size(inputs.len() as u64, 4) * fee_sats_per_vbyte.as_sat(),
   	);

2. Let the lender choose and pay for the fee instead. It makes constructing the transaction a bit more complicated (hopefully simple again once we use PSETs), but the lender knows the structure of the transaction by the time they add their inputs.
3. Do not add a fee output directly to the loan transaction and instead use a fee bumping technique such as Child Pays for Parent (CPFP). We've talked about something like this in the past, but we've never tried it AFAIK.

[thomaseizinger]

Let the lender choose and pay for the fee instead. It makes constructing the transaction a bit more complicated (hopefully simple again once we use PSETs), but the lender knows the structure of the transaction by the time they add their inputs.

I think I am in favor of this. You could argue that the transaction fees are "operating costs" and need to be covered by the interest that the lender is earning.

Why would it make constructing the transaction more complicated?

[luckysori]

Why would it make constructing the transaction more complicated?

If the lender pays for the fee, then they need to add a bitcoin input on top of their principal input, plus a likely change output for the leftovers after covering the fee.

[luckysori]

Also, do you think doing 3 is a bad idea or the wrong approach? The lender would still be responsible for paying for the fees since they're the one who broadcast the loan transaction.