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

pull Roasbeef wants to merge 16 commits into bitcoin:master from Roasbeef:bip-tap-pr changing 23 files +94914 −0
  1. 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).

  2. bip-tap: BIPs for the Taproot Assets Protocol c156b7691d
  3. Roasbeef force-pushed on Sep 6, 2023
  4. 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.

  5. 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.

  6. 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.
  7. 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?

  8. 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.

  9. 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).

  10. 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?

  11. 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.

  12. 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.

  13. 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

  14. 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
  15. Merge pull request #42 from Roasbeef/bip-tap-psbt-asset-version
    bip-tap-psbt: define value for asset version
    58b218e3d3
  16. bip-tap-addr: sync TLV types 257edb65ab
  17. bip-tap-addr+bip-tap-vm: replace key_family with group_key 2c8de8879f
  18. bip-tap: use even/odd TLV numbers for asset encoding 7e3dfd985e
  19. bip-tap-proof-file: use even/odd TLV numbers for proofs 1828353d2e
  20. Merge pull request #43 from guggero/tlv-re-numbering
    Use even/odd TLV numbers everywhere
    666d60e87f
  21. 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
  22. bip tap: move asset_id reveal to proof file 373551d7d9
  23. 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
  24. bip-tap proof: reveal asset_group_key at genesis proof a25ef95ecf
  25. bip-tap proof file: also first transition now requires witness validation 1b68510b98
  26. bip-tap vm: specify that minting transition witnesses must be verified cc3e1ceea5
  27. 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
  28. Merge pull request #45 from Roasbeef/split-universe-trees
    bip-tap-universe: split universe trees, use new sum values
    6dd3458ddc
  29. kallewoof commented at 3:44 am on December 14, 2023: contributor
    LGTM. @luke-jr ?
  30. luke-jr added the label New BIP on Dec 26, 2023
  31. luke-jr commented at 7:02 pm on December 26, 2023: member
    Confused about why “blip-tap” isn’t included here…?
  32. illesdavid approved
  33. 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).

  34. 5twelve approved
  35. luke-jr commented at 5:54 pm on October 17, 2024: member
    BIPs cover LN. Those should be BIPs too.

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-31 23:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me