Improve peg-outs with dynamic fees

[jkitman]

Currently peg-outs have several serious issues that need to be addressed:

• Fed can pay more fees than users contribute resulting in a negative balance (fed crashes)
• Fed can accept peg-outs that depend on unconfirmed change (fed crashes)
• No way to bump fees on unconfirmed transactions (if on-chain fees suddenly go up, peg-outs can get stuck indefinitely)

Step 1: Add user-determined fees.

• Replace the fixed user peg-out fee with an exact fee based on the current mempool (eliminating peg-out profits/losses for the fed):
• Expose a wallet API that given a (tx amount, peg-out address) returns the PegOutFees = (total sats, sat/byte)
• Users include the PegOutFees in their PegOut requests which can be rejected during consensus proposal if the fed cannot fulfill the request (due to not enough fees or SpendableUTXO)
• The fed requires FeeConsensus < actual fees == PegOutFees (target 10 blocks to confirm)
• Peg-outs are immediately signed and broadcast (rather than aggregated and waiting for an urgency heuristic), so there will be one tx per peg-out request
• Since subsequent peg-outs may need to wait for change (~10-20 blocks), it is recommended that the fed maintains a few SpendableUTXO to handle concurrent requests, although peg-out volume should be low for early use-cases
• Fixed by https://github.com/fedimint/fedimint/pull/276

Step 2: Allow for user RBF

• Allow users to output additional fees to existing transactions either via a new BumpFee output type or by modifying the existing PegOut
• When a BumpFee is accepted the federation should sign and RBF the existing peg-out transaction with the additional fees
• After the tx reaches confirmation finality any fees that did not get confirmed are made redeemable to the user through a mechanism where the user proves they created the initial PegOut

Step 3: Aggregate or Queue transactions

• Long-term if peg-out volume increases eventually users may have to wait for change because the fed cannot maintain enough SpendableUTXO
• In this case either transactions will need to be queued or aggregated so that users do not have to wait around and continually try to resubmit peg-outs
• In either case, RBF will need to be available so that users can adjust fees and receive change as we cannot know ahead of time which transactions will be confirmed on-chain or how fees might increase after a peg-out is submitted.

This issue replaces #1 and #196 with a more up-to-date roadmap for peg-outs.

[dpc]

Allow users to output additional fees to existing transactions either via a new BumpFee output type or by modifying the existing PegOut

The problem is that UTXOs are a shared resource and each individual user potentially has less to loose on the transaction stuck in the mempool, than the rest of the federation combined that might want to use the UTXO stuck in the mempool. Possibly the user doesn't even care at all and is happy to wait a month for the transaction to confirm.

It seems to me that it would be better to somehow have the user overpay for the possible higher fee rate upfront, and either redeem them later if the transaction confirmed at the lower fee rate, or store any difference that mint was able to save into "community fee pool" use it when it's to pay for sudden fee spikes via rbf of cpfp.

[jkitman]

@dpc By default the fees are selected with a max target confirmation time of 10 blocks, which should be okay in most fee markets, which is why I haven't prioritized the RBF feature.

I think you are right that the fed should have a way of freeing up big UTXOs outside of users. Forcing users to overpay is not great UX because most users will want to know exactly what they will be paying before they peg-out. Instead you could have the fed automatically RBF UTXOs when they are stuck for a long enough time period.

Another option we considered is you can use CPFP when you run out of UTXOs. This could cause fees to become larger (because you are paying for multiple txs), but is really the only peg-out option in that circumstance. Fed members could even do peg-outs with their own bitcoin to unstick the UTXOs.

[NicolaLS]

I don't know a lot about CPFP transactions. Do they have more weight/ are more costly in general ? Because if user A pays 2sat/vbyte but then the fees suddenly rise (e.g 14sat/vbyte )and it gets stuck the next peg-out B has to pay 14sat/vbyte anyway so doing it as a child transaction to A wouldn't increase fees (unfairly).

[NicolaLS]

I think offering RBF to A until B shows up and then perform a CPFP tx is a good approach.

[jkitman]

@NicolaLS A miner would sum the vbytes and fees from both txs in CPFP to calculate the combined sat/vbyte.

[NicolaLS]

@NicolaLS A miner would sum the vbytes and fees from both txs in CPFP to calculate the combined sat/vbyte.

ok got it, so it would be unfair to B..

[dpc]

Do they have more weight/ are more costly in general ? Because if user A pays 2sat/vbyte but then the fees suddenly rise (e.g 14sat/vbyte )and it gets stuck the next peg-out B has to pay 14sat/vbyte anyway so doing it as a child transaction to A wouldn't increase fees (unfairly).

CPFP can be great, but indeed it shifts the cost to the second person (B).

Instead you could have the fed automatically RBF UTXOs when they are stuck for a long enough time period.

Yes, but who should pay for it? :)

There are the following choices:

1) Force the second person (B) pay extra for CPFP/RBF of tx of A, if so happens that they need to use this output while it is stuck in the mempool. While it might seem unfair to B, it kind of moves the cost from person with low time preference, to the person with high time preference, so I don't think it's all that terrible. Also, as the Mint builds the peg-out txes and enforces a min feerate, there's no risk of some maliciously large txes being sent with absurdly low fees just to get them stuck. However there is some minor risk of simple tragedy of commons where during the time of slowly yet steadily increasing market fee rates users underpay each time, hoping that someone with higher urgency will pay for them anyway. 2) Have the first person (A) pre-pay upfront "an emergency budget" which would be used to RBF the tx after a while if it did not confirm with a normal fee. In case it did confirm normally: a) give A their money back, or b) just keep these funds around and use them to subsidze bumping fees in case of emergencies etc.

1 is relatively simple, which is nice. However being able to redeem the user might be desirable to have eventually anyway. An optimal way to send funds is never a fixed guess, but to always just bid dynamically with RBF targeting just slightly above minimum that gets us in a block in a given amount of time. Dynamic bidding will require over-paying first, and getting the different back later. Pooling fees makes it more smooth/fair/predictable for all the users, but is additional accounting and might be frowned upon by some regulators.

[jkitman]

@dpc Thinking about it, I suppose (1) is preferable to me because it is the most clear for users and they don't have to worry about checking in later to bump fees / redeem funds.

In practice I'd expect the on-chain use to be rather small since most users will be using LN.

[dpc]

1 is probably a best approach to start with. However I would expect elements of 2 might become necessary eventually, so it's probably worth keeping them in mind.

[elsirion]

1 also has the benefit of allowing to withdraw all your money. I really dislike it when you get a few sats stuck in wallets because they reserve a certain "emergency budget" (e.g. a lot of custodial LN wallets).

[NicolaLS]

@dpc 1. sounds like the best option right now even though I disagree with - somebody maybe having the necessity to move funds quickly - being regarded as higher time preference. I thought 2. sounded even better but @elsirion reminded me about the horrible annoying UX you get with that in his comment (I don't think that it would be a regulatory issue though if its set in stone (code) by the protocol that the "profit" is only temporary).

[NicolaLS]

This Issue made me wonder: We anticipate on-chain usage being very small (compared to lightning) but do we have any mechanic to prevent running out of UTXOs when we get a bunch of lightning peg-ins but a lot of on-chain peg-outs. We shouldn't just rely on the small probability of "on-chain action" in the federation. Maybe a second model in which the on-chain stuff gets outsourced to a BitcoinGateway (can also be a LightningGateway) which would act analogous to the LnGw..?

[dpc]

somebody maybe having the necessity to move funds quickly - being regarded as higher time preference

It's not a moral judgment, just stating the fact of life. Sometimes we can wait, and sometimes we can't and are willing to pay for it. :)

We anticipate on-chain usage being very small (compared to lightning) but do we have any mechanic to prevent running out of UTXOs when we get a bunch of lightning peg-ins but a lot of on-chain peg-outs.

There are always loop-out services available, and I would expect that thanks to batching etc. they might be even cheaper than doing your own on chain transactions.

BTW. I'm a bit fuzzy here, but my understanding is that a gateway will have to deposit funds to the mint first to get notes, so it can facilitate LN incoming transfers, so you can't run out of L1 funds due to LN peg-ins. Unless I misunderstood you or something here.

[NicolaLS]

Sometimes we can wait, and sometimes we can't and are willing to pay for it. :

Even with no moral judgment: the federation adds to the bad situation instead of being neutral in that situation. So the phrasing would be: sometimes we can't wait and are being taken advantage of to pay even more than we would anyway. (I get the point though ;)

BTW. I'm a bit fuzzy here, but my understanding is that a gateway will have to deposit funds to the mint first to get notes, so it can facilitate LN incoming transfers, so you can't run out of L1 funds due to LN peg-ins. Unless I misunderstood you or something here.

No you did not misunderstand, I was just being dumb..thanks for the clarification :)

[jkitman]

@dpc @NicolaLS Yes, the fed always matches assets and liabilities so it cannot run out of funds. On-chain bitcoin is an asset and LN contracts are liabilities. When a LN payment occurs, the fed just facilities the transfer of the LN contract ownership between the user and gateway. Whoever is the owner of that contract can redeem it for on-chain bitcoin (fed assets and liabilities decrease equally) or covert it to ecash (from an LN to mint liability).

TLDR an initial set of gateways or users will need to peg-in so that they can create LN contracts.