📅 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/
Dr Maxim Orlovsky [ARCHIVE] /
npub1a8…rpwgy
2023-06-07 23:20:30
in reply to nevent1q…75py
Author Public Key
npub1a80jcetgws9xmu7wnylvekpymw2acym2psjpp03e0chmhq38pc8qwrpwgyPublished at
2023-06-07 23:20:30Event JSON
{
"id": "70a1030ac38a20ec34afb13bba157fafa5815305ad7acf78711e23f595c43128",
"pubkey": "e9df2c6568740a6df3ce993eccd824db95dc136a0c2410be397e2fbb82270e0e",
"created_at": 1686180030,
"kind": 1,
"tags": [
[
"e",
"17c6b88eaabd27d18d00d5fd92c39900bd12338a2c8102c44983686a740531ea",
"",
"root"
],
[
"e",
"7a9b3422d6cfde3151c75c3bdd7d6c206fa8ca66ec71b88c3a6760473d167ee7",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2023-04-19\n🗒️ 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.\n📝 Original message:Hi David,\n\n\u003e Ok, I think I understand you, but I'd like to try rephrasing what you\n\u003e wrote in a very brief format to see if you agree that it's correct and\n\u003e in the hopes that it might help other Bitcoin/LN developers understand.\n\nIn your description you mix together question of how BTC* can be issued\nand how the contract settlement happens. However, they must be \ndistinguished, otherwise the contract trust model can't be anyhow better\nthan a fixed centralized BTC* design you add to the equation as an \nassumption:\n\n\u003e What it doesn't provide is trustless contracting beyond the \n\u003e capabilities of Bitcoin script.\n\nHowever:\n1. Contract x*2=4 settlement is fully trustless.\n2. BTC* contract settlement may vary.\n\nOne may argue that there is no way of getting BTC* in a trustless way, \nbut this is not true:\n\n1. We may have a trustless BTC* in lightning channels (including\n multiparty channels with many participants).\n\n2. It also depends on how you define the value of the original BTC.\n If BTC is a coin existing in bitcoin blockchain, than yes - you\n can't have a fully trustless BTC* for on-chain operations. But if\n you define BTC as a digital scarcity strictly inheriting existing\n UTXO set from bitcoin blockchain, but which may exist elsewhere\n than bitcoin blockchain, you may have a 100% trustless BTC*.\n\nWhat can be a case for (2)? As I told in my first letter, with RGB\nwe do not need the existing heavy-duty bitcoin blockchain at all.\nWe still need a layer 1 settlement for our single-use-seals, but it may\nhave a very different design comparing to existing bitcoin blockchain.\n\nAt LNP/BP Standards Association we are working on such design for the\nlast 3 years, and have quite a lot of progress in this direction. The\ndesign we have for the layer 1 needed for client-side-validation \n(which Peter Todd calls \"proof of publication medium\") can be \nrepresented as a single signature + pubkey per block, scaling up to\ntheoretically unlimited number of transactions. There are still some\nproblems we have to solve, but overall the direction seems realistic.\n\nSo, if/once we have a new blockchain, RGB (or its successor) can \noperate on both bitcoin blockchain (let's call it timechain) and the \nnew blockchain (we call the new blockchain \"sigchain\" or \"sealchain\", \ndepending on the design model - we currently have 2 of them). Than, BTC\ncan be 100% trustlessly lifted from the timechain into RGB - and than\noperate on top of the sigchain. In this model no pegout would be ever\nneeded, and the last point of trust gets removed.\n\n\n\u003e In short, I think this capability of RGB allows easily creating\n\u003e user-defined sidechains based on arbitrary scripts.\n\nTrue, but RGB capabilities are even much larger than that. There is a \nplenty of smart contracts which do not need BTC/BTC* at all and can \noperate on RGB even today - but which were impossible on bitcoin \nblockchain or lightning before RGB (at least without heavily polluting \nblock space):\n\n1. Bearer securities - corporate shares, bonds, options, futures etc. \n They will be 100% confidential and censorship-resistant + scalable\n b/c of Lightning network. Yes, you still trust the issuer (like with\n corporate shares), but the the secondary market is much improved.\n2. Bearer ownership rights (\"NFTs done in the right way\"), again\n private, scalable, not polluting blockchain. For instance, I would\n like to have all books \u0026 songs as a bought to be present in this\n format. This also opens options for creators to earn commissions not\n just from an initial sale, but also from secondary market.\n3. Digital collateral-based stable coins (in terms of their purchasing\n power and not necessary linked to any fiat).\n4. Digital identity, where RGB and single-use-seals make key revocation\n a global event. Without this it is impossible to prove that a given\n key was or was not revoked at certain date.\n5. Decentralized naming systems - like ENS, but much better because\n no ethereum is required :)\n6. Provable historical event logs: opentimestamps doesn't allow\n proving that there is no alternative commitments. With RGB it is \n possible to build event logs which has 100% trustless provable\n properties that no alternative history of the events does exist.\n For instance, if a doctor gives a prediction that a baby will be\n a boy and not a girl, it is impossible to witness the case with\n OpenTimeStamp (the doctor can make 2 OTSes for both outcomes),\n while with RGB it can be proven that no alternative commitment was\n created.\n7. Liquidity pools, DEXes, AMM and other fancy stuff on Lightning,\n which we call \"BiFi\" (Bitcoin finance). One may listen to the talk\n on the last Bitcoin Amsterdam conference where I have presented\n that concept [1]. It requires more than just RGB - also some\n improvements to the Lightning network and protocols like Storm\n as a decentralized (tokenless!) data layer - but all of that is\n WIP at LNP/BP Standards Association with many parts already being\n released in a test versions (another reason why LNP Node is\n important - a topic we were discussing two e-mails ago).\n\nThus we say that RGB allows everything what can be done with existing\n\"blockchain smart contracts\" - but in much more scalable, \nprivacy-preserving way and with bitcoin, not requiring new/other \ntokens. Arguably, this is the largest thing that happened to bitcoin \nsince bitcoin, with a potential to make Lightning network obsolete\n(sigchain potentially exceeds in scalability the existing LN, \nespecially when gossip traffic and liquidity limitations are taken\ninto account).\n\nThe time will show where all these assumptions about the potential of\nsigchain and #BiFi are correct. Meanwhile, we at LNP/BP Standards\nAssociation continue our work on advancing bitcoin protocol and\nlightning network protocols - without whining about any soft- or hard-\nforks :). Of course, we, as a non-profit, need support - so all bitcoin\nhodlers are welcome to join the very few organizations and individuals\nalready supporting our efforts [2], making all this future possible \n(you can contact us via \"ukolova [at] lnp-bp.org\").\n\nAt the end, I'd like t, thank you for the detailed analysis and great\nwrite-up on RGB in the latest Bitcoin Optech Newsletter. It explains\nRGB in more simple words than I was was able to!\n\n\nKind regards,\nMaxim Orlovsky\nLNP/BP Standards Association\nGitHub: https://github.com/LNP-BP\nTwitter: @lnp_bp\n\n\n[1]: https://www.youtube.com/watch?v=DtkTE6m0zio\n[2]: https://rgb.tech/thanks/sponsors/",
"sig": "63fc4f010694a9d50af125c8e5a5ca2575885f865eddcf4624f4eacdfb807a8ce4494d9ff5835125f672b9fdec7a7ad0e5d60f6e81f7d248a48f2688fe05bcb2"
}