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/ _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev