Ruben Somsen [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-15 📝 Original message: Hi Laolu, > ignoring the ...

📅 Original date posted:2022-04-15
📝 Original message:
Hi Laolu,

> ignoring the rules leads to assets being burnt, but in most cases imo
that's a sufficient enough incentive to maintain and validate the relevant
set of witnesses

I agree it is sufficient, but only because using Bitcoin script without an
additional scripting language inside of Taro is already sufficient. Perhaps
you could show me a concrete example where you think replicating Bitcoin's
scripting capabilities inside Taro can be useful, so I can show you where I
think it fails.

> came up with a "issuance covenant" design sketch that may or may not be
useful

To summarize my view from my first post, I basically think there are two
broad exceptions to the "can't do scripting" rule:

1. Self-encumbrance: you have to use the token according to the rules, else
the token becomes burned/invalid. The example you're giving here can be
said to fall under this category. The usefulness of this is
extremely narrow, and merely replicating Bitcoin's script inside of Taro is
certainly not sufficient to achieve it.

2. On-chain validation: instead of keeping the satisfaction of the script
off-chain, you publish it on-chain in the Bitcoin blockchain. This works,
but breaks a fundamental design goal of Taro/RGB (remaining off-chain), and
adds significant complexity.

These two points lead me to my conclusion that off-chain validation
protocols (to rule out the exception in point 2) can't do any meaningful
(to rule out the exception in point 1) scripting.

This doesn't mean you can't still add some scripting to facilitate certain
use cases that fall under the two exceptions, but a regular scripting
language for on-chain payments such as Bitcoin's is not going to cut it (at
least not without significant changes).

Personally I'd be inclined to leave out the scripting language altogether
(as the encumbrance of Bitcoin UTXOs is sufficient in most cases), unless
you have a very specific and compelling use case in mind that justify the
complexity.

Cheers,
Ruben


On Mon, Apr 11, 2022 at 9:52 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:

> Hi Ruben,
>
> > Also, the people that are responsible for the current shape of RGB aren't
> > the people who originated the idea, so it would not be fair to the
> > originators either (Peter Todd, Alekos Filini, Giacomo Zucco).
>
> Sure I have no problems acknowledging them in the current BIP draft. Both
> the protocols build off of ideas re client-side-validation, but then end up
> exploring different parts of the large design space. Peter Todd is already
> there, but I can add the others you've listed. I might even just expand
> that
> section into a longer "Related Work" section along the way.
>
> > What I tried to say was that it does not make sense to build scripting
> > support into Taro, because you can't actually do anything interesting
> with
> > it due to this limitation. can do with their own Taro tokens, or else he
> > will burn them – not very useful
>
> I agree that the usage will be somewhat context specific, and dependent on
> the security properties one is after. In the current purposefully
> simplified
> version, it's correct that ignoring the rules leads to assets being burnt,
> but in most cases imo that's a sufficient enough incentive to maintain and
> validate the relevant set of witnesses.
>
> I was thinking about the scripting layer a bit over the weekend, and came
> up
> with a "issuance covenant" design sketch that may or may not be useful. At
> a
> high level, lets say we extend the system to allow a specified (so a new
> asset type) or generalized script to be validated when an asset issuance
> transaction is being validated. If we add some new domain specific covenant
> op codes at the Taro level, then we'd be able to validate issuance events
> like:
>
> * "Issuing N units of this assets can only be done if 1.5*N units of BTC
> are present in the nth output of the minting transaction. In addition,
> the output created must commit to a NUMs point for the internal key,
> meaning that only a script path is possible. The script paths must be
> revealed, with the only acceptable unlocking leaf being a time lock of
> 9
> months".
>
> I don't fully have a concrete protocol that would use something like that,
> but that was an attempt to express certain collateralization requirements
> for issuing certain assets. Verifiers would only recognize that asset if
> the
> issuance covenant script passes, and (perhaps) the absolute timelock on
> those coins hasn't expired yet. This seems like a useful primitive for
> creating assets that are somehow backed by on-chain BTC collateralization.
> However this is just a design sketch that needs to answer questions like:
>
> * are the assets still valid after that timeout period, or are they
> considered to be burnt?
>
> * assuming that the "asset key family" (used to authorize issuance of
> related assets) are jointly owned, and maintained in a canonical
> Universe, then would it be possible for 3rd parties to verify the level
> of collateralization on-chain, with the join parties maintaining the
> pool of collateralized assets accordingly?
>
> * continuing with the above, is it feasible to use a DLC script within
> one
> of these fixed tapscript leaves to allow more collateral to be
> added/removed from the pool backing those assets?
>
> I think it's too early to conclude that the scripting layer isn't useful.
> Over time I plan to add more concrete ideas like the above to the section
> tracking the types of applications that can be built on Taro.
>
> > So theoretically you could get Bitcoin covenants to enforce certain
> > spending conditions on Taro assets. Not sure how practical that ends up
> > being, but intriguing to consider.
>
> Exactly! Exactly how practical it ends up being would depend on the types
> of
> covenants deployed in the future. With something like a TLUV and OP_CAT (as
> they're sufficiently generalized vs adding op codes to very the proofs) a
> Script would be able to re-create the set of commitments to restrict the
> set
> of outputs that can be created after spending. One would use OP_CAT to
> handle re-creating the taro asset root, and TLUV (or something similar) to
> handle the Bitcoin tapscript part (swap out leaf index 0 where the taro
> commitment is, etc).
>
> > The above also reminds me of another potential issue which you need to be
> > aware of, if you're not already. Similar to my comment about how the
> > location of the Taro tree inside the taproot tree needs to be
> > deterministic for the verifier, the output in which you place the Taro
> > tree also needs to be
>
> Yep, the location needs to be fully specified which includes factoring the
> output index as well. A simple way to restrict this would just to say it's
> always the first output. Otherwise, you could lift the output index into
> the
> asset ID calculation.
>
> -- Laolu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/17d2aa29/attachment.html>;