From: "David A. Harding" <dave@dtrt•org>
To: Dr Maxim Orlovsky <orlovsky@lnp-bp•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RGB protocol announcement
Date: Wed, 19 Apr 2023 09:37:53 -1000 [thread overview]
Message-ID: <d34c6e5c4a776acfb455e549440a7c10@dtrt.org> (raw)
In-Reply-To: <o80w3onSFX0O35gdZWrApKpor9gfV57gvgogoZGZDuC6KRc_DOsU0QRuEuOBkrRLYpFgOPxFUVnIjjSN6KDSgHXztIGXFREHvN5EPZ9e1oQ=@lnp-bp.org>
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
next prev parent reply other threads:[~2023-04-19 19:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 22:09 Dr Maxim Orlovsky
2023-04-16 5:34 ` David A. Harding
2023-04-16 7:15 ` Federico Tenga
2023-04-18 0:47 ` Dr Maxim Orlovsky
2023-04-18 23:16 ` Dr Maxim Orlovsky
2023-04-19 19:37 ` David A. Harding [this message]
2023-04-19 22:17 ` Dr Maxim Orlovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d34c6e5c4a776acfb455e549440a7c10@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=orlovsky@lnp-bp$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox