Date: Wed, 19 Apr 2023 22:17:57 +0000
To: "David A. Harding" <dave@dtrt.org>
From: Dr Maxim Orlovsky <orlovsky@lnp-bp.org>
Message-ID: <laGWWZiHcM2wPyvD-EL62eW0mydFULvYnuhir99pRC_ZTB6ZIR6KObnlCWM7g35ExkMwFlmyj38UMWx37AFyfTOGDuKxhaSDXR3QEAk3xZ4=@lnp-bp.org>
In-Reply-To: <d34c6e5c4a776acfb455e549440a7c10@dtrt.org>
References: <JpC1PVaT1XunO5ZCcan4GkylS8cUadw8ueukJhEyfdFu2tzHa1CqcXT8vZDytu3ZEX9qPJ1pqG85NfqZ0cwGerHLXh3ZrUTXksxoPxuYyxA=@lnp-bp.org>
 <3089493b2f202e30af42a485efec3fd1@dtrt.org>
 <o80w3onSFX0O35gdZWrApKpor9gfV57gvgogoZGZDuC6KRc_DOsU0QRuEuOBkrRLYpFgOPxFUVnIjjSN6KDSgHXztIGXFREHvN5EPZ9e1oQ=@lnp-bp.org>
 <d34c6e5c4a776acfb455e549440a7c10@dtrt.org>
Feedback-ID: 18134079:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] RGB protocol announcement
Precedence: list

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=20
distinguished, otherwise the contract trust model can't be anyhow better
than a fixed centralized BTC* design you add to the equation as an=20
assumption:

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

However:
1. Contract x*2=3D4 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,=20
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=20
(which Peter Todd calls "proof of publication medium") can be=20
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=20
operate on both bitcoin blockchain (let's call it timechain) and the=20
new blockchain (we call the new blockchain "sigchain" or "sealchain",=20
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=20
plenty of smart contracts which do not need BTC/BTC* at all and can=20
operate on RGB even today - but which were impossible on bitcoin=20
blockchain or lightning before RGB (at least without heavily polluting=20
block space):

1. Bearer securities - corporate shares, bonds, options, futures etc.=20
   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=20
   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 parts already being
   released in a test versions (another reason why LNP Node is
   important - a topic we were discussing two e-mails ago).

Thus we say that RGB allows everything what can be done with existing
"blockchain smart contracts" - but in much more scalable,=20
privacy-preserving way and with bitcoin, not requiring new/other=20
tokens. Arguably, this is the largest thing that happened to bitcoin=20
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,=20
especially when gossip traffic and liquidity limitations are taken
into account).

The time will show where all these assumptions about the potential of
sigchain and #BiFi are correct. Meanwhile, we at LNP/BP Standards
Association continue our work on advancing bitcoin protocol and
lightning network protocols - without whining about any soft- or hard-
forks :). Of course, we, as a non-profit, need support - so all bitcoin
hodlers are welcome to join the very few organizations and individuals
already supporting our efforts [2], making all this future possible=20
(you can contact us via "ukolova [at] lnp-bp.org").

At the end, I'd like t, thank you for the detailed analysis and great
write-up on RGB in the latest Bitcoin Optech Newsletter. It explains
RGB in more simple words than I was was able to!


Kind regards,
Maxim Orlovsky
LNP/BP Standards Association
GitHub: https://github.com/LNP-BP
Twitter: @lnp_bp


[1]: https://www.youtube.com/watch?v=3DDtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/