Proof-of-payment protocol

[fedsten]

Motivation
When you perform a payment, it is important to be able to prove to third parties that the payment was indeed finalized correctly. This is relevant for example in case of disputes between parties or when dealing with service providers such as centralised exchanges. With normal Bitcoin transactions, you always have the blockchain as a source of truth to testify that a specific transaction did indeed occur as agreed between the parties and was finalised. However, in RGB there is the consignment data which is transferred off-chain, with no on-chain record to prove that the consignment was truly delivered to the payee.

Proposal
To address the issue, an interactive protocol is needed, with the requirement for the payee to provide a signed receipt of received consignment before the payer proceeds to perform the Bitcoin transaction to close the single-use-seal. Specifically, the protocol should include the following steps:

1. The payee sends an invoice to the payer.
2. The payer sends the consignment data to the payee.
3. The payee validates the consignment.
4. The payee sends a signed receipt to the payer acknowledging that the correct consignment was received and validated.
5. The payer closes the on-chain single-use-seal, and commits the consignment in the output of the Bitcoin transaction.
6. The payee monitors the blockchain and as soon as the Bitcoin transaction receives a sufficient number of confirmations, the payment is considered finalised. In case the RGB assets are being moved on a Lightning Network payment channel, the payment will be considered finalised when the channel is updated.

[fedsten]

Adding to this proposal, I believe that something that needs to be agreed on between the two parties is also the network where the transactions is going to be broadcast to (e.g. mainnet, testnet, signet, sidechains etc). We surely do not want the payee to monitor a different blockchain from the one where the Bitcoin transaction has been sent to.

[dr-orlovsky]

The nework is already a part of RGB invoice created by the payee: https://github.com/LNP-BP/presentations/blob/master/Presentation%20slides/Universal%20LNP-BP%20invoices.pdf

[dr-orlovsky]

This is more detailed workflow which includes also Storm nodes (storm is a protocol for Lightning network [Bifrost specifically] for storage; it works alike torrent here). Storm node may be run by payee, payer - or by wallet provider. Advantage of the storm comparing to centralized server is the fact that (a) it is interoperable protocol, (b) re-uses LN connectivity, (c) minimizes amount of data transfer, (d) may include storage incentivization with LN payments.

Invoice should contain:

• Optional storm node addresses (the same as LN node addresses), if storm nodes are provided by payee or payee wallet
• LNPBP-38 invoice made of either:
  • bitcoin address
  • blinded UTXO address
  • descriptor (for recurrent payments)
  • PSBT (for payjoin protocols)
• Time (in blocks) for witness tx mining
• Signature over this information

Payment slip is a compact data structure providing payee with the following information:

• Updated witness tx (which may change due to change of the fee)
• Signature for the witness transaction (such that payee may re-broadcast it if necessary)
• Consignment id to request from storm node
• Storm node addresses (the same as LN node addresses), if they were not provided in invoice
• Signed confirmation from the storm node on full consignment upload

sequenceDiagram

participant payee as Payee
participant payer as Payer
participant blockchain as Bitcoin blockchain
participant storm as Storm nodes<br>(trusted)

payee -) +payer: Invoice
payer ->> payer: Prepare consignment
payer ->> payer: Compose witness tx

payer -) +storm: Upload consignment manifest
storm -) payer: Missed chunks
payer -) storm: Upload missed consignment chunks
payer -) storm: 
payer -) storm: 
storm -) -payer: Confirmation of complete upload
payer ->> -payee: Payment slip

activate payee
payee -) storm: Request storm manifest
storm -) payee: Consignment manifest
payee -) storm: Download consignment chunks
storm -) payee: 
payee -) storm: 
storm -) payee: 
payee -) storm: 
storm -) payee: 
payee ->> payee: Verify consignment
payee ->> -payer: Singature

activate payer
payer ->> payer: Sign witness tx
payer -) blockchain: Publish witness tx
activate blockchain
blockchain -) payee: Mempool notification
activate payee
payee ->> payee: Include consignment into stash
payer -) -blockchain: RBF witness tx
blockchain -) -payee: Block header notification
payee ->> -payee: Update contract state

Loading

[dr-orlovsky]

@fedsten which key should be used by the beneficiary to sign the consignment? The simple answer "the same as was used in creating invoice" is not a good one: a malicious sender (or a man-in-the-middle) may re-do the invoice with his own signature and than sign the consignment, claiming that the beneficiary has accepted it, while it had not.

In fact, invoice signatures and receipts require identity system. A simple solution might be to use the same bitcoin key as in the UTXO which receives the payment, but currently we hide the UTXO from the payee to preserve the privacy, so this will also not work.

[fedsten]

My assumption was that a public key need to be specified in the invoice, so that it can be used to verify the signature and potentially also to encrypt data if the communication channel used to exchange the consignment is not considered safe enough.

[dr-orlovsky]

In this case it is not hard to do a fake invoice with fake public key (for instance in the man-in-the-middle attack)

[fedsten]

Yes with payments in general the invoice sharing is assumed to happen on a secure channel, we could have an identity system on top but then you just move the problem to "how do I discover the true identity of my counterparty". I believe that by having signed receipts we do not want the payer to have a proof of the counterparty identity, but rather to have a proof that the payment was performed respecting the agreement signed with the supposed counterparty. Identity verification is another problem that requires much more engineering efforts.

[dr-orlovsky]

Agree. Than the pubkey from the invoice is the identity for RGB, so it will check the signature on the consigment to be from the same identity as in the invoice.

[fedsten]

I was also thinking that by having a signed receipt before the transaction is finalised, it is no more needed to sign the invoice. The invoice only provides info on how the payer should build the consignment, then after there is a candidate consignment the receiver can sign it to produce the proof of payment, signing also the invoice is redundant (while making QR codes harder to scan).