path: root/c3/b69d7b45c74a771fd899c50ca81dfd24e25465

Return-Path: <orlovsky@lnp-bp.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1FAF0C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 23:16:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E81A940217
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 23:16:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E81A940217
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=lnp-bp.org header.i=@lnp-bp.org header.a=rsa-sha256
 header.s=protonmail2 header.b=RlLxrX8Q
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id s__RTCIlggXB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 23:16:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1558E4013C
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 1558E4013C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 23:16:14 +0000 (UTC)
Date: Tue, 18 Apr 2023 23:16:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lnp-bp.org;
 s=protonmail2; t=1681859772; x=1682118972;
 bh=uCOvjfjKoVxHA6hDLVRKhYvo2krpuadIDDL0aTPgTKA=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=RlLxrX8QipI9psP5OlBWXHaQLTD5O5cqGis/qMowAjDjagMN4ynyk7yzlZbaYR5HQ
 NULfD7vSGfdpvaGZh9k9A0m5BXye/YTwdvmZ22dfUAw5DA5wySPqIWjiS4lHnKuIqo
 TAAF2n0PoUM2eOZ0KZyNzUli9G9mEX4QaFfssSivBAdNcpqfCMRO1LBAOFAilBnU9I
 tyvJJpVJTs1XmdA+PYgLAg5T29kJUXR80vFPU/qJHVY5YmGxdKvsbDm19pvq96SDZ4
 FE0y4Odx0cTICdDWJvNA39f4EojRIiY1KwdapgxTHvpbdRxffIKNn7GiLOixlhsNo8
 eJRNDKLsczpkA==
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
X-Mailman-Approved-At: Tue, 18 Apr 2023 23:32:20 +0000
Subject: Re: [bitcoin-dev] RGB protocol announcement
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2023 23:16:19 -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 <=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)