bip-tap: BIPs for the Taproot Assets Protocol

Roasbeef commented at 6:41 pm on September 6, 2023: contributor

Overview

These BIPs describe the Taproot Asset Protocol, a Taproot-native asset overlay built on top of the base Bitcoin blockchain. Taproot Assets enable the representation of arbitrary (normal and collectibles) assets on top of Bitcoin without bloating the base chain. The protocol is designed such that transactions interacting with Taproot Assets are indistinguishable from regular transactions from the PoV of the Bitcoin blockchain. Taproot Assets extend the base Taproot script tree with a nested ‘‘asset script’’ tree (a merkle-sum sparse merkle tree, or MS-SMT) that commits to valid witnesses as structured metadata that allow for proofs of the movement of assets across the transaction graph. The provenance of transfers of a Taproot Asset can be verified using a hermetic proof transmitted as flat file, or using the aide of an externally maintained Universe, which is a MS-SMT that indexes on-chain asset issuance+transfers, which natively supports proof-of-reserves/supply system.

Taproot Assets support off-chain single and multi-hop transfers over Lightning channels (based on the BOLT protocol suite), with the latter manifested using Taproot Assets’ unique embedded asset script system. Light client verification of on-chain Taproot Asset transfers is facilitated by a series of on and off-chain merkle proofs, which can be compressed by delegating a trust relationship to an active Universe instance. A variant on off-chain multi-party channels are proposed to support off-chain transfer of normal assets. In addition, a special type of Universe, dubbed a Pocket Universe, which is based on an exit-only commit-chain design can be used to aggregate transfers on-chain in a trust-minimized manner.

BIP Documents

With this PR, we seek to request BIP numbers be assigned for the 7 included documents:

bip-tap-mssmt: describes the MS-SMT (Merkle-Sum Sparse Merkle Tree) data structure used to store assets and various proofs.
bip-tap: describes the Taproot Assets Protocol validation and state transition rules.
bip-tap-addr: describes the address format used to send and receive assets.
bip-tap-vm: describes the initial version of the off-chain TAP VM used to lock and unlock assets.
bip-tap-vpsbt: describes a vPSBT (virtual PSBT) which is a series custom types on top of the existing PSBT protocol to facilitate more elaborate asset related transactions.
bip-tap-proof-file: describes the flat file format which is used to prove and verify the provenance of an asset
bip-tap-universe: describes the Universe server construct, which is an off-chain index into TAP data on-chain, used for: proof distribution, asset boostraping, and asset transaction archiving.

For each BIP, we also include a sub-directory that includes comprehensive test vectors (to be expanded over time).

bip-tap: BIPs for the Taproot Assets Protocol c156b7691d

Roasbeef force-pushed on Sep 6, 2023

ChrisMartl commented at 7:25 pm on September 6, 2023: none

@Roasbeef

Could you please provide an analysis statement, which effects or how this proposal could increment the exploit exposure for the Bitcoin system due to the loose flexibility of Bitcoin’s script (predicative processing)?

Bitcoin has this predicate issue (since genesis) and it is necessary to perform a risk analysis about this for every proposed change.

Roasbeef commented at 7:33 pm on September 6, 2023: contributor

Bitcoin has this predicate issue (since genesis) and it is necessary to perform a risk analysis about this for every proposed change.

This document proposes no changes to Bitcoin. Instead it’s built as a layer on top of Bitcoin. Transactions that interact with the system look like normal taproot transactions (in the system taproot inputs and outputs are required). Only those that have the committed on chain information can distinguish these transactions from regular Bitcoin transactions.

Symphonic3 commented at 9:27 pm on September 6, 2023: none

NACK, this protocol is one of many that exist for this purpose and should remain outside of any spec for bitcoin. Application layer BIPs should provide a clear motivation resulting in a net benefit for bitcoin, which this protocol does not do. These types of applications can exist externally and do not require their spec to be recognized in this manner, except possibly if one wishes to use an appeal to authority to grant them undue extra credibility.

ChrisMartl commented at 3:13 pm on September 10, 2023: none

Bitcoin has this predicate issue (since genesis) and it is necessary to perform a risk analysis about this for every proposed change.

This document proposes no changes to Bitcoin. Instead it’s built as a layer on top of Bitcoin. Transactions that interact with the system look like normal taproot transactions (in the system taproot inputs and outputs are required). Only those that have the committed on chain information can distinguish these transactions from regular Bitcoin transactions. @Roasbeef So, this proposal incentives the usage of exploits of already existing op codes for storage of arbitrary data to be interpreted by an application layer off chain?

ChrisMartl commented at 6:54 pm on September 11, 2023: none

If the review process no-acknowledgment/acknowledgment have any relevance here, then, as Symphonic3 stated above:

NACK; this protocol is one of many that exists or exited before for this purpose and should remain outside of any spec. for Bitcoin.

Application layer BIPs should provide a clear motivation resulting in a net benefit for Bitcoin as a system; this protocol does not provide that.

These types of applications can exist externally and do not require their specs. to be recognized in this manner, except possibly if one wishes to use an appeal to authority to grant them undue extra credibility or some source of truth.

Roasbeef commented at 8:21 pm on September 11, 2023: contributor

NACK, this protocol is one of many that exist for this purpose and should remain outside of any spec for bitcoin.

BIPs aren’t limited to only specs for Bitcoin consensus. There are numerous BIPs, many of which you’ve probably never heard about and don’t affect the way you use Bitcoin. I recommend you read the very first BIP which outlines the process, including what items are in scope and how the process has evolved over time. It’s clear you don’t fully understand how the BIP process works, so I recommend brushing up before posting more off-topic comments here.

Concepts like NACKs and ACKs don’t necessarily apply at this level (particularly as the BIP describes no consensus changes, but even those that do are able to be assigned BIP numbers, even if they aren’t widely adopted). If you’re able to give technical feedback on the proposal, then those comments would be pertinent.

So, this proposal incentives the usage of exploits of already existing op codes for storage of arbitrary data to be interpreted by an application layer off chain?

I recommend you read the specification to understand the protocol fully before commenting based on an incomplete mental model. The protocol adds no additional storage to Bitcoin, beyond normal P2TR UTXOs (looks just like normal transactions).

ChrisMartl commented at 9:11 pm on September 11, 2023: none

@Roasbeef

This is a review process from everyone with any level of understanding of the Bitcoin system. Your role is to reach social consensus among a super majority of the Bitcoin stakeholders. And your role is to translate your high level of understanding to participants with lower understanding level; not to exploit your relative competitive advantage. You way of writing seems to be in an arrogant attitude.

So, your proposal, while not adding anything new to the protocol and the system, consists simply in storing a witness program (as usual, in the transaction output) hashed from an envelope of arbitrary data stored somewhere off-timechain. Or did I understand it wrongly? If so, could you please be less arrogant and explain it to people with less understanding than yours?

achow101 commented at 11:12 pm on September 11, 2023: member

Your role is to reach social consensus among a super majority of the Bitcoin stakeholders.

It is not. Just because something has a BIP number doesn’t mean it’s a good idea or that it has consensus. BIPs are merely a repository of specifications that are technically sound, well specified, and could be deployed if everyone chose to do so. That is the bar. No consensus needs to be achieved.

The merits of a particular proposal can be debated in other fora such as the bitcoin-dev mailing list. Please keep discussion here about the text itself and whether it sufficiently conveys the specification. Whether it is something that should be deployed is off topic.

ChrisMartl commented at 4:16 am on September 12, 2023: none

Your role is to reach social consensus among a super majority of the Bitcoin stakeholders.

It is not. Just because something has a BIP number doesn’t mean it’s a good idea or that it has consensus. BIPs are merely a repository of specifications that are technically sound, well specified, and could be deployed if everyone chose to do so. That is the bar. No consensus needs to be achieved.

Well, that is not how BIP2 defines the way of proceedings. I don’t want to debate with you this topic here.

The merits of a particular proposal can be debated in other fora such as the bitcoin-dev mailing list. Please keep discussion here about the text itself and whether it sufficiently conveys the specification. Whether it is something that should be deployed is off topic.

Since it is a review process, the discussion is being performed on the substance and not of the form. For review of forms, others automated methods can be done more efficiently.

ChrisMartl commented at 4:32 am on September 12, 2023: none

@achow101

I might suggest you to have one source of truth or one source of discussion if you want to have a lesson learned from failures of the past in Bitcoin regarding BIPs and technical substantials; take following example, more or less six years ago a hypothetical scenario was addressed in a different forum. The topic was relevant and it is more relevant now in the current circumstances, but did that topic reach the right hears at that time? Could have it had a better outcome if it were discussed in one place close where the reference changes are happening?

https://bitcoin.stackexchange.com/questions/54849/segwit-arbitrary-data-storage-in-witness

bip-tap-psbt: define value for asset version

Using this, the vPSBT packet now contains the information required to
have a distinct asset version for a given output.

270a9f9d6b

Merge pull request #42 from Roasbeef/bip-tap-psbt-asset-version

bip-tap-psbt: define value for asset version

58b218e3d3

