Proposed Spectrum tx structure

[dr-orlovsky]

Graphical specification for funding and commitment transactions with RGB proofs:

Notes:

• The chart covers P2C commitment scheme only. Whether OP_RETURN scheme can be used with lightning — and is there any need in using it — should be a matter of separate discussion.
• Here we follow the #93 recommendation, putting the tweaked key in the same output which is used for the channel creation. This is not a requirement, the same workflow will work with the tweaked key (=proof commitment) put into any of the outputs (according to #92) ...
• ... or even into some external transaction. The question is do we need this form of flexibility and why is it needed? As for non-LN part of RGB, it can be useful to allocate the assets to an existing UTXO, but with Spectrum we will have funding on-chain transaction in any way, so I propose to limit channel opening only to vout addressing option.

[dr-orlovsky]

After discussion with @giacomozucco we came to the (preliminary) conclusion that:

1. OP_RETURN commitments are not needed in Spectrum (due to the reason mentioned in the original comment)
2. UTXO-binding of the RGB assets would not be used in Spectrum (also see the reasons above)
3. P2(W)SH within the commitment and funding transactions should not be used for P2C commitments
4. While from the clarity point in the spect it will be nice to describe RGB-only channels first and than adding bitcoin transfers to them later, in the real-world wallets we should not enforce this kind of separation and shall promote joint RGB/Bitcoin channels in order to enable future DEX functionality.
5. A rationale section should be added to the future Spectrum spec clarifying arguments for a such design decisions.

[dr-orlovsky]

An updated complete version:

Key facts:

• LN transactions have very rigid structure: we can't modify the number of inputs and outputs withing commitment and HTLC-timeout/success transactions, so we are limited to P2C pk tweaks committing RGB proofs
• Commitment and HTLC transactions can be tweaked at a fixed points: each of them has only single P2WPKH output (No 1 for commitment and 0 for HTLC transacitons)
• Bitcoins and RGB (multi)assets can be easily combined withing the same channel, opening a route for DEX functionality (exchange in asset/bitcoin pairs on the multi-hop route)
• Since RGB assets are bound to outputs withing LN channel tx structure, they will "follow" the bitcoins from that outputs, meaning that we get all complex LN channel security behaviors for cooperative/unilateral/non-cooperative channel closing, channel updates and multi-hop transfers with HTLCs for "free"...
• ... and we just need to make sure that with each channel operation, when a new partially-signed bitcoin transaction (PSBT) is being generated, we create a proper RGB proof for it and committing to it by tweaking the pk in that single P2WPKH output presented in each type of LN channel PSBT

[dr-orlovsky]

Now part of #105