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]

You brought up a very good point!

May I again ask you to move this to the standard proposals in https://github.com/LNP-BP/LNPBPs/discussions/categories/standard-proposals, since this repo is not related to the RGB protocol specs and just a note implementing data storage.