bip-tap-addr: sync TLV types 257edb65ab

bip-tap-addr+bip-tap-vm: replace key_family with group_key 2c8de8879f

bip-tap: use even/odd TLV numbers for asset encoding 7e3dfd985e

bip-tap-proof-file: use even/odd TLV numbers for proofs 1828353d2e

Merge pull request #43 from guggero/tlv-re-numbering

Use even/odd TLV numbers everywhere

666d60e87f

bip-tap: clarify prev_asset_id and prev_asset_script_key

To avoid confusing it with the "next" asset_script_key and asset_id, we
rename the fields slightly.

f4c73241e4

bip tap: move asset_id reveal to proof file 373551d7d9

bip-tap: make minting witness encode asset internal key

This let the verifier check that the `asset_group_key` is derived
correctly from the internal key, and that the signature is valid.

67366eb8af

bip-tap proof: reveal asset_group_key at genesis proof a25ef95ecf

bip-tap proof file: also first transition now requires witness validation 1b68510b98

bip-tap vm: specify that minting transition witnesses must be verified cc3e1ceea5

bip-tap-universe: split universe trees, use new sum values

In this commit, we split the Universe trees into transfer vs issuance.
The leaf sum value for issuance is the number of units, while for
transfer just `1` (accumulator).

For Multiverse trees, we make a similar distinction. The sum value for
an issuance multiverse is just 1, so it tracks the total amount of
assets committed to. For transfer multiverses, the value here is the
same as the root of a transfer universe, this ends up summing to the
total number of transfer committed to.

aeb9e47dad

Merge pull request #45 from Roasbeef/split-universe-trees

bip-tap-universe: split universe trees, use new sum values

6dd3458ddc

kallewoof commented at 3:44 am on December 14, 2023: contributor

LGTM. @luke-jr ?

luke-jr added the label New BIP on Dec 26, 2023

luke-jr commented at 7:02 pm on December 26, 2023: member

Confused about why “blip-tap” isn’t included here…?

illesdavid approved

Roasbeef commented at 2:28 am on January 16, 2024: contributor

Confused about why “blip-tap” isn’t included here…?

That defines LN extensions to put the stuff committed in UTXOs into channels. No BIPs cover LN/BOLT channels as defined. It’s written as an extension to the BOLTs, so it assumes existing knowledge of just about everything specified in the BOLTs.

It’s also the case that everything in these BIPs has been implemented, but not all the LN extension stuff has been implemented yet (no vest vectors, etc).

bip-tap: correct `asset_tree_root` usage

The field `asset_tree_root` is not 40 bytes long, but 32.

This is both consistent with the implementation, and with the definition
of the field further down in this bip.

Definition:

> the asset tree is calculated as either:
> * <code>asset_tree_root = sha256(asset_id || left_hash || right_hash
> || sum_value)</code>
> or
> * <code>asset_tree_root = sha256(asset_group_key || left_hash ||
> right_hash || sum_value)</code>

Implementation:

```
leafParts := [][]byte{
  {byte(c.Version)}, TaprootAssetsMarker[:], rootHash[:],
  rootSum[:],
}
```

The bip now reflects this.

71c83e5999

fixup! bip-tap: correct `asset_tree_root` usage deffebf4f7

fixup! bip-tap: correct `asset_tree_root` usage 165fab1ce4

5twelve approved

luke-jr commented at 5:54 pm on October 17, 2024: member

BIPs cover LN. Those should be BIPs too.

Merge pull request #47 from gijswijs/fix-asset-tree-root-length

bip-tap: correct `asset_tree_root` usage

66b59192d5

dstadulis commented at 0:44 am on November 22, 2024: none

BIPs cover LN.

The bip-tap series cover the layer one technical scope of how to implement the client side proving and verification demands – but not Lightning Network functionality. E.g. what properties MUST a taproot-assets implementation produce to be securely operating with another taproot-asset client. Think: the proving, validation, data availability designs for taproot-asset clients.

Given that LN functionality is merely about how lightning nodes handle pre-signed bitcoin transactions, including these, higher-layer design requirements, into bitcoin BIPs isn’t necessary for an implementation to meet and would be a layer violation.

This layer segmentation is akin to how the taproot BIPs 341 don’t include references for how P2TR outputs must be used in the simple_taproot_channels lightning designs – the scope of design demands is orthogonal.

Those should be BIPs too.

Including a link, to the taproot asset bLIP, in an appendix / related reading section seems helpful https://github.com/lightning/blips/pull/29

bip-tap: BIPs for the Taproot Assets Protocol #1489

Overview

BIP Documents