Re: [bitcoin-dev] Concern about "Inscriptions"
> that does not change the fact that Alice -> Bob -> Zack was mined in the > blockchain, and those transactions exist If you use it in that way, then cut-through is pointless. The whole point of using it is scaling. If you have only "Alice -> Zack" transaction, that is included in some block, then cut-through is really useful. In other cases, if you include all transactions anyway, and create only a proof for some nodes, then it doesn't scale, because you have to always process those transactions in the middle, while there is no need to do so. It is needed only during batching, to prevent double-spending, but if it is deeply confirmed, then who needs something that doesn't scale? Also, going in that direction is a natural consequence of enabling full-RBF: transactions will be replaced, which means mempool-level-batching (ideally non-interactive, done automatically by nodes) will be next, sooner or later. On 2023-09-05 19:49:51 user Peter Todd wrote: On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote: > > Given the current concerns with blockchain size increases due to inscriptions, and now that the lightning network is starting to gain more traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning? > > People will not agree to shrink the maximum block size. However, if you want to kill inscriptions, there is another approach, that could be used to force them into second layers: it is called cut-through, and was described in this topic: https://bitcointalk.org/index.php?topic=281848.0 > > Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for example some inscriptions were created in "Alice -> Bob" transaction, then cut-through could remove those inscriptions, while leaving the payment unaffected, because the proper amount of coins will be received by Zack, as it should be. You are incorrect: cut-through transactions will not meaningfully affect inscriptions. While it is true that with fancy cryptography we can prove the Alice -> ... -> Zack chain, that does not change the fact that Alice -> Bob -> Zack was mined in the blockchain, and those transactions exist. Anyone running a full archival node will still have those transactions, and can provide them (and all their inscription data) to anyone who needs it. This is not unlike how in Bitcoin right now many people run pruned nodes that do not have any archival inscription data. Them running those nodes does not prevent others from running full archival nodes that do make that data available. -- https://petertodd.org 'peter'[:-1]@petertodd.org___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP-????: The Taproot Assets Protocol
After more than a year of tinkering, iterating, simplifying, and implementing, I'm excited to officially publish (and request BIP numbers for) the Taproot Assets Protocol. Since the initial publishing we've retained the same spec/document structure, with the addition of a new BIP that describes the vPSBT format (which are PSBTs for the TAP layer). Each BIP now also contains a set of comprehensive test vectors (to be further expanded over time. https://github.com/bitcoin/bips/pull/1489 As the complete set of documents is large, we omit them from this email. The breakdown of the BIPs are as follows: * `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. Some highlights of the additions/modifications of the BIPs since the initial drafts were published last year: * Test JSON vectors for each BIP document now included. * The Universe construct for initial verification of assets, distributing asset proofs, and transaction archiving is now further specified. A naive and tree based syncing algorithm, along with a standardized REST/gRPC interface are now in place. * The asset group key structure (formerly known as asset key families) has been further developed. Group keys allow for the creation of assets that support ongoing issuance. A valid witness of a group key during the minting process allows otherwise disparate assets to be considered fungible, and nested under the same sub-tree. A group key is itself just a taproot output key. This enables complex issuance conditions such as: multi-sig threshold, hash chain reveal, and any other conditions expressible by script (and eventually beyond!). * New versioning bytes across the protocol to ensure extensibility and upgradability in a backwards compatible manner where possible. The asset metadata format now has been re-worked to only commit to a hash of the serialized meta data. Asset metadata can now also have structured data, key-value or otherwise. * Observance of re-org protection for asset proofs. The file format now also uses an incremental hash function to reduce memory requirements when added a new transition to the end of the file. * Specification of the vPSBT protocol [1] which is the analogue of normal PSBTs for the TAP layer. The packet format specifies custom key/value pairs for the protocol describes an aggregate TAP transaction. After the packet is signed by all participants, it's "anchored" into a normal Bitcoin transaction by committing to the resulting output commitments and witnesses. We've also made significant advancements in our initial implementation [2], with many wallets, explorers, services, and businesses working with us to test and iterate on both the protocol and the implementation. We're actively working on our next major release, which will be a major milestone towards the eventual mainnet deployment of the protocol! -- Laolu [1]: https://lightning.engineering/posts/2023-06-14-virtual-psbt/ [2]: https://github.com/lightninglabs/taproot-assets ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
