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:
1. Limiting block size
2. Shifting the cost of complex scripts from sender to recipient (P2SH)
3. 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 largest part of most bitcoin unlocking scripts is the cryptographic signatures. These signatures are about twice the size of their corresponding public keys, which makes the unlocking scripts (even without P2SH) larger than the locking scripts.
The significantly higher cost of consuming vs. creating UTXOs creates an incentive conflict between node runners and transactors. Transactors are disincentivized from spending their small UTXOs (especially at times with high fees), preferring instead to spend large UTXOs and create more small change UTXOs. Meanwhile node runners pay the cost for this accumulation of small UTXOs in higher validation costs for all transactions.
Odd as it may seem, the verification that each UTXO spent by a transaction in the historical blockchain has its locking script satisfied by a corresponding unlocking script is significantly less fundamental. For that matter, a bitcoin node running default bitcoin core 26.x will not validate the full locking script execution for transactions before block 804000 (August 19, 2023).
All of the above means that there are different costs imposed on bitcoin nodes by different portions of the blockchain. Data required to determine the effects of each transaction must be validated by each node syncing from the genesis block3, transaction outputs tend to be more costly than transaction inputs in the long run (especially if they are long lived), and much of the witness data isn't even checked except for the most recent transactions.
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.
Why these weights? Let's look at the cost of transaction inputs and outputs with and without segregated witness:
The first thing to note from this table is how the witness script types (P2WPKH, P2WSH) have nearly the same number of input and output bytes (which are charged a full vByte each). The spender of a witness script is then charged 1/4 vByte for the data authorizing the spend, much of which is not verified for any but the most recent transactions, and none of which has an ongoing cost in the UTXO index. The other thing worth noting here is how the cost of using a more secure 2-of-3 multisig compared to a single signature is reduced from 147 vBytes to 36.25 vBytes.
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 the network to validate. The script structure used by inscriptions explicitly skips execution of the inscription data, so the only verification done on it is a single hash check (ensuring that the revealed inscription is what the inscriber planned to reveal). This data is hashed once and then never looked at again by nodes. It has a very low computational cost (an order of magnitude lower than an equivalent size multisig script).
But inscriptions are driving up fees and pushing out other users.
Yes! With the current software available for interacting with the bitcoin network, inscriboooors have greater economic incentive to make their inscriptions than many folks have to make other transactions.
This throws into stark relief the value of increasing the economic density of bitcoin transactions. The Lightning Network takes a huge step toward this by enabling hundreds, thousands, or millions of economic transactions to be packed into a single bitcoin transaction. The greater the economic density of each byte in a transaction the lower the fee paid for that economic activity. As the economic density of bitcoin transactions increases, other uses of block space have been and will continue to be priced out9.
It's worth noting that if off chain multisig protocols such as MuSig2 or FROST, or adaptor signatures become prevalent; it may make sense to reduce or eliminate the witness discount. These protocols can enable otherwise large spending conditions to be represented by a single signature. This, combined with Taproot's efficient key path spending could bring the cost of an input with nearly arbitrarily complex conditions down to only 105 Bytes.
Conclusion
The response to high fees caused by inscriptions is the same as to any other supposed sky is falling scenario in the history of bitcoin: Patiently build, patiently build. There's a lot we can do to increase the economic density of bitcoin transactions from building better Lightning wallets to Ark to discrete log contracts and beyond. Removing the witness discount (prematurely), rolling back taproot, or similar counter-productive actions will only serve to reduce the economic density of current bitcoin transactions and exacerbate the situation.
Stay humble, stack sats, and build.
Footnotes
* The term witness was adopted into bitcoin from cryptography jargon where it refers to data needed to efficiently verify a cryptographic claim. BIP141 defines it as any "data required to check transaction validity but not required to determine transaction effects". Cryptographers may have picked the term up from manufacturing witness marks used to efficiently verify the alignment of components.
* The Utreexo project aims to change this for a subset of bitcoin nodes by allowing them to efficiently accumulate UTXO inclusion roots and then receive the inclusion paths along with the spends of those UTXOs. If this becomes a common way to use bitcoin, it shifts the cost of more UTXOs from the nodes to the holders of those UTXOs.
* The ZeroSync project aims to change this for some nodes in some contexts.
* Transaction ID: Reversed byte order double SHA256 of the pre-segwit network format transaction.
* Multiple valid transactions with the same inputs and outputs have different txids if they are signed in different ways or have their signatures modified by a third party.
* Can be any value without a hard fork because old nodes are not aware of the segregated witness data.
* 1-million or less to maintain compatibility and prevent a hard fork.
* Assuming the use of compact public keys and 71-byte low-R/S DER signatures.
* Anyone remember Satoshi Dice?
This is a guest post by Brandon Black. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
http://dlvr.it/T0JJjk
Comments
Post a Comment