From: Dr Maxim Orlovsky <orlovsky@lnp-bp•org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RGB protocol announcement
Date: Tue, 18 Apr 2023 23:16:05 +0000 [thread overview]
Message-ID: <o80w3onSFX0O35gdZWrApKpor9gfV57gvgogoZGZDuC6KRc_DOsU0QRuEuOBkrRLYpFgOPxFUVnIjjSN6KDSgHXztIGXFREHvN5EPZ9e1oQ=@lnp-bp.org> (raw)
In-Reply-To: <3089493b2f202e30af42a485efec3fd1@dtrt.org>
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)
next prev parent reply other threads:[~2023-04-18 23:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 22:09 Dr Maxim Orlovsky
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky [this message]
2023-04-19 19:37 ` David A. Harding
2023-04-19 22:17 ` Dr Maxim Orlovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='o80w3onSFX0O35gdZWrApKpor9gfV57gvgogoZGZDuC6KRc_DOsU0QRuEuOBkrRLYpFgOPxFUVnIjjSN6KDSgHXztIGXFREHvN5EPZ9e1oQ=@lnp-bp.org' \
--to=orlovsky@lnp-bp$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox