Dr Maxim Orlovsky [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-19 🗒️ Summary of this message: RGB allows for ...
📅 Original date posted:2023-04-19
🗒️ Summary of this message: RGB allows for trustless contracting beyond Bitcoin script, including user-defined sidechains and smart contracts that don't need BTC. A new blockchain, sigchain, could remove the need for pegouts.
📝 Original message: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 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,
privacy-preserving way and with bitcoin, not requiring new/other
tokens. Arguably, this is the largest thing that happened to bitcoin
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,
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
(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=DtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/
🗒️ Summary of this message: RGB allows for trustless contracting beyond Bitcoin script, including user-defined sidechains and smart contracts that don't need BTC. A new blockchain, sigchain, could remove the need for pegouts.
📝 Original message: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 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,
privacy-preserving way and with bitcoin, not requiring new/other
tokens. Arguably, this is the largest thing that happened to bitcoin
since bitcoin, with a potential to make Lightning network obsolete
(sigchain potentially exceeds in scalability the existing LN,
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
(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=DtkTE6m0zio
[2]: https://rgb.tech/thanks/sponsors/