bip-taro: modify asset ID generation, require unique commitments #21

Roasbeef · 2022-04-14T01:51:51Z

This commit contains a few important changes:

The asset ID now includes the output index, which ensures they're
unique and also allows for created assets to live in distinct outputs.
A concrete requirement (handwavy statement was there before) that only
a single taro commitment exists in a script tree at any given time. To
achieve this, we take advantage of the BIP 340 tagged hash contract,
to ensure that the commitment is either the only element, or is the
leftmost/rightmost element.
Building off the above, we then detail a deterministic way to burn
assets, as well as prove to others that assets have been burnt. The
asset burning will play a role in the upcoming re-genesis protocol
feature.

One additional change during transfers is for parties to reveal the
sibling hash of the taro root commitment so uniqueness verification can
be done on that level. In addition, a similar reveal occurs for the
other outputs (if they exist) that don't explicitly commit (as far as
one party is aware) to any other assets.

Roasbeef · 2022-04-14T01:52:44Z

cc @dstadulis @jharveyb

Roasbeef · 2022-04-14T01:53:55Z

I still need to propagate this change to what needs to be revealed during swap transactions, which will also propagate to the PSBT BIP.

I also reference creating a BIP specifically for a deterministic algorithm for consisting a compliant commitment and tapscript tree based on either the set of leaf elements (the normal scripts) or the existing root hash (created via some other algo).

bip-taro.mediawiki

Roasbeef · 2022-04-16T02:14:37Z

Pushed up a new commit that tightens up the specification and adds the usual psuedo-code language in my made up language (beefcaml).

bip-taro.mediawiki

wpaulino · 2022-04-19T18:27:33Z

bip-taro.mediawiki

+The following algorithm can be used to verify that an output elsewhere in the
+transaction doesn't commit to a duplicate Taro commitment:
+<source lang="python">
+verify_no_taro_up_my_sleaves(genesis_tx: Tx, taro_root: []byte) -> bool


Nit: s/sleaves/sleeves

bip-taro.mediawiki

Roasbeef · 2022-04-19T23:56:22Z

Thanks for the review @wpaulino! Pushed up a fixup commit addressing the comments.

Roasbeef · 2022-04-20T00:28:42Z

Pushed up the final beefcaml code for asset burning+verification. Will also rebase now so the fixup commits are folded in.

bip-taro.mediawiki

jharveyb · 2022-04-21T18:29:21Z

bip-taro.mediawiki

+The following algorithm can be used to verify that an output elsewhere in the
+transaction doesn't commit to a duplicate Taro commitment:
+<source lang="python">
+verify_no_taro_up_my_sleaves(genesis_tx: Tx, taro_root: []byte) -> bool


Nit: s/sleaves/sleeves

jharveyb · 2022-04-21T18:36:08Z

bip-taro.mediawiki

+In addition to verifying that a commitment is unique within the constraints of
+a single taproot tree, we also need to verify that there is no similar
+commitment across the remaining outputs in the genesis transaction. We can do
+this by asserting that:


IIUC this requires having the preimages for every (single tapscript element or top-level tapscript branch) to cover each output in the TX. This seems worth mentioning explicitly.

This also seems like it would interfere with TXs built interactively with multiple parties (for each output added to a PSBT, we would also need to propagate tapscript preimages). Not sure if we can avoid that though.

IIUC this requires having the preimages for every (single tapscript element or top-level tapscript branch) to cover each output in the TX

Correct. In the typical case, I expect genesis transactions to just be 1-in-1 transactions, as there's no need to make a change output. If there is a change output, then we only require that opening.

Added a sentence below this mentioning that. This is intended to be covered in the code fragment below where we examine the commitment opening.

jharveyb · 2022-04-21T18:39:07Z

bip-taro.mediawiki

+** If top level key was derived using BIP 86, then verify the key derivation.
+** If the key commits to a script path:
+*** If only a single element is in the tree, verify that isn't a duplicate commitment.
+*** If the tree contains more than one element, then verify that the pre-image of the two branches isn't a taro commitment.


Are we checking only for duplicate commitments, or any other commitments? Here (and in the pseudocode) we allow non-duplicate commitments if they are the only tapscript element, but disallow them at depth 1.

So it's sort of implied by the commitment_expected call that we're mainly ensuring that none of the "expected" outputs have a commitment here. As far as allowing non-duplicate commitments (other valid taro commitments), that's accepted here as long as it isn't committing to that specific taro root.

I think I don't fully understand your questions however?

Or actually, I think you're getting at the fact that assuming commitment_expected knows which outputs to expect a valid commitment, of we also need to check for the marker byte prefix here of this leaf hash?

I was confused about if we are allowing multiple taro commitments in the same TX in general. Regardless of if we are or aren't, the rules / checks should be the same at depth 0 and depth 1.

