Re: [bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

Hi David,

> Ok, I think I understand you, but I'd like to try rephrasing what you
> wrote in a very brief format to see if you agree that it's correct and
> in the hopes that it might help other Bitcoin/LN developers understand.

In your description you mix together question of how BTC* can be issued
and how the contract settlement happens. However, they must be 
distinguished, otherwise the contract trust model can't be anyhow better
than a fixed centralized BTC* design you add to the equation as an 
assumption:

> What it doesn't provide is trustless contracting beyond the 
> capabilities of Bitcoin script.

However:
1. Contract x*2=4 settlement is fully trustless.
2. BTC* contract settlement may vary.

One may argue that there is no way of getting BTC* in a trustless way, 
but this is not true:

1. We may have a trustless BTC* in lightning channels (including
   multiparty channels with many participants).

2. It also depends on how you define the value of the original BTC.
   If BTC is a coin existing in bitcoin blockchain, than yes - you
   can't have a fully trustless BTC* for on-chain operations. But if
   you define BTC as a digital scarcity strictly inheriting existing
   UTXO  set from bitcoin blockchain, but which may exist elsewhere
   than bitcoin blockchain, you may have a 100% trustless BTC*.

What can be a case for (2)? As I told in my first letter, with RGB
we do not need the existing heavy-duty bitcoin blockchain at all.
We still need a layer 1 settlement for our single-use-seals, but it may
have a very different design comparing to existing bitcoin blockchain.

At LNP/BP Standards Association we are working on such design for the
last 3 years, and have quite a lot of progress in this direction. The
design we have for the layer 1 needed for client-side-validation 
(which Peter Todd calls "proof of publication medium") can be 
represented as a single signature + pubkey per block, scaling up to
theoretically unlimited number of transactions. There are still some
problems we have to solve, but overall the direction seems realistic.

So, if/once we have a new blockchain, RGB (or its successor) can 
operate on both bitcoin blockchain (let's call it timechain) and the 
new blockchain (we call the new blockchain "sigchain" or "sealchain", 
depending on the design model - we currently have 2 of them). Than, BTC
can be 100% trustlessly lifted from the timechain into RGB - and than
operate on top of the sigchain. In this model no pegout would be ever
needed, and the last point of trust gets removed.


> In short, I think this capability of RGB allows easily creating
> user-defined sidechains based on arbitrary scripts.

True, but RGB capabilities are even much larger than that. There is a 
plenty of smart contracts which do not need BTC/BTC* at all and can 
operate on RGB even today - but which were impossible on bitcoin 
blockchain or lightning before RGB (at least without heavily polluting 
block space):

1. Bearer securities - corporate shares, bonds, options, futures etc. 
   They will be 100% confidential and censorship-resistant + scalable
   b/c of Lightning network. Yes, you still trust the issuer (like with
   corporate shares), but the the secondary market is much improved.
2. Bearer ownership rights ("NFTs done in the right way"), again
   private, scalable, not polluting blockchain. For instance, I would
   like to have all books & songs as a bought to be present in this
   format. This also opens options for creators to earn commissions not
   just from an initial sale, but also from secondary market.
3. Digital collateral-based stable coins (in terms of their purchasing
   power and not necessary linked to any fiat).
4. Digital identity, where RGB and single-use-seals make key revocation
   a global event. Without this it is impossible to prove that a given
   key was or was not revoked at certain date.
5. Decentralized naming systems - like ENS, but much better because
   no ethereum is required :)
6. Provable historical event logs: opentimestamps doesn't allow
   proving that there is no alternative commitments. With RGB it is 
   possible to build event logs which has 100% trustless provable
   properties that no alternative history of the events does exist.
   For instance, if a doctor gives a prediction that a baby will be
   a boy and not a girl, it is impossible to witness the case with
   OpenTimeStamp (the doctor can make 2 OTSes for both outcomes),
   while with RGB it can be proven that no alternative commitment was
   created.
7. Liquidity pools, DEXes, AMM and other fancy stuff on Lightning,
   which we call "BiFi" (Bitcoin finance). One may listen to the talk
   on the last Bitcoin Amsterdam conference where I have presented
   that concept [1]. It requires more than just RGB - also some
   improvements to the Lightning network and protocols like Storm
   as a decentralized (tokenless!) data layer - but all of that is
   WIP at LNP/BP Standards Association with many 

Re: [bitcoin-dev] RGB protocol announcement

[David A. Harding via bitcoin-dev]

On 2023-04-18 13:16, Dr Maxim Orlovsky wrote:

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).


