On-chain confirmation timeout negotiation

[fedsten]

Motivation
While accepting an incoming RGB asset transfer, the payee has to wait the the on-chain confirmation of the Bitcoin transaction committing to the state transition before considering the payment finalised. If the payer sets a too low transaction fee, the payee may end up waiting an indefinite amount of time for the transaction to be confirmed. In the context of RGB, this wait is more problematic compared to normal Bitcoin payments, because during this time the payee cannot use the UTXO dedicated to receive the RGB transfer, as spending it could result in burning the assets she is about to receive.

While the payee has her UTXO effectively frozen, the payer may not be incentivised to solve the situation by increasing the fee with either RBF (which requires changing the consignment) or CPFP, as she may be ok with longer confirmation times in exchange of a cheaper mining fee.

Proposal
To avoid the frozen UTXO problem, a confirmation timeout has to be introduced, so that in the case the Bitcoin transaction is not confirmed before the timeout, the payee can consider the RGB transfer as failed and refuse to release whatever was promised in exchange for the RGB payment, even if after the timeout the transaction is then confirmed.

The length of the timeout needs to be negotiated by the two parties, as the payer has an incentive to keep it as high as possible while the payee would like to keep it as low as possible. The negotiation can be initiated by the payee providing a timeout proposal in a signed invoice, and the payer will accept (or refuse) the timeout proposal by proceeding (or not proceeding) with the payment. Now that the payer has agreed to make sure the Bitcoin transaction is confirmed before the timeout, she will be incentivised to pay and adeguate mining fee and bump it later on if necessary, relieving the payee from the need to keep an UTXO frozen indefinitely.

To avoid confusion when multiple invoices are issued for the same payment, before broadcasting the Bitcoin transaction the payer will also have to ask the payee to confirm that a specific timeout is to be associated with the consignment that is about to be committed in the Bitcoin transaction, in this way it will be always possible to prove towards a third party what were the payment conditions (i.e. timeout and consignment) agreed between the two parties in case of a dispute.

As a best practice, wallets software's UI should also provide the option for the payee to override the timeout, and still accept a late payment if the users wishes to do so.

N.B. this proposal can be considered an extension of the already discussed Proposal for proof-of-payment protocol

[dr-orlovsky]

What is better: to negotiate the timeout or a fee?

[fedsten]

I think we can summarize as follows:

- Time negotiation advantages: as the responsibility to get the transaction confirmed lies with the payer, it is easy to implement fee bumping mechanism and have more flexibility to calibrate the fee. On the other hand, if the tx fails to be confirmed in time and the receiver uses the utxo assigned to the payment, the sent assets will effectively be burned.
- Fee negotiation advantages: once a fee value is agreed on, the sender can considered his job as finished as soon as he broadcast the transaction. However there are here two disadvantages: 1) there is no incentive for the sender to bump the fee later on if necessary, making it possible for transactions to be stuck for long time if fee rate increases (NB in RGB the receiver cannot even do a CPFP to accelerate incoming payments) and 2) in this way the sender has performed all his agreed duties as soon as he broadcasts the transaction, but at the same time before confirmation he still has the ability to double spend, so it is not clear when the payment can be considered finalised.

[fedsten]

A more long term solution was also suggested by Ruben Somsen on Telegram, where he proposed to define a spending condition in the RGB state transition with the tokens going to the payee's utxo if the Bitcoin transaction is included in the chain before block N, while if it gets included after block N the tokens will all be assigned to the change utxo of the payer. In this way the payer is still incentivised to provide sufficient fee and bump it when needed, the payee doesn't need to keep his utxo locked indefinitely and under no scenarios any assets gets accidentally burned.

I personally find this solution very good, but it requires to add a lot of complexity in the RGB transfer, so my suggestion is to start with a best practice for wallets to implement the timeout negotiation as described above, and later on move to an RGB contract enforced solution.