Here the checks are written as:
-At depth 0:
--verify that isn't a duplicate commitment
-At depth 1:
--verify that the pre-image of the two branches isn't a taro commitment

If we want to allow multiple valid taro commitments, then we should relax the checks at depth 1 / in the MultiLeaf case to only assert that both branch preimages are not duplicate taro commitments.

I was confused about if we are allowing multiple taro commitments in the same TX in general

A single output should only have a single commitment. Other outputs may have commitments as well depending on the on chain event (like a transfer for example will produce a transaction with multiple commitments).

For asset creation, the asset ID includes the output index, so this check here is just wanting to ensure that the verifier is aware of any relevant assets being issued in the transaction.

For transfers, this is needed to ensure that they aren't committing to a history where the transfer didn't happen.

Cleared this up offline, will be more explicit here w.r.t what we're trying to verify and also the intent of commitment_expected.

jharveyb · 2022-04-21T18:47:25Z

bip-taro.mediawiki

+** For each output, the first depth of the control block leaf reveal must be presented:
+*** If the output key was created via BIP 86, then simply verify the mapping based on the internal key. In this case there is no script tree being committed to.
+*** If the proof is of depth 0, meaning only a single value is committed to, then assert the item isn't a valid Taro asset root.
+*** If the proof is of depth 1, then assert that either both elements are tap branches, or one of the items is a leaf that isn't a valid Taro asset root.


Here we disallow ANY other Taro asset roots in the TX vs. above; IIUC this implies that an asset burn must be the only Taro-related activity in a given TX? (Cannot issue new assets owned by another output, or perform a transfer to another output, etc.).

IIUC this implies that an asset burn must be the only Taro-related activity in a given TX? (Cannot issue new assets owned by another output, or perform a transfer to another output, etc.).

