Idea: RGB-extended Bitcoin transaction validation about spec HOT 7 CLOSED

Continuing from this thought:

1. The pay-to-contract construction is placed on outputs.
2. Signatures, which commit to how an output will be distributed, are placed on inputs.

If we were to use pay-to-contract, then it becomes difficult to extend RGB to all possible future extensions of Bitcoin, and systems on top of Bitcoin.

So, remembering that the below involves novel cryptography that is made by a non-mathematician:

Dual-commitment ECDSA Signatures

ECDSA signing requires generation of a random point R from a secret r scalar. The x-coordinate of this R is then part of the final signature.

We can instead generate R from the below:

q = random()
Q = q * G
R = Q + h(Q || rgb_sighash) * G
r = q + h(Q || rgb_sighash)

Where rgb_sighash is similar to the SegWit sighash of a transaction, except the RGB-level transaction includes additional fields (number of assets in each input, number of assets in each output).

The resulting signature (R.x, s) commits not only to the Bitcoin-level transaction onchain (via s), but also to the RGB-level transaction (via R.x). Third-party malleability can only affect the sign of s but not the sign of R.x.

Onchain, SegWit witnesses are committed to in the witness Merkle tree on the coinbase.

Someone sending an RGB asset MUST then provide the chain of RGB transactions, and the points the equivalent Bitcoin-level transaction are confirmed onchain.

The witnesses for the Bitcoin-level transaction, the signatures, includes a commitment to the RGB-level transaction.

from spec.

This however has the massive advantage that RGB can be made to work with any valid Bitcoin transaction. This means that any future offchain protocol can, with some effort, be made to work with RGB assets.

With my poor understanding, I don't see why a modular approach based on a subsequent validation outside of Core, could not be adapted as well. What I'm missing?

from spec.

It has been some time since I wrote my above blathering nonsense, but if I remember my thinking correctly:

1. Ideally, the paint applied by RGB should be invisible to Core.
2. However, the paint applied by RGB should be visible (possibly with some additional paint-identification information) to RGB.
3. Ideally, the paint applied by RGB should be applicable to any contract encodable in Bitcoin SCRIPT, not just some subset of scripts.

A "plain" painting scheme would be to require payment to a P2PKH whose public key is computed using pay-to-contract.

However, it would only apply to P2PKH.
If we wish to use some other contract type, then it is incompatible with this painting scheme.

The initial idea is a hare-brained thought to allow a signature to commit, not just to a Bitcoin transaction, but also to an RGB paint color.
If paint is carried by signatures rather than particular SCRIPT templates, then Bitcoin Core is unaware of the color, but it is possible to show to an RGB implementation that yes, the signature does indeed commit to this output having a particular paint, which is also applied to this output and that output.

from spec.

Thank you to try to explain. It seems to me I got something more.

So what you are saying is, if I understand it correctly, that the present design of RGB is applicable only to particular script templates (namely P2PKH) and not to a generic transaction (for instance) P2SH, because the signature commit to the transaction but not to the RGB paint color.

If we put the paint in the signature, then it becomes "script agnostic" but this would require a "forked" version of Bitcoin Core and it would not be possible/convenient to put the verification of the color in an "external" program.

This, from a maintenance perspective would be a big burden, because it would require a lot of additional and very critic rebases. It is a big choice. Needs pondering.
Thank you again for your thoughts and your explanations.

from spec.

If we put the paint in the signature, then it becomes "script agnostic" but this would require a "forked" version of Bitcoin Core and it would not be possible/convenient to put the verification of the color in an "external" program.

What I am proposing is to fork only the SCRIPT interpreter, not the entire Bitcoin Core.

After all, if you have an instance of Bitcoin Core that already considers the transaction as valid (for Bitcoin), then you can have a separate external program that gets the SCRIPT, the witness stack, and a version of the transaction that includes RGB-specific data (e.g. asset types, how many assets go to which outputs) and outputs whether the transaction is valid (under RGB rules) or not.

You can keep the RGB-specific data in an (untrusted!) peer, and verify that the signatures in the witness stack commit to the full RGB-level transaction, while the signatures themselves are also valid for the Bitcoin-level transaction.

In particular, there is no consensus change in Bitcoin Core. Bitcoin Core is aware only of Bitcoin-level transactions. If an RGB transaction is valid at Bitcoin-level but is invalid at RGB-level, then the RGB assets have been burned, but the only one who can do this burning is the owner of the asset, so it is indistinguishable from the case where somebody acquires an asset, then loses the private keys in an information-theoretically-unrecoverable manner.

Admittedly, if improvements like Simplicity pan out and get into Bitcoin Core we would have to also include it, but as I understand it the Simplicity code itself is relatively modular.
The only change needed is a change in the behavior of CHECKSIG-equivalent to check both Bitcoin-level and RGB-level transactions.

This allows us to have no special casing (at the RGB-onchain-level; obviously RGB-aware Lightning implementations still need to special case it) when RGB assets go through Lightning, especially if Lightning changes how channels are implemented.

This assumes that reimplementing Bitcoin SCRIPT (and only Bitcoin SCRIPT) is not so hard, and that changes in SCRIPTing are not so hard.

SCRIPT is a stack machine and is relatively easy to implement. Of course, Bitcoin history means that there are many many tweaks to the SCRIPT interpretation.

I would like to point out also that RGB-validity is dependent on Bitcoin-vaildity. So it is OK if RGB reimplementation of SCRIPT accepts more transactions as valid than Bitcoin does; if the RGB transaction is not accepted (after being stripped of RGB-specific data) by a stock Bitcoin Core, then it is still RGB-invalid even if the SCRIPT execution in RGB accepts it. Thus, small deviations between RGB SCRIPT and Bitcoin SCRIPT interpreters can be acceptable.

A caveat, again, is that putting the paint in the signature is an idea made by a non-mathematician and you should really find a mathematician to check if that idea is at all good. For all you know I am just trying to backdoor you.

So let me propose the following concrete process:

1. An RGB implementation receives an RGB transaction that purports to be valid.
2. That RGB transaction has an equivalent Bitcoin transaction after stripping of RGB-specific data (i.e. if the RGB-specific data (asset colors, asset issuance, what assets go to which outputs) is just concatenated to a standard Bitcoin tx, stripping is trivial).
3. The RGB implementation checks if the equivalent Bitcoin transaction is valid according to a stock Bitcoin Core implementation.
4. This is verified if (a) the Bitcoin tx is in a block that Core considers valid (b) the tx is in the Core mempool or (c) doing sendrawtransaction adds it to the Core mempool.
5. The RGB implementation then checks if the RGB transaction is valid under RGB rules.
6. The RGB implementation checks if the RGB transaction spends from a known-valid RGB transaction and that the asset types and asset issuances match up.
7. Then SCRIPT from the inputs is executed, with the modification that CHECKSIG and similar operations verify the RGB transaction is committed to in the signature via the R.

This allows the RGB implementation to be separate from a stock Bitcoin Core.

from spec.

I'm not a mathematician either, but I also like the idea of "painting" signatures (fun fact: that was actually in the spec originally as you can see from this commit 774d38e).

The reason why we migrated to pay to contract is that what you described works only as long as you have a single signature script. In the case of multisig (well, today's multisig, I'm ignoring Schnorr at the moment) it's impossible to enforce, at the Bitcoin level, that all signatures commit to the same data. So, even though none of the parties in a multisig address could steal the tokens, the last signer could sign with a wrong commitment (or just don't reveal the parameters needed to check it) effectively burn the asset for everybody.

You can imagine that we don't want this to happen, especially in a protocol that is meant to run on Lightning Network, aka "Multisig with random people on Tor" 😄

from spec.

I understand.

from spec.