bitcoin
bip-tap: BIPs for the Taproot Assets Protocol
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).
@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.
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.
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.
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?
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.
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).
@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?
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.
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.
@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
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).
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
I support this proposal. Bitcoin must remain a financial settlement protocol. Enforcing consensus-level constraints on arbitrary data — particularly large OP_RETURN payloads — is essential to prevent abuse that threatens Bitcoin’s utility, legal neutrality, and long-term sustainability. This soft fork moves in the right direction. ---mikeD
