Transaction-RGB transition & DBC coordination workflow for wallets & exchanges

[dr-orlovsky]

1. DBC tweak individual keys (pay-to-contract)/signatures (for sign-to-contract), taking container and message, and producing commitment (tweaked container version) and modified container, where the tweak information is added. Next, container is split into proof, which is crucial for client-side-validation and must be carefully kept, and supplement, which may be reconstructed from other data (transaction graph etc). Tweaking factor is a third part of container.
   Further development: CommitEmbed scheme API must take container and message, and produce commitment_factor (tweaking factor) and embedded_commitment. Or, the procedure must be split into "commit" and "embed".

2. LNPBP4 allows to assemble multiple messages under many protocols and produce a single embeddable commitment, which acts as a message for (1). Some source data must be kept as another proof.

3. RGB takes both proofs and stores them as a parts of anchor. It also stores tweaking factor separately as a second structure next to anchor (and a part of stash, since it's loss may result in data loss, not necessary RGB, may be bitcoins, so it's still crucial part of CSVD)

4. When a wallet or an exchange need to to an RGB transfer, it:

   • drafts PSBT with all necessary inputs and outputs
   • asks RGB Node about outputs that can be spent in order to make a transfer of desired state & construct a state transition
   • asks RGB Node to extend information, which include:
     • filling in all tweaking factors for inputs, if any
     • additional data on other state for inputs
     • putting state transition and DBC stack as a part of output information
     • adding information to inputs about closed seals
       this is mostly done by LNP/BP Core library using stash API
   • with such PSBT it can use hardware or other wallet to create all necessary commitments AND signatures
     • for commitments, wallet will use LNP/BP RGB & DBC (for other CSV protocols) functions
     • it will add all proofs to PSBT
   • this PSBT is passed back to the RGB Node so it can store the necessary data into stash and remove them from PSBT

This fits into PSBT roles (updater, signer, extractor) and works well with multi-sign workflows, hardware and over-the-air signing devices.

PSBT Keys:

• DBC
  • input: tweaking factor per public key
  • output: public key to tweak
  • output: LNPBP4 multimessage structure and protocol-specific sources of the messages (see below)
• RGB
  • global: genesis for each involved contract
  • global: schema for geneses not committing to the root ones
  • RGB version feature flags per contract is already part of schema
  • global: map of contract_id:transition_id for all transitions involved with inputs
  • input: map of schema_id+owned_right_type (key) to array of state data

Additionally to PSBT, some sort of "partial RGB state transitions" (PRGBT) is required to construct multi-party state transition related to multiple transactions.

For invoicing, we need different form of PSBT, which will not contain any of the referenced information (only asset info, amount and scriptPubkey structure).

Consignment must contain tweaking information for outputs associated with endpoints.