Hi Maxim,

Ok, I think I understand you, but I'd like to try rephrasing what you
wrote in a very brief format to see if you agree that it's correct and
in the hopes that it might help other Bitcoin/LN developers understand.

- Xavier and Yasmin create an RGB contract that says any BTC deposited
  into multi(2,x,y) can be used as BTC\*

- Bob acquires some of this BTC\*

- Bob offers his BTC\* to anyone who can provide x for (4 == 2 * x)

- Alice knows x = 2

- Alice asks Xavier and Yasmin to sign an onchain transaction
  withdrawing Bob's BTC\*. She provides them proof that Bob offered his
  BTC\* and that she knew the answer.  The both sign the the 
transaction.


In short, I think this capability of RGB allows easily creating
user-defined sidechains based on arbitrary scripts.  This is similar to
what Elements allowed last I looked at it, although RGB makes the
process of creating new sidechains much smoother, reduces global state,
and allows sidechain tokens (including tokens like lifted BTC) to be
used with LN without sidechain-specific programming.  That seems like a
significant advance to me.

What it doesn't provide is trustless contracting beyond the capabilities
of Bitcoin script.  To be fair, when I looked at your documentation
again just now, I don't see it promising enhanced **trustless**
contracting---I see it only promising enhanced contracting, which I (and
perhaps others) seem to have interpreted as also being trustless.

I hope I've understood you correctly.  Regardless, thank you for your
many detailed answers to my questions!

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

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. 

Re: [bitcoin-dev] RGB protocol announcement

[Dr Maxim Orlovsky via bitcoin-dev]

Hi David,

Thank you for taking time on doing analysis and writing comments.
I will address all small questions in this reply -- with a follow-up 
e-mail dedicated to the technical question from your letter
regarding the problem of "on-publishable conditional statements seemingly
being insecure in multiparty protocols", which requires longer write-up.


> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/

Thank you for spotting; we hadn't updated the readme. Now its fixed.


> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations?

The status of LNP implementation is "experimental": it is an instrument
for testing new protocols in the scope of the Lightning network, and
its main feature is in having lightweight and modular architecture.

LNP implementation is not anymore required for using RGB on LN - as 
Federico already mentioned in his reply, Bitfinex team was able to
independently integrate RGB with existing LDK codebase [1] (I even 
didn't know about that before they announced), and there is a WIP on
integrating RGB through CLN extensions. So the question of LNP node
readiness/completeness is unrelated to the question of RGB readiness,
features or technical properties; in my previous e-mail I just had 
pointed out that at some (past) point in time we had to work on LN 
re-implementation due to some restrictions we had back those days -- 
like with pay-to-contract commitments which were impossible to 
implement in the existing nodes due to architecture limitations -- 
but with the change to taproot-based commitments in late 2021-
early 2022 this is not true anymore.


> While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation. Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.

A lot of documentation was written and is being written. For instance,
if you look at the foundational crates we have in RGB, they are
well documented, containing more docs than the code itself, like in


Also, we have a number of websites tracking the RGB docs, listed in
 and  - literally
dozens of them. So your information is outdated.

Of course, much more need to be written - but again, for a small team
of community & self-fundend non-profit with the budget comparable to 
a coffee  shop. I think we are doing all what we can. If community 
needs more docs -- it is welcome to provide more funding or hands in 
writing them.


> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review. For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN.

It is there, literally for years, where it should be - in P2P protocol,
BOLT4, as directory and file names suggest:


It is based on our other library which provides encryption:



> In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several
> of your applications seem to almost entirely lack the string "test".
> For example, here are LNP-node and RGB-node compared to the four LN
> implementations I regularly monitor:
>
> /tmp/rgb-node$ git grep -i '\' | wc -l
> 7

RGB Node is not a part of the current RGB release -- starting from 
v0.10 RGB do not require a background service. The node is still useful
in server-side environments - but 100% of mobile and most of desktop
users and wallet devs would never need to touch it; thus the update
of the node to v0.10 will come later. Anyway, there is no reason of
doing its extensive test coverage since it its role to be a wrapper
around RGB libraries (existing in other repositories) which contain
100% of RGB consensus and applied business logic. Node just manages
threads and file I/O - not the stuff which is test-covered first of 
all (and even for that task it uses others of our libraries with a 
like io-react, used in other high-load projects. (BTW pls pay 
attention to how such libs are documented:
).

The real RGB code is here, as it is clearly stated in the Github:
* consensus-level 
  - 
  - 
  - 
* integration libraries - 

With the 

Re: [bitcoin-dev] RGB protocol announcement

[Federico Tenga via bitcoin-dev]

To add some context to the conversation, I would like to point out that
another RGB lightning implementation exists based on LDK, you may want to
check it out to have a better picture of how RGB works on LN:
https://github.com/RGB-Tools/rgb-lightning-sample

On Sun, 16 Apr 2023 at 07:35, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Dr Orlovsky,
>
> Thank you for writing about your interesting project.  Some replies
> inline below:
>
> On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
> > RGB v0.10 can be downloaded and installed as described on
> > 
> > website, which also contains a number of user and developer guidelines.
> > RGB source code can be found on 
>
> FYI: the RGB-WG organization page links to a repository whose latest
> release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
> https://github.com/RGB-WG/rgb-node/
>
> > My goal with RGB was not just to enable assets on Lightning, but that
> > of a much larger scope: to build a programmability layer for Bitcoin
> > and Lightning, which may unlock other cases than just tokens - DAOs,
> > decentralized identities and other things that bitcoin itself was
> > lacking.
>
> 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?  To give my own example of the problem:
>
> - Bob doesn't believe that there's a number which can be multiplied by 2
>to produce 4.  He's willing to pay a bounty for proof that he's wrong
>but Bitcoin does not currently provide a multiplication opcode, so he
>can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
>
> - Bob hears that RGB has turing-complete scripting, so he buys some
>random tokens that have an RGB contract which allows him to encumber
>them by any AlumVM script.  He then creates a Bitcoin transaction
>signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
>solution to (x * 2 == 4) to spend his RGB-based tokens.  He publishes
>a PSBT for the transaction along with the RGB data needed to claim the
>tokens.
>
> - Anyone on the network can now claim the BTC without knowing the
>solution, destroying the RGB-based tokens.
>
> - If, instead, Bob hears that Mallory knows the solution, he could sign
> a
>PSBT with the default SH_ALL to her, but then Mallory could take the
>BTC without solving the problem, again destroying the RGB-based
>tokens.
>
> - Or, in another case, Bob hears that Alice knows the solution, but he
>doesn't want to risk his tokens being destroyed, so he refuses to sign
>a transaction paying Alice until she provides him the answer.  When
>Alice does provide him the answer, and he realizes it's so simple, he
>changes his mind about paying her and doesn't sign his transaction to
>her.  She has no recourse.
>
> It seems to me, based on my understanding of Somsen's original insight,
> that client-side validation by itself cannot enforce conditions in a
> trustless multiparty setting.
>
> I think that implies that it's only possible to enforce conditions in a
> consensus system (or in a trust-dependent system), which would have
> significant implications for the future direction of your work, as you
> wrote in your email:
>
> > We're also working on the design of a layer 1 which will be perfect for
> > the
> > client-side-validated applications (“how to design a blockchain today
> > if we
> > knew about client-side-validation/single-use-seals”). This should be
> > very
> > compact (order of one signature per block) ultra-scalable
> > (theoretically
> > unlimited no of tx in a block) chain which can run systems like RGB -
> > with
> > Bitcoin UTXO set migrated into RGB [...]
>
> * * *
>
> Looking at other parts of your email:
>
> > Nevertheless, in 2021 we were able to present both RGB powered with a
> > Turing-complete virtual machine (AluVM) [2] and RGB had became
> > operational on
> > Lightning Network [3] using the LNP Node - a complete rust
> > re-implementation of
> > the Lightning protocol made by me at the Association [4].
>
> Could you clarify the status of these implementations?  While trying to
> learn about RGB, I noticed that you don't have much completed
> documentation.  Previous reviewers also mentioned this and I saw that
> you suggested them to read the code or view your videos.
>
> When reading your code for your LN implementation (LNP), I noticed it
> seemed to be missing a lot of things present in other LN implementations
> I regularly review.  For example, I can't find where it supports
> creating or parsing onions, which seems to be a fundamental requirement
> for using LN.  In trying to figure out how it works, I also noticed that
> I couldn't find either unit tests or integration tests---indeed several

Re: [bitcoin-dev] RGB protocol announcement

[David A. Harding via bitcoin-dev]

Hi Dr Orlovsky,

Thank you for writing about your interesting project.  Some replies
inline below:

On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
RGB v0.10 can be downloaded and installed as described on 


website, which also contains a number of user and developer guidelines.
RGB source code can be found on 


FYI: the RGB-WG organization page links to a repository whose latest
release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
https://github.com/RGB-WG/rgb-node/


My goal with RGB was not just to enable assets on Lightning, but that
of a much larger scope: to build a programmability layer for Bitcoin
and Lightning, which may unlock other cases than just tokens - DAOs,
decentralized identities and other things that bitcoin itself was 
lacking.


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?  To give my own example of the problem:

- Bob doesn't believe that there's a number which can be multiplied by 2
  to produce 4.  He's willing to pay a bounty for proof that he's wrong
  but Bitcoin does not currently provide a multiplication opcode, so he
  can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"

- Bob hears that RGB has turing-complete scripting, so he buys some
  random tokens that have an RGB contract which allows him to encumber
  them by any AlumVM script.  He then creates a Bitcoin transaction
  signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
  solution to (x * 2 == 4) to spend his RGB-based tokens.  He publishes
  a PSBT for the transaction along with the RGB data needed to claim the
  tokens.

- Anyone on the network can now claim the BTC without knowing the
  solution, destroying the RGB-based tokens.

- If, instead, Bob hears that Mallory knows the solution, he could sign 
a

  PSBT with the default SH_ALL to her, but then Mallory could take the
  BTC without solving the problem, again destroying the RGB-based
  tokens.

- Or, in another case, Bob hears that Alice knows the solution, but he
  doesn't want to risk his tokens being destroyed, so he refuses to sign
  a transaction paying Alice until she provides him the answer.  When
  Alice does provide him the answer, and he realizes it's so simple, he
  changes his mind about paying her and doesn't sign his transaction to
  her.  She has no recourse.

It seems to me, based on my understanding of Somsen's original insight,
that client-side validation by itself cannot enforce conditions in a
trustless multiparty setting.

I think that implies that it's only possible to enforce conditions in a
consensus system (or in a trust-dependent system), which would have
significant implications for the future direction of your work, as you
wrote in your email:

We're also working on the design of a layer 1 which will be perfect for 
the
client-side-validated applications (“how to design a blockchain today 
if we
knew about client-side-validation/single-use-seals”). This should be 
very
compact (order of one signature per block) ultra-scalable 
(theoretically
unlimited no of tx in a block) chain which can run systems like RGB - 
with

Bitcoin UTXO set migrated into RGB [...]


* * *

Looking at other parts of your email:


Nevertheless, in 2021 we were able to present both RGB powered with a
Turing-complete virtual machine (AluVM) [2] and RGB had became 
operational on
Lightning Network [3] using the LNP Node - a complete rust 
re-implementation of

the Lightning protocol made by me at the Association [4].


Could you clarify the status of these implementations?  While trying to
learn about RGB, I noticed that you don't have much completed
documentation.  Previous reviewers also mentioned this and I saw that
you suggested them to read the code or view your videos.

When reading your code for your LN implementation (LNP), I noticed it
seemed to be missing a lot of things present in other LN implementations
I regularly review.  For example, I can't find where it supports
creating or parsing onions, which seems to be a fundamental requirement
for using LN.  In trying to figure out how it works, I also noticed that
I couldn't find either unit tests or integration tests---indeed several
of your applications seem to almost entirely lack the string "test".
For example, here are LNP-node and RGB-node compared to the four LN
implementations I regularly monitor:

/tmp/rgb-node$ git grep -i '\' | wc -l
7
/tmp/lnp-node$ git grep -i '\' | wc -l
4

~/repos/rust-lightning$ git grep -i '\' | wc -l
2008
~/repos/cln$ git grep -i '\' | wc -l
1459
~/repos/lnd$ git grep -i '\' | wc -l
3547
~/repos/eclair$ git grep -i '\' | wc -l
2576

I realize those are all projects by larger teams than that which works
on RGB, but a difference of three orders of magnitude is very surprising
to me.  Do