Date: Tue, 18 Apr 2023 23:16:05 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Dr Maxim Orlovsky <orlovsky@lnp-bp.org>
Message-ID: <o80w3onSFX0O35gdZWrApKpor9gfV57gvgogoZGZDuC6KRc_DOsU0QRuEuOBkrRLYpFgOPxFUVnIjjSN6KDSgHXztIGXFREHvN5EPZ9e1oQ=@lnp-bp.org>
In-Reply-To: <3089493b2f202e30af42a485efec3fd1@dtrt.org>
References: <JpC1PVaT1XunO5ZCcan4GkylS8cUadw8ueukJhEyfdFu2tzHa1CqcXT8vZDytu3ZEX9qPJ1pqG85NfqZ0cwGerHLXh3ZrUTXksxoPxuYyxA=@lnp-bp.org>
 <3089493b2f202e30af42a485efec3fd1@dtrt.org>
Feedback-ID: 18134079:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] RGB protocol announcement
Precedence: list

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 <=E2=80=A6 description follows =
=E2=80=A6>

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=20
the way I see distributed systems, bitcoin and other =E2=80=9Cblockchains=
=E2=80=9D=20
and multi-party contracts, thus this may have caused inability to=20
speak in the same terms. For me, the setup you are describing=20
doesn=E2=80=99t make sense at all: there is no reason of doing things with
RGB that way. I.e, you are suggesting invalid setup - and then=20
prove that it is not working :).

I will try first to explain why I think the reasoning you are=20
putting into the argument is invalid in the assumptions: nobody=20
should expect that RGB somehow magically makes on-chain BTC (I will=20
use this acronym to distinguish BTC-as-money from bitcoin-as-
blockchain or tech) more programmable or anyhow better: it is=20
impossible without softfork or a hardfork on _blockchain consensus_=20
level. What is possible is to add functionality on top of that; but
anything additional won=E2=80=99t work for BTC unless it is =E2=80=9Clifted=
=E2=80=9D into=20
that new layer. This is true with sidechains, this is true with=20
Lightning, this is for sure true with RGB. So any setups we are=20
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=20
token, so I propose not to make setups more complex and start=20
discussing them without introducing a new tokens unless it is=20
really required.

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

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

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

   This part I will take from your letter without changes, however=20
   will skip the rest about production of some tokens etc, which=20
   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=20
contract (its **genesis**) featuring BTC* AND providing the=20
following conditions (in the contract **schema**, which is a part=20
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=20
   introduction of =E2=80=9Cglobal state=E2=80=9D)

2. BTC* can be reclaimed by any party providing a solution (in form
   of RGB **state extension**) which is verified by AluVM. Alice,=20
   if she have found the solution, now can **assign** that=20
   previously =E2=80=9Cfloating=E2=80=9D/unowned BTC* to an UTXO she contro=
ls.=20

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

3. To ensure uniqueness of the winner (i.e. prevent=20
   =E2=80=9Cdouble-spending=E2=80=9D of =E2=80=9Cfree-floating=E2=80=9D/uno=
wned BTC* from the=20
   contract global state) Alice is also required (by the contract=20
   conditions defined by Bob in the contract schema) to post some=20
   identifiable information into a mined bitcoin transaction
   on-chain (NB: this is not the same as a witness transaction; it=20
   can be any transaction not related to the contract UTXOs in any=20
   way). The transaction must contain a pre-defined signal in a=20
   form known only to the contract participants; for instance some=20
   pre-defined random value stored in OP_RETURN, address, value,=20
   witness, pay-to-contract tweak of some pre-defined pubkey - or=20
   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=20
   party who had made such tx mined wins the game (if two txes are=20
   mined in a block, they may be sorted by their txid or block=20
   position). Because of AluVM, contracts can inspect on-chain
   bitcoin state and find the signal.

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


Final notes:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

All communications between Alice and Bob happens wherever they=20
want - in IRC, mailing list, Nostr, telegram - or using=20
decentralized networks like LN (with=C2=A0[Storm]=C2=A0on top, which we=20
deliberately created for that purpose). It would be also possible
for Alice and Bob to use their RGB Nodes which will be=20
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=20
may set up a n-of-n or n-of-m multiparty state channel (=E2=80=9Cchannel=20
factory=E2=80=9D).

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

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

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

2) on-chain "lifting" which is semi-trusted (trustless private=20
   decentralized peg-in and semi-trusted federated peg-out=20
   requiring user+federation multisig but no privacy/history=20
   exposure thanks to zk; such on-chain lifting is still much=20
   better than other alternatives with drivechains or federated=20
   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?=20

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=20
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=20
"forgetting" to mention the original authors - until they were
ashamed by the community. Funny enough, even the original name of=20
their "protocol" was [CMYK].

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


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/021=
559.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)