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. “Normal” RGB flow (known to those who read about RGB before introduction of state extensions) with state transitions and witness bitcoin transactions would start only when Alice would like to spend that BTC* or to peg out - and at that point of time an RGB state transition will have to be created, and a corresponding bitcoin transaction (called “witness transaction”) spending that Alice’s UTXO, will have to be crafted, signed and mined. Final notes: ============ Communication medium -------------------- All communications between Alice and Bob happens wherever they want - in IRC, mailing list, Nostr, telegram - or using decentralized networks like LN (with [Storm] on top, which we deliberately created for that purpose). It would be also possible for Alice and Bob to use their RGB Nodes which will be communicating through RGB RPC protocol - there is a lot of ways, and RGB is fully abstracted from them. Going fully off-chain --------------------- The above design can be put fully off-chain if the group of players may set up a n-of-n or n-of-m multiparty state channel (“channel factory”). Question of BTC* ---------------- Regarding BTC* creation, for now we do have at least two designs we have developed over years: 1) for Lightning channels, which has the same level of trustlessness as the pure BTC in LN; 2) on-chain "lifting" which is semi-trusted (trustless private decentralized peg-in and semi-trusted federated peg-out requiring user+federation multisig but no privacy/history exposure thanks to zk; such on-chain lifting is still much better than other alternatives with drivechains or federated sidechains). Last, but not least ------------------- > 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? As far as I see, Ruben's letter was about different protocol, built by Lightning Labs after they had studied (since they did plan to implement) RGB - but they ended up with taking results of many years of our research and did a successful fundraising of ~80m on it, even "forgetting" to mention the original authors - until they were ashamed by the community. Funny enough, even the original name of their "protocol" was [CMYK]. I have no desire on commenting how they solved (and did they solve) that - or any other - problem. I expect that they would again try to take the solution I have described above and do another fundraising with motto of transforming their product into “smart contracts on Lightning” :) Kind regards, Maxim Orlovsky CEO (Chief engineering officer) @ LNP/BP Standards Association, https://lnp-bp.org Twitter: @lnp_bp ----- [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021559.html [Storm]: https://github.com/Storm-WG [CMYK]: [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020208.html) _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev