Subject: Re: [bitcoin-dev] RGB protocol announcement

From: Dr Maxim Orlovsky <[email-masked]>
Date: Tue, 18 Apr 2023 23:16:05 +0000

Hi Harding,

This is the continuation from my previous e-mail [1] addressing the
largest and last unanswered question from your reply:

> To give my own example of the problem <… description follows …>

I am not entirely understand your argument or question, even though
I have spent a lot of time trying to crack it. For me it seems that
this is due to different paradigms we are thinking in. Client-side-
validation and work on RGB had required me to dramatically change 
the way I see distributed systems, bitcoin and other “blockchains” 
and multi-party contracts, thus this may have caused inability to 
speak in the same terms. For me, the setup you are describing 
doesn’t make sense at all: there is no reason of doing things with
RGB that way. I.e, you are suggesting invalid setup - and then 
prove that it is not working :).

I will try first to explain why I think the reasoning you are 
putting into the argument is invalid in the assumptions: nobody 
should expect that RGB somehow magically makes on-chain BTC (I will 
use this acronym to distinguish BTC-as-money from bitcoin-as-
blockchain or tech) more programmable or anyhow better: it is 
impossible without softfork or a hardfork on _blockchain consensus_ 
level. What is possible is to add functionality on top of that; but
anything additional won’t work for BTC unless it is “lifted” into 
that new layer. This is true with sidechains, this is true with 
Lightning, this is for sure true with RGB. So any setups we are 
analyzing must analyze such lifted BTC* in RGB as a value, and not
an on-chain. Next, most forms of contracts do not require a new 
token, so I propose not to make setups more complex and start 
discussing them without introducing a new tokens unless it is 
really required.

Now, my setup to cover your case (or at least what I understood 
from it) would be the following:

1. Assume we have some BTC lifted to RGB, which we will name BTC*.
   (let’s leave the question on how to do that aside; it can be 
   discussed separately).

2. > Bob doesn't believe that there's a number which can be
   multiplied by to produce 4. He's willing to pay a bounty for
   proof that he's wrong.

   This part I will take from your letter without changes, however 
   will skip the rest about production of some tokens etc, which 
   is unnecessary here.

(Please correct me if I am wrong in understanding what you wanted
to achieve and I will correct it - for instance I can't understand
why we need some Carol(s) at all).

To fulfill the described setup, Bob have to create a new RGB 
contract (its **genesis**) featuring BTC* AND providing the 
following conditions (in the contract **schema**, which is a part 
of genesis):

1. The value of BTC* is preserved within the contract not attached
   to any of UTXOs (it has become possible with RGB v0.10 
   introduction of “global state”)

2. BTC* can be reclaimed by any party providing a solution (in form
   of RGB **state extension**) which is verified by AluVM. Alice, 
   if she have found the solution, now can **assign** that 
   previously “floating”/unowned BTC* to an UTXO she controls. 

   State extensions were introduced into RGB in late 2020 v0.4.
   State extensions are different from a normal state transitions 
   by the fact that they do not have inputs referencing some 
   previously-owned (i.e. assigned to an UTXO) state, i.e. their 
   creation doesn’t require creation of a corresponding bitcoin 
   transaction spending some UTXOs with a state (as it is in case 
   of a state transitions).

3. To ensure uniqueness of the winner (i.e. prevent 
   “double-spending” of “free-floating”/unowned BTC* from the 
   contract global state) Alice is also required (by the contract 
   conditions defined by Bob in the contract schema) to post some 
   identifiable information into a mined bitcoin transaction
   on-chain (NB: this is not the same as a witness transaction; it 
   can be any transaction not related to the contract UTXOs in any 
   way). The transaction must contain a pre-defined signal in a 
   form known only to the contract participants; for instance some 
   pre-defined random value stored in OP_RETURN, address, value, 
   witness, pay-to-contract tweak of some pre-defined pubkey - or 
   anywhere else. This can re-use a transaction which can be mined
   anyway (like a payment that happens in parallel) and can even
   avoid additional block space consumption if something like P2C
   or tapret commitment is used (though this will require
   a pre-knowledge of public keys at the moment of contract
   creation). The contract script claims that only the first 
   party who had made such tx mined wins the game (if two txes are 
   mined in a block, they may be sorted by their txid or block 
   position). Because of AluVM, contracts can inspect on-chain
   bitcoin state and find the signal.

That’s it! The structure of the contract would be genesis and that
thing called “state extension” - and nothing more. “Normal” RGB
flow (known to those who read about RGB before introduction of 
state extensions) with state transitions and witness bitcoin 
transactions would start only when Alice would like to spend that 
BTC* or to peg out - and at that point of time an RGB state 
transition will have to be created, and a corresponding bitcoin 
transaction (called “witness transaction”) spending that Alice’s 
UTXO, will have to be crafted, signed and mined. 

Final notes:
============

Communication medium
--------------------

All communications between Alice and Bob happens wherever they 
want - in IRC, mailing list, Nostr, telegram - or using 
decentralized networks like LN (with [Storm] on top, which we 
deliberately created for that purpose). It would be also possible
for Alice and Bob to use their RGB Nodes which will be 
communicating through RGB RPC protocol - there is a lot of ways,
and RGB is fully abstracted from them.

Going fully off-chain
---------------------

The above design can be put fully off-chain if the group of players 
may set up a n-of-n or n-of-m multiparty state channel (“channel 
factory”).

Question of BTC*
----------------

Regarding BTC* creation, for now we do have at least two designs we 
have developed over years: 

1) for Lightning channels, which has the same level of 
   trustlessness as the pure BTC in LN;

2) on-chain "lifting" which is semi-trusted (trustless private 
   decentralized peg-in and semi-trusted federated peg-out 
   requiring user+federation multisig but no privacy/history 
   exposure thanks to zk; such on-chain lifting is still much 
   better than other alternatives with drivechains or federated 
   sidechains).

Last, but not least
-------------------

> Is there any documentation or discussion archives that address the
> problem of non-publishable conditional statements seemingly being
> insecure in multiparty protocols, as previously described on this
> list [1] by Ruben Somsen? 

As far as I see, Ruben's letter was about different protocol, built
by Lightning Labs after they had studied (since they did plan to 
implement) RGB - but they ended up with taking results of many years
of our research and did a successful fundraising of ~80m on it, even 
"forgetting" to mention the original authors - until they were
ashamed by the community. Funny enough, even the original name of 
their "protocol" was [CMYK].

I have no desire on commenting how they solved (and did they solve) 
that - or any other - problem. I expect that they would again try 
to take the solution I have described above and do another 
fundraising with motto of transforming their product into “smart 
contracts on Lightning” :)

Kind regards,
Maxim Orlovsky
CEO (Chief engineering officer)
@ LNP/BP Standards Association,
https://lnp-bp.org
Twitter: @lnp_bp

-----

[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021559.html
[Storm]: https://github.com/Storm-WG
[CMYK]: [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html)