bip-tap: BIPs for the Taproot Assets Protocol #1489
Conversation
|
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. |
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. |
@Roasbeef |
|
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. |
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.
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). |
|
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? |
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. |
Well, that is not how BIP2 defines the way of proceedings.
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. |
|
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 |
Using this, the vPSBT packet now contains the information required to have a distinct asset version for a given output.
bip-tap-psbt: define value for asset version
Use even/odd TLV numbers everywhere
To avoid confusing it with the "next" asset_script_key and asset_id, we rename the fields slightly.
This let the verifier check that the `asset_group_key` is derived correctly from the internal key, and that the signature is valid.
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.
bip-tap-universe: split universe trees, use new sum values
|
LGTM. @luke-jr ? |
|
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). |
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 assetbip-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).