Great question! The burn operation is allowed when batched with any other taro events (transfer, etc). The specific event here is defined by removal of a commitment from the sub-asset tree and therefore the main taro commitment. The burn verification routine has access to both the non-inclusion proof (verify it's no longer committed to in the simple case of a collectible), and also the new taro root (to verify that this is placed in a unique location).

These two additional rules are more or less summed up in the taro_commitment_is_valid routine, but I wanted to spell them out here as well.

I made another updated to make this more explicit in that right now it sort of only allows a total burn (no assets committed to at all), vs a selective burn (some assets not committed to, or the committed amounts should be reduced):

For each output, that doesn't commit to the asset tree the non-inclusion proof is rooted at

a selective burn (some assets not committed to, or the committed amounts should be reduced)

Is it correct to equate:
"some assets not committed to" = burning an entire class of an asset (my collectible, or all my beefbux)
"he committed amounts should be reduced" = Of my 100 beefbux, I burn 20 for a net result of 80 beefbux

Is it correct to equate:

Correct.

dstadulis

Looking good, a few questions about some of the pseudo-code, a nit.

bip-taro.mediawiki

dstadulis · 2022-04-22T18:31:46Z

bip-taro.mediawiki

+               # The pre-image is a leaf, so verify the hashes match up.
+               case LeafReveal(leaf_bytes):


Suggested change

# The pre-image is a leaf, so verify the hashes match up.

case LeafReveal(leaf_bytes):

# The pre-image is a non-taro leaf, so verify the hashes match up.

case LeafReveal(leaf_bytes):

Is this code verifying that the hashes match up (equates to something) or that their characteristics conform to what aught to be (no conflicts)

IIUC, both: we verify that the pre-image is indeed a tapleaf (as bound by the tagged hash output) and we can re-derive that to arrive at the same sibling hash contained in the normal control block proof.

bip-taro.mediawiki

dstadulis · 2022-04-22T18:56:58Z

bip-taro.mediawiki

+** For each output, the first depth of the control block leaf reveal must be presented:
+*** If the output key was created via BIP 86, then simply verify the mapping based on the internal key. In this case there is no script tree being committed to.
+*** If the proof is of depth 0, meaning only a single value is committed to, then assert the item isn't a valid Taro asset root.
+*** If the proof is of depth 1, then assert that either both elements are tap branches, or one of the items is a leaf that isn't a valid Taro asset root.


a selective burn (some assets not committed to, or the committed amounts should be reduced)

Is it correct to equate:
"some assets not committed to" = burning an entire class of an asset (my collectible, or all my beefbux)
"he committed amounts should be reduced" = Of my 100 beefbux, I burn 20 for a net result of 80 beefbux

bip-taro.mediawiki

This commit contains a few important changes: * The asset ID now includes the output index, which ensures they're unique and also allows for created assets to live in distinct outputs. * A concrete requirement (handwavy statement was there before) that only a single taro commitment exists in a script tree at any given time. To achieve this, we take advantage of the BIP 340 tagged hash contract, to ensure that the commitment is either the only element, or is the leftmost/rightmost element. * Building off the above, we then detail a deterministic way to burn assets, as well as prove to others that assets have been burnt. The asset burning will play a role in the upcoming re-genesis protocol feature. One additional change during transfers is for parties to reveal the sibling hash of the taro root commitment so uniqueness verification can be done on that level. In addition, a similar reveal occurs for the other outputs (if they exist) that don't explicitly commit (as far as one party is aware) to any other assets.

Roasbeef · 2022-04-29T23:12:51Z

Pushed a new commit with the following updates:

During asset creation, we indeed only care that no other duplicate commitments for that asset exist.
For asset burning, we validate the normal non-inclusion proof, but for each other output that can commit to a to commitment, we verify that either it doesn't has a taro commitment or it has one and the asset is no longer committed to.

Here's the comparison: https://github.com/Roasbeef/bips/compare/ec30a546bcd0187141aca8988d7595337418a7e7..70fb13a4a76d9f20d0c3c8dac55cfb10df850e3b

Roasbeef · 2022-04-29T23:13:16Z

Working on a similar PR to tighten up the bip-taro-vm doc with more precise algorithms.

Roasbeef mentioned this pull request Apr 14, 2022

assets: enforce uniqnuess or strong binding with asset leaf position lightninglabs/taproot-assets#4

Closed

wpaulino reviewed Apr 14, 2022

View reviewed changes

wpaulino mentioned this pull request Apr 18, 2022

asset: Introduce Asset struct with leaf TLV encoding lightninglabs/taproot-assets#14

Merged

wpaulino reviewed Apr 19, 2022

View reviewed changes

Roasbeef mentioned this pull request Apr 19, 2022

bip-taro: implement provable burning and verification lightninglabs/taproot-assets#24

Closed

4 tasks

wpaulino approved these changes Apr 20, 2022

View reviewed changes

Roasbeef force-pushed the bip-taro-uniqueness branch from 1eb82f1 to c86cbdc Compare April 21, 2022 00:56

jharveyb reviewed Apr 21, 2022

View reviewed changes

Roasbeef force-pushed the bip-taro-uniqueness branch 2 times, most recently from ff93833 to 7ae1e0b Compare April 22, 2022 01:06

dstadulis suggested changes Apr 22, 2022

View reviewed changes

dstadulis reviewed Apr 22, 2022

View reviewed changes

bip-taro.mediawiki Outdated Show resolved Hide resolved

bip-taro.mediawiki Outdated Show resolved Hide resolved

bip-taro.mediawiki Outdated Show resolved Hide resolved

Roasbeef force-pushed the bip-taro-uniqueness branch from 7ae1e0b to ec30a54 Compare April 22, 2022 23:06

Roasbeef force-pushed the bip-taro-uniqueness branch from ec30a54 to 70fb13a Compare April 29, 2022 23:12

Roasbeef merged commit 70bbfc5 into bip-taro Apr 29, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bip-taro: modify asset ID generation, require unique commitments #21

bip-taro: modify asset ID generation, require unique commitments #21

Roasbeef commented Apr 14, 2022

Roasbeef commented Apr 14, 2022

Roasbeef commented Apr 14, 2022

Roasbeef commented Apr 16, 2022

wpaulino Apr 19, 2022

jharveyb Apr 21, 2022

Roasbeef commented Apr 19, 2022

Roasbeef commented Apr 20, 2022

jharveyb Apr 21, 2022

jharveyb Apr 21, 2022

Roasbeef Apr 22, 2022

jharveyb Apr 21, 2022

Roasbeef Apr 22, 2022

Roasbeef Apr 22, 2022

jharveyb Apr 22, 2022

Roasbeef Apr 22, 2022

Roasbeef Apr 22, 2022

Roasbeef Apr 23, 2022

jharveyb Apr 21, 2022

Roasbeef Apr 22, 2022

Roasbeef Apr 22, 2022 •

edited

Loading

dstadulis Apr 22, 2022

Roasbeef Apr 22, 2022

dstadulis left a comment

dstadulis Apr 22, 2022

Roasbeef Apr 22, 2022

dstadulis Apr 22, 2022

Roasbeef commented Apr 29, 2022 •

edited

Loading

Roasbeef commented Apr 29, 2022

		# The pre-image is a leaf, so verify the hashes match up.
		case LeafReveal(leaf_bytes):

bip-taro: modify asset ID generation, require unique commitments #21

bip-taro: modify asset ID generation, require unique commitments #21

Conversation

Roasbeef commented Apr 14, 2022

Roasbeef commented Apr 14, 2022

Roasbeef commented Apr 14, 2022

Roasbeef commented Apr 16, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef commented Apr 19, 2022

Roasbeef commented Apr 20, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef Apr 22, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dstadulis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef commented Apr 29, 2022 • edited Loading

Roasbeef commented Apr 29, 2022

Roasbeef Apr 22, 2022 •

edited

Loading

Roasbeef commented Apr 29, 2022 •

edited

Loading