Want to save on fees? Stop using addresses!
Given the rise in bitcoin transaction fees, it makes sense to carefully consider the most cost-effective way to use bitcoin. To do this, one needs to understand the structure of bitcoin transactions and their relative sizes. The reason is that the size of the fee for a transaction is proportional (only) to the number of bytes of the transaction. Fees have no relationship to the amount of bitcoin being transacted.
The size of a bitcoin transaction mainly depends on the number of inputs and the number of outputs. Assuming the number of inputs and outputs are reasonable (less than 128 inputs and 128 outputs), a transaction will consist of 10 bytes, plus some bytes for each input and some bytes for each output. The purpose of each output is to create a new utxo (unspent transction output). The purpose of each input is to spend the output of a previous transaction (a previously created utxo).
The number of bytes required for each input and output depends on the type of utxo being spent or created. Each input requires 40 bytes plus the size of the script proving the utxo is allowed to be spent. Each output requires 8 bytes plus the size of the script indicating what is required to spend the utxo later.
More details about the format of transactions can be found at
en.bitcoin.it/wiki/Transaction
The most common type of utxo is so-called pay-to-pubkey-hash (p2pkh). The utxo is created by giving a script that contains a 20 byte hash of a public key. This 20 byte hash is what correspond to p2pkh “addresses”. The script in the output creating such a utxo is 25 bytes. Combined with the 8 bytes giving the number of satoshis, creating a p2pkh utxo requires 25 bytes.
Spending a p2pkh utxo requires giving the public key and a signature. Complicating matters a bit further, public keys may be “compressed” (33 bytes) or “uncompressed” (65 bytes). The compressed pubkey and uncompressed pubkey are associated with different addresses, so we must distinguish between compressed p2pkh utxos and uncompressed p2pkh utxos. Signatures are often 73 bytes (though it’s possible this can vary). Spending a compressed p2pkh utxo requires a script of about 108 bytes, meaning the input spending the utxo will have a total of 148 bytes. Spending an uncompressed p2pkh utxo requires a script of about 140 bytes, meaning the input spending the utxo will have a total of 180 bytes. For the most part, we can assume all newly created p2pkh utxos will be compressed p2pkh. However, there are likely many old uncompressed p2pkh utxos waiting to be spent, so we will not ignore them here.
Many bitcoiners may be unaware that originally bitcoin did not work with addresses at all. Instead the utxo contained the public key itself (instead of its hash). This required more bytes to create the utxo (outputs of txs were bigger) but fewer bytes to spend the utxo (inputs of txs were smaller). These are called pay-to-pubkey (p2pk) utxos. To see examples of p2pk in action, look at transactions in the first blocks of the bitcoin blockchain carefully. (Most block explorer present these using addresses, so one must look at the actual transactions themselves. The commands getrawtransaction and decoderawtransaction in the Bitcoin Core client can be used for this purpose.)
Why were addresses introduced? There are two main arguments for addresses. One is the fact that 20 bytes can be represented in a relatively short way (the familiar Base58 format with a checksum). This makes them more user friendly. The other argument is that addresses are slightly cryptographically safer, since one does not need to reveal the public key until it is time to spend the utxo. Both of these are valid arguments in favor of p2pkh utxos. Here we consider the cost of using p2pkh instead of p2pk.
Again, we must distinguish between compressed and uncompressed pubkeys. The early use of p2pk made use of uncompressed pubkeys, requiring 65 bytes to specify the public key when the utxo was created. It is probably only very few early adopters concerned with uncompressed p2pk utxos and there is no reason to create new uncompressed p2pk utxos, so we will ignore this possibility. From now on, we assume p2pk utxos are given by compressed pubkeys. Creating such a p2pk requires 41 bytes (8 bytes for the number of satoshis and 35 bytes for the script with the compressed pubkey). Spending a p2pk utxo requires giving a script with (approximately) 74 bytes containing the signature, in addition to the 40 bytes every input requires, giving a total of 114 bytes.
A very different kind of utxo is provided by pay-to-script-hash (p2sh), which will simply ignore in this article.
We now have enough information to compute an estimated size of a transaction. Suppose a transaction spends i_p p2pk utxos, i_c compressed p2pkh utxos and i_u uncompressed p2pkh utxos. Suppose the transaction creates o_p new p2pk utxos and o_c compressed p2pkh utxos. (There is no reason to create new uncompressed p2pkh utxos, so we ignore this possibility. Then the number of bytes of the transaction should be
size(i_p,i_c,i_u,o_p,o_c) = 10+114 i_p+148 i_c+180 i_u+41 o_p+33 o_c.
Given this function, we can compute the relative sizes of transactions if we make different choices about the kinds of utxos we use. For example, assume we regularly create transactions with two inputs and two outputs. Each such transaction if we solely use compressed p2pkh utxos has size
size(0,2,0,0,2) = 10 + 148*2 + 33*2 = 372 bytes
On the other hand, if we solely use compressed p2pk utxos each such transaction has size
size(2,0,0,2,0) = 10 + 114*2 + 41*2 = 320 bytes.
This is a savings of 14% in terms of bytes, and hence in terms of fees.
It is not realistic, of course, to assume everyone stops using p2pkh (addresses). However, businesses who make regular transactions to maintain an internal wallet as well as interact with customers could use p2pk utxos for internal use and p2pkh for interaction with customers. This could result in transactions where half the utxos are p2pk and the other half are (compressed) p2pkh. Again, assume two inputs and two outputs for simplicity. Such transactions would have size
size(1,1,0,1,1) = 10 + 114 + 148 + 41 + 33 = 346 bytes.
This is still a savings of 7%.
The situation is complicated still further by the fact that fees vary over time. Even simple bitcoin savers may want to know if they should move p2pkh utxos into p2pk utxos. To give a simple example, suppose a bitcoin saver has a wallet with a single compressed p2pkh utxo with 2 bitcoins. A transaction spending this utxo to a new compressed p2pk utxo would have size
size(0,1,0,1,0) = 10 + 148 + 41 = 199 bytes.
If 150 satoshis per byte is the current fee rate, then the new utxo would only have 1.99970150. However, suppose two months from now the fee rate is 1000 satoshis per byte. A transaction spending the new p2pk utxo to a single p2pkh utxo would cost
1000 * size(1,0,0,0,1) = 1000 * (10 + 114 + 33) = 157000 satoshis
leaving 1.99813150 bitcoins. On the other hand, if the saver still had the original 2 bitcoins in the compressed p2pkh utxo, then spending to a single p2pkh utxo would cost
1000 * size(0,1,0,0,1) = 1000 * (10 + 148 + 33) = 191000 satoshis
leaving 1.99809 bitcoins, which is actually slightly less.
Using similar calculations, it is possible to see that it is worthwhile to move
an uncompressed p2pkh utxo into a p2pk utxo if one expects fees
to increase by four times.
Bitcoin savers may also wonder if it is worth it to consolidate p2pkh utxos into a single p2pk utxo, even though this may be bad for privacy. The answer is yes, assuming fees will double. More precise information will be given in a future article.
In summary, in order to make the most cost-effective use of bitcoin, it is better to use (compressed) p2pk utxos instead of p2pkh utxos (addresses). Compressed p2pk utxos are already supported by the bitcoin protocol, so no forks are required to make this change. Likewise, no one’s permission is required to begin making use of p2pk utxos. The only problem is that wallets are currently wedded to the p2pkh “address” format, so making use of p2pk requires more technical knowledge to craft transactions by hand.
