This year has seen a massive upswing in demand for the limited space available within bitcoin blocks, leading to higher fees for on chain transactions. Much of the demand is for transactions revealing inscriptions. The contents of these inscriptions are revealed as part of the witness data1 of a bitcoin transaction. This witness data1 is discounted to one quarter the cost of other transaction data. Why are we giving these inscriptions a discount? Should we soft-fork out the witness discount?
Why are some bytes cheaper than other bytes? Money in general and bitcoin in particular operate on the back of human incentives. Bitcoin aligns the incentives of miners and transactors through the use of the native bitcoin token to pay miners for inclusion of particular transactions in the blocks they construct. The same cannot be said of aligning the incentives of node runners with miners and transactors, nor of aligning incentives between senders and recipients.
There have been 3 major improvements to bitcoin’s incentive alignment to date:
- Limiting block size
- Shifting the cost of complex scripts from sender to recipient (P2SH)
- Aligning the costs of data between node runners and transactors (SegWit)
Limiting The Block Size
Transactors want to make lots of transactions and miners want to collect lots of transaction fees; but node runners have to relay, verify, and store all of that transaction data and they are not compensated like miners for doing so. Early in bitcoin’s history, Satoshi worked to address this by adding a fixed block size limit (enforced by nodes). The limit was 1 million bytes per block, and put an upper bound on the amount of data that nodes would need to download and verify. At the time, Satoshi wrote, “[w]e can phase in a change later if we get closer to needing it.” Later, referring to a patch to increase the limit, he noted, “[d]on’t use this patch, it’ll make you incompatible with the network”, meaning that increasing the block size limit is a hard fork change and requires more coordination even than a soft fork. In the years that followed, bitcoin deliberately avoided such incompatible hard fork changes, which has also meant keeping the 1 million byte block size limit.
Shifting Complex Script Costs From Sender To Recipient
Because bitcoin is secured by locking scripts, it has always been possible to lock it with advanced scripts, including multisig. Under the original design, the sender of a bitcoin transaction would place the recipient’s full locking script in their transaction, and pay any fees to get that locking script included in a block. Developers realized that as fees increased, senders might become hesitant to pay users of larger locking scripts due to the higher cost of paying those users. These complex locking scripts also posed a problem for encoding into addresses and sharing via low bandwidth mechanisms such as QR Code.
To resolve this, P2SH was added to bitcoin as a soft fork. Under the rules of this fork, instead of putting the recipient’s entire locking script in the output of the transaction, the sender simply includes a hash of it. When the recipient inevitably spends that output, they include the full script in the spending transaction, which is checked against the hash of the script the coin is locked to before being validated. With this change, a redeem script of any size could be represented by a locking script of a fixed length and senders no longer had a need (or ability) to discriminate between recipients based on their spending conditions.
Aligning The Costs Of Data Between Node Runners And Transactors
The most fundamental verification that nodes perform on bitcoin transactions is that the bitcoin they attempt to spend does, in fact, exist. To do this, each node maintains an index of each unit of spendable bitcoin (unspent transaction output, UTXO). The larger this index, the greater the cost of running a node and verifying future transactions2. As a result, a transaction which increases the size of this index (having more outputs than inputs) costs more over time than a transaction with the same number of bytes that reduces the index size. The significantly higher cost of consuming vs. creating UTXOs creates an incentive conflict between node runners and transactors.
Enter Segregated Witness
The segregated witness (SegWit) soft fork is the most ambitious change made to bitcoin to date. The greatest motivation for the change was to fix the long standing problem of TXID4 malleability5 in bitcoin. In order to fix this malleability, the unlocking script is replaced with a newly created “witness”. By removing the authorization data (which can often be changed by third parties without changing the effects of the transaction) from the TXID, protocols (such as Lightning) which depend on unchanging TXIDs become possible.
With the authorization data moved out of the original transaction structure, it no longer counts against the 1 million byte block limit. A new limit is required. Many approaches to limiting the segregated witness data were discussed at the time: A separate witness byte limit6, a combined limit of < 1 million bytes7, or a weighted combined limit. In the end, the weighted combined limit was chosen, with segregated witness data weighted at 1-unit, transaction data weighted at 4-units, and a 4 million weight block limit. Each weight unit is treated as 1/4 of a virtual byte (vByte) for the purpose of fee calculations.
Taproot And Inscriptions Change Everything (Or Nothing)
As I said at the outset, bitcoin rides on human incentives, and here we can see how changes have been made to bitcoin over the years to improve the alignment of incentives between the parties using the network. Taproot itself is “just” an alternative way of locking bitcoin using segregated witness. It doesn’t change these incentives significantly. One of the changes that came along with Taproot was to remove certain limits on script size. This was done to reduce the complexity of designing analysis tools for bitcoin scripts, and as an acknowledgement of the relative cost of different types of data. Removing these limits made inscriptions simpler than they were before Taproot, but didn’t fundamentally change the incentive structure of the network.
Now to the crux of the matter. Inscriptions are revealed in the witness, so they’re only charged 1/4 vByte per byte of inscription data. Is this an abuse of the witness discount? The truth is that inscription data is some of the cheapest data for nodes on…