RGB payment workflow scenarious

[dr-orlovsky]

Scenarious

1. Bob is first-time user having no RGB (but having bitcoins)
2. Bob is first-time user having neither RGB nor bitcoins
3. Bob already has RGB tokens
4. Bob would like to receive LN payment with RGB tokens
5. Bob would like to receive RGB tokens non-interactively and/or recurrently

Design criteria:

• Preserve as much privacy about pub keys, addresses and owned UTXOs as possible
• Reduce interactivity
• Prevent possibility of RGB assets loss b/c of non-intentious output spending with non-RGB-enabled wallets
• Support outputs with modified/tweaked keys
• UX simplification: reducing the friction for users to operate

Scenario details

1. Onchain payment, Alice -> Bob; Bob is a bitcoiner, but first-time RGB user:
   1.1. Bob derives new master subkeys at m/82'/0'/...
   1.2a. Bob wallet generates an address with m/82'/0'/0/N encoded as normal bitcoin address
   1.3a. Bob sends to this address bitcoin payment (also from some other wallet) from his other output
   1.4a. Bob generates payment invoice with blinded newly-created UTXO
   -- if Bob do not need to keep privacy of his UTXO --
   1.2b. Bob creates PSBT spending to the new address
   1.3b. Bob makes PSBT-based RGB invoice
   1.4b. Alice does the payment; tx includes (a) Alice change, (b) Bob tokens, (c) single-use-seal witness
   1.5b. If single-use-seal witness happens to Bob's token output Bob will get tweaking factor from PSBT sent alongside consignment
   1.6. Alice sends consignment to Bob; Bob awaits transaction mining and merges consignment to his stash

2. Onchain payment, Alice -> Bob; Bob is new to bitcoin
   2.1. Bob creates seed and derives a new master subkeys at m/82'/0'/...
   2.2. Bob wallet generates an address with m/82'/0'/0/N encoded as normal bitcoin address
   2.3. Bob sends miniscript-based RGB invoice
   2.4. Alice creates transaction paying some satoshis to Bob's output
   2.5. If single-use-seal witness happens to Bob's token output Bob will get tweaking factor from PSBT sent alongside consignment
   2.6. Alice sends consignment to Bob; Bob awaits transaction mining and merges consignment to his stash

3. Onchain payment, Alice -> Bob; Bob already has RGB tokens
   3.1. Bob creates UTXO-based invoice with blinded output, which scriptPubkey contains public key derived from m/82'/0'/...
   ... the rest is proceeded as usual ...

4. LN payment
   4.1. Bob needs to ask Alice to establish a channel with him (Alice can be a payment hub/exchange)
   4.2. (optionally) Bob computes route (normal LN process) to Alice providing her with routing hints
   4.3. Bob generates LN RGB invoice - an extension to LN invoices with additional info on asset type
   ... payment proceed as usual for LN invoices ...

5. Bob needs to receive non-interactive, "anyone can pay" or repeated payments onchain (LN non-interactive and recurrent payments follow LN rules)
   5.1. Bob derives a new master subkey branch under m/82'/0'/...
   5.2. Bob shares his miniscript-based RGB invoice containing xpubkey information
   5.3. Alice does recurrent or non-interactive payments, allocating some satoshis for Bob's outputs in witness transactions. Consignment with all required information are sent to Bitforst server provided by Bob as a part of the invoice

Formats

Invoices

• Blinded UTXO-based
• PSBT-based
• miniscript-based
• LN-based

Data structures

• RGB-specific extended pub and private keys for mainnet, signet and different forms of scriptPubkey. Used in (a) wallet exports, (b) in PSBTs
• PSBT proprietary keys for:
  • single-use-seal tweaks
  • information on which key is tweaked
  • blinding information on UTXOs (or pointers to the blind factors)
  • xpubkeys in RGB format
  • RGB amounts? (for simplification & double checking)

[St333p]

The LN workflow is not completely clear to me.

4.2. Bob computes route (normal LN process) to Alice

Isn't the sender computing the route in the regular LN process? The receiver can include routing hints about private channels in the invoice to ease path finding, but IIRC the sender is the one constructing the onion.

Moreover there is a liquidity issue: If Bob is the one opening a channel towards Alice or a hub, then all of his liquidity over LN will be outwards and he won't be able to receive a payment over LN unless someone opens a inbound channel or he performs some kind of rebalancing over the channel.

I guess a reasonable initial workflow for a Alice -> Bob LN transaction (I tend to think about Alice as an exchange) can be:

• Bob sets up a LN node
• Alice opens a channel to Bob with a larger capacity than the transacted amount
• Bob creates an invoice for the amount he wants to receive
• Alice pays the invoice
• Bob now has both inbound and outbound capacity and all of the connectivity that Alice has

For plain LN it's possible to include a first commitment transaction directly during channel creation, which would greatly reduce human interactivity; I would expect the same to be possible for RGB as well.

[dr-orlovsky]

Isn't the sender computing the route in the regular LN process?

It is, however the payee can provide routing hints and include them into LN invoice, so I put emphasize on this part here, especially b/c Bob (payee) needs to make sure that the route for the payment indeed exists

Moreover there is a liquidity issue: If Bob is the one opening a channel towards Alice or a hub, then all of his liquidity over LN will be outwards and he won't be able to receive a payment over LN unless someone opens a inbound channel or he performs some kind of rebalancing over the channel.

Good point

I guess a reasonable initial workflow for a Alice -> Bob LN transaction (I tend to think about Alice as an exchange) can be:

This will work

[St333p]

It is, however the payee can provide routing hints and include them into LN invoice, so I put emphasize on this part here, especially b/c Bob (payee) needs to make sure that the route for the payment indeed exists

I'm not sure Bob can ensure a path exists. He can provide a possible path, but whether that path contains enough liquidity has to be tested by trying to pay. Even if Bob was able to fake a payment trial to test for liquidity on the path, nobody can ensure that the situation of middleman channels will not change during the time needed for the "human" interaction between Alice and Bob.

[dr-orlovsky]

Note: look how this scenarios can be combined with LNURL

[dr-orlovsky]

Tradeoff comparison table for different RGB invoicing options:

Feature	Blinded UTXO invoices	PSBT-based invoices	Miniscript-based invoices	LN-derived invoices
Repeated and "anyone can pay" payments	with set expiration date only	not possible	work well	works like in LN
Confidentiality	very good	single UTXO exposed	payee pubkeys exposed	good
Non-RGB transaction batching for payee	not possible	possible	possible	not possible
Interactive signature scenarious (multisigs, payjoins etc)	not possible	possible	not possible	not applicable
Invoice data size	small	large	medium	medium
Can be used by payee w/o UTXOs avaliable	no	yes	yes	no

[dr-orlovsky]

Results of analytical call with @giacomozucco regarding this issue:

• These workflows do not capture LN-based scenarious; basically we need one corresponding LN scenario for each onchain scenario
• All four invoice formats are required
• All of them must be encoded using bech32 standard in a similar way
• There must be a possibility for failback options in LN invoices (like do an onchain payment if there is no path)
• Work on bitcoin-wide miniscript/descriptor invoices is required
• Work on LN-wide channel opening invoices is required
• In perspective, Bifrost-based & LNURL compatible interactive invoicing protocol may be designed (with embedded support for all four invoice mechanics)