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".
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.
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)
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.
DBC tweak individual keys (pay-to-contract)/signatures (for sign-to-contract), taking
containerand message, and producingcommitment(tweaked container version) and modified container, where the tweak information is added. Next, container is split intoproof, which is crucial for client-side-validation and must be carefully kept, andsupplement, 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".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.
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)
When a wallet or an exchange need to to an RGB transfer, it:
This fits into PSBT roles (updater, signer, extractor) and works well with multi-sign workflows, hardware and over-the-air signing devices.
PSBT Keys:
contract_id:transition_idfor all transitions involved with inputsschema_id+owned_right_type(key) to array of state dataAdditionally 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.