On 2023-04-18 13:16, Dr Maxim Orlovsky wrote:
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).
Hi Maxim,
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.
- Xavier and Yasmin create an RGB contract that says any BTC deposited
into multi(2,x,y) can be used as BTC\*
- Bob acquires some of this BTC\*
- Bob offers his BTC\* to anyone who can provide x for (4 == 2 * x)
- Alice knows x = 2
- Alice asks Xavier and Yasmin to sign an onchain transaction
withdrawing Bob's BTC\*. She provides them proof that Bob offered his
BTC\* and that she knew the answer. The both sign the the
transaction.
In short, I think this capability of RGB allows easily creating
user-defined sidechains based on arbitrary scripts. This is similar to
what Elements allowed last I looked at it, although RGB makes the
process of creating new sidechains much smoother, reduces global state,
and allows sidechain tokens (including tokens like lifted BTC) to be
used with LN without sidechain-specific programming. That seems like a
significant advance to me.
What it doesn't provide is trustless contracting beyond the capabilities
of Bitcoin script. To be fair, when I looked at your documentation
again just now, I don't see it promising enhanced **trustless**
contracting---I see it only promising enhanced contracting, which I (and
perhaps others) seem to have interpreted as also being trustless.
I hope I've understood you correctly. Regardless, thank you for your
many detailed answers to my questions!
-Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
