bitcoin-dev

Ordinals BIP PR

Ordinals BIP PR

Original Postby vjudeu at gazeta.pl

Posted on: November 21, 2023 23:10 UTC

The discussion revolves around the impact of posting large TapScripts, including Ordinals, on Bitcoin's mempool and its implications for regular payment transactions.

Ordinals, in their current form, compete with conventional payments due to the block size limitation of 4 MB every 10 minutes. This creates a trade-off where only one type of transaction can be confirmed—a payment or data—since both cannot coexist in a single block.

When an OP_RETURN is included in a TapScript, it becomes impossible to push that data on-chain as no valid input can satisfy such a TapScript. This necessitates the use of an alternative TapScript branch without the OP_RETURN or simply spending by key. Unlike regular OP_RETURNs that are contained within transaction outputs, TapScripts containing OP_RETURNs are revealed in transaction inputs, specifically in the witness part, which bars the commitment from being posted on-chain.

A proposed solution to better manage Ordinals involves creating a Bitcoin Improvement Proposal (BIP) that would not promote but rather appropriately handle Ordinals, allowing ordinary users to compete in this fee-based system. The proposal suggests concealing Ordinals behind an R-value, making them smaller, more cost-effective, and leaving additional space for regular transactions while maintaining the cryptographic proof that connects the data with a specific transaction input. This change would also render Ordinals uncensorable since users could opt to hide any Ordinal behind their signature across any address type, including P2PK, and reveal it later, though not on the blockchain, preserving space for other transactions.

In essence, the argument is made for transactions to prioritize payments, with Ordinals as an optional attachment, rather than relegating payments to a secondary feature beneath data pushes. This perspective underscores Bitcoin's fundamental purpose as a payment system, advocating for the prioritization of transactions as "always a payment, and optionally also an Ordinal," rather than a platform primarily used for data storage where payments are included out of protocol necessity.