This year saw a significant increase in demand for the limited space available within a Bitcoin block, leading to higher fees for on-chain transactions. Most of the demand is for trades that reveal inscriptions. The contents of this inscription are released as part of eyewitness data.One Bitcoin trading. this witness dataOne Discounted at 1/4 of other transaction data costs. Why do we offer discounts on these inscriptions? Should we softfork the witness discount?
Why are some bytes cheaper than others?
Money in general, and Bitcoin in particular, operates based on human incentives. Bitcoin uses the native Bitcoin token to align the incentives of miners and traders by paying miners for including certain transactions in the blocks they form. The same cannot be said about aligning the incentives of node runners with miners and traders, or about aligning the incentives between senders and receivers.
To date, there have been three major improvements to Bitcoin incentive adjustments:
1. Limit block size
2. Shift the cost of complex scripts from sender to receiver (P2SH)
3. Data cost coordination between node runners and transactions (SegWit)
Block size limit
Traders want to make a lot of transactions and miners want to collect a lot of transaction fees. However, node runners must relay, verify, and store all transaction data and are not compensated for this like miners. Early in Bitcoin history, Satoshi tried to solve this problem by adding a fixed block size limit (enforced by nodes). The limit was 1 million bytes per block, putting an upper limit on the amount of data a node had to download and verify. “Changes can be phased in later as we get closer to need,” Satoshi wrote at the time. He later mentioned a patch that increases the limit, saying “(d)if you don’t use this patch you will become incompatible with the network”, meaning that increasing the block size limit is a hard fork change and is necessary. It allows for more adjustments than a soft fork. In the years that followed, Bitcoin deliberately avoided these incompatible hard fork changes, which also meant maintaining a block size limit of 1 million bytes.
Shift costs of complex scripts from sender to recipient
Because Bitcoin is protected by a locking script, it has always been possible to lock Bitcoin using advanced scripts, including multisig. According to the original design, the sender of a Bitcoin transaction places the recipient’s entire locking script into the transaction and pays a fee to include that locking script in the block. Developers have realized that as fees increase, senders may become hesitant to pay users for larger lock scripts because the cost to them is higher. These complex locking scripts also caused problems encoding them as addresses and sharing them through low-bandwidth mechanisms such as QR codes.
To solve this, P2SH was added to Bitcoin as a soft fork. Under the rules of this fork, instead of putting the receiver’s entire locking script in the transaction output, the sender simply includes the hash. When the recipient inevitably consumes that output, the spending transaction will include the entire script, which will be checked against the hash of the script in which the coins are locked before being verified. This change allows redemption scripts of any size to appear as fixed-length lock scripts, and senders no longer have the need (or ability) to discriminate between recipients based on spend terms.
Coordinating data costs between node executors and transactions
The most basic verification that nodes perform on Bitcoin transactions is that the Bitcoin they are trying to use actually exists. To achieve this, each node maintains an index for each unit of spendable Bitcoin (unspent transaction output, UTXO). The larger this index, the greater the cost of running a node and confirming future transactions.2. As a result, a transaction that increases the size of this index (with more outputs than inputs) will cost more over time than a transaction with the same number of bytes that decreases the size of the index.
The biggest part of most Bitcoin unlocking scripts is the cryptographic signature. These signatures are approximately twice the size of the corresponding public key, so the unlocking script (even without P2SH) will be larger than the locking script.
The cost of consuming UTXOs is quite high compared to generating them, creating an incentive conflict between node runners and traders. Traders are reluctant to spend small UTXOs (especially if the fees are high) and instead prefer to spend large UTXOs and generate more small UTXOs. Meanwhile, node executors pay for a small accumulation of UTXOs with a higher verification fee for every transaction.
Strange as it may seem, it is much less fundamental to ensure that each UTXO used in a transaction on a historical blockchain has a locking script satisfied by its unlocking script. Therefore, Bitcoin nodes running native Bitcoin Core 26.x will not verify full lock script execution for transactions prior to block 804000 (August 19, 2023).
All of the above means that there are different fees charged to Bitcoin nodes depending on the different parts of the blockchain. The data needed to determine the effect of each transaction must be verified by each node being synchronized in the genesis block.threeTransaction outputs tend to be more expensive than transaction inputs in the long run (especially if they are long-lived), and much of the witness data is unverified except for the most recent transactions.
Please enter a separate witness
The SegWit soft fork is the most ambitious change to Bitcoin to date. The biggest motivation for the change was to solve a long-standing problem with TXID.4 malleability5 In Bitcoin. To fix this malleability, the unlock script is replaced with a newly created “witness”. By removing authentication data from the TXID (which can often be changed by third parties without changing the impact of the transaction), protocols (such as Lightning) that rely on an immutable TXID become possible.
Once the acknowledgment data moves outside the original transaction structure, it no longer counts towards the 1 million byte block limit. New limits are needed. A number of approaches to limit disaggregated surveillance data were discussed at the time. Separate watchdog limit6Limit of less than 1 million bytes total7or weighted combined limits. In the end, the weighted combination limit was chosen as the weight of the separated witness data was 1 unit, the weight of the transaction data was 4 units, and the block weight was 4 million. Each weight unit is treated as 1/4 of a virtual byte (vByte) for fee calculation purposes.
Why are there these weights? Let’s look at transaction input and output costs with and without separate witnesses.
The first thing to note in this table is that the watchdog script types (P2WPKH, P2WSH) have approximately the same number of input and output bytes (each is billed for a full vByte). The spender in the watch script is then billed 1/4 vByte for the data authorizing the spend, most of which is not confirmed beyond the most recent transaction and incurs no ongoing cost to the UTXO index. Another thing worth noting here is that the cost of using 2-of-3 multi-signature, which is more secure than single signature, is reduced from 147vBytes to 36.25vBytes.
Taproot and inscriptions either change everything or nothing.
As I said at the beginning, Bitcoin exploits human incentives and here we can see how Bitcoin has changed over the years to improve the alignment of incentives between parties using the network.
Taproot itself is just an alternative method of locking down Bitcoin using isolated surveillance. These incentives will not change significantly. One of the changes that comes with Taproot is the removal of certain limits on script size. This was done to reduce the complexity of designing analysis tools for Bitcoin Script and to acknowledge the relative costs of different types of data. Removing these restrictions makes inscriptions simpler than before Taproot, but does not fundamentally change the incentive structure of the network.
Now to the crux of the matter. Since the inscription is visible to witnesses, only 1/4 vByte is charged per byte of inscription data. Is this an abuse of witness discounts? In fact, inscription data is one of the cheapest pieces of data that nodes in the network can verify. The script structure used for inscriptions explicitly skips execution of the inscription data, so the only check performed on it is a single hash check (ensures that the disclosed inscription is what the inscription planned to reveal). This data is hashed once and never seen again on the node. The computational cost is very low (much lower than an equivalently sized multi-signature script).
But Inscription is raising fees and crowding out other users.
yes! With the current software available to interact with the Bitcoin network, inscribers have a greater economic incentive to write their own inscriptions than many people do to make other transactions.
This brings into stark relief the value of increasing the economic density of Bitcoin transactions. The Lightning Network takes a big step toward this by allowing hundreds, thousands, or even millions of economic transactions to be bundled into a single Bitcoin transaction. The greater the economic density of each byte in a transaction, the lower the fees paid for that economic activity. As the economic density of Bitcoin transactions increases, other uses of block space have been priced in and will continue to be so.9.
What is noteworthy is If the Off-chain multisig protocols or adapter signing such as MuSig2 or FROST are becoming popular. that In May It makes sense to reduce or eliminate witness discounts. These protocols allow large spending terms to be expressed in a single signature. This, combined with Taproot’s efficient key path spending, can reduce the cost of inputs with almost arbitrarily complex conditions to 105. byte.
conclusion
The response to the high fees caused by the inscription is the same as any other scenario in Bitcoin history where the sky is falling. Be patient and build. From building better Lightning wallets to Ark, separate log contracts and beyond, there is a lot we can do to increase the economic density of Bitcoin transactions. Removing witness discounts (early), rolling back taproot, or similar counterproductive measures will only serve to reduce the economic density of current Bitcoin transactions and make the situation worse.
Stay humble, build your position, and build.
footnote
- The term witness was adopted by Bitcoin from cryptography jargon to refer to the data needed to efficiently verify cryptographic claims. BIP141 defines it as “data necessary to confirm the validity of a transaction but not necessary to determine the effect of the transaction.” Cryptographers may have picked this term from the manufacturing witness markings used to efficiently verify the alignment of components.
- The Utreexo project aims to change this by allowing a subset of Bitcoin nodes to efficiently accumulate UTXO inclusion routes and then receive the inclusion routes along with the spending of those UTXOs. If this becomes a common way to spend Bitcoin, more UTXO costs will be shifted from the nodes to those UTXO holders.
- The ZeroSync project aims to change this for some nodes in some situations.
- Transaction ID: Reverse byte order double SHA256 of pre-SegWit network format transaction.
- Multiple valid transactions with the same inputs and outputs will have different txids if they were signed in different ways or if the signatures were modified by a third party.
- Any value is possible without a hard fork since the previous node is not aware of the separated witness data.
- To maintain compatibility and prevent hard forks, there are less than 1 million.
- Assume you use a compressed public key and a 71-byte low R/S DER signature.
- Does anyone remember the Satoshi dice?
This is a guest post by Brandon Black. The opinions expressed are solely personal and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.