Andreas Antonopoulos published an interesting article last August on the effect segregated witness (Segwit) may have on the unspent transaction output set (UTXO set). I didn’t agree with the conclusions in that article, and thought about writing about it back in August. Which I didn’t. Now that the article has sailed up as hot stuff again on the interwebs, I got a second chance.
The article notes: “The incentives created by fees matter because they affect the behavior of wallets” (emphasis mine).
An example was presented with two transactions, A and B. A with 3 multisig inputs and 2 outputs, and B with 2 multisig inputs and 3 outputs.
The higher the Net-new-UTXO of a transaction the more the UTXO set will grow due to this transaction. We can see that without Segwit, transaction B (with highest Net-new-UTXO) is the cheapest transaction, but with Segwit, transaction A (with the lowest Net-new-UTXO) is the cheapest one.
The point that the article makes from this is that incentives will shift from making transactions with positive Net-new-UTXO to making transactions with negative Net-new-UTXO. Or at least the incentives will shift towards less Net-new-UTXO. The article concludes: “After segregated witness, the transaction fees align with the incentive to minimize new UTXO creation”.
This is where I get lost. While this is certainly interesting data, I’m looking at it from the perspective of a wallet. The wallet must obey its user’s will. The user wants to pay a bill, so the wallet will somehow collect inputs and create outputs to fulfill that will.
The wallet wants to do this cheaply, so it will only use two outputs. One for the bill and one for the change. There’s not much choice there, regardless of whether Segwit is used or not.
The question then comes down to selecting inputs. All inputs cost money to include, so every extra input will result in a more expensive transaction. If Segwit is used, the cost is at a 75% discount, but the coin selection should not change much since the wallet still wants to keep the number of inputs low.
My conclusion is that Segwit does not affect the behavior of wallets.
There are, however, some UTXOs that have so little value that you would lose money to include them. They would cost more in fees than the value they provide, causing a net loss on the spendable output amounts. Many of those UTXOs will be pushed over the edge to the profitable side when Segwit is used, because they are now cheaper to include. It might be this effect that the article refers to, but I don’t think so.
If any of you (I’m looking at you Andreas!) have more insight into this, please let me know by commenting on this article.
Fix Might Actually Increase UTXO set
Frankly, if I’m right above, the UTXO set might actually increase with Segwit. An output which use 2-of-3 multisig, will take 34 bytes with Segwit instead of today’s 23 bytes.(See BIP141.) The increase in bytes is due to the witness script hash being 32 bytes instead of the 20 bytes script hash. The scriptPubKey becomes,
0x00 0x20 [32-byte-hash]
OP_HASH160 0x14 [20-byte-hash-value] OP_EQUAL
This increase in hash size is a security measure to protect against future collision attacks since we are approaching the limit for when a collision attack on 20 byte hashes is feasible. Though I’m not sure why a collision attack would be a concern. Shouldn’t we only have to worry about preimage attacks? Anyway, this increase has not much to do with Segwit since it’s a security measure that would possibly be needed anyway in the future for P2SH, and P2PKH as well. It was just a good opportunity to sneak in the fix for P2WSH.
Of course, this depends on how the mix of payment types will play out. Some types will be smaller with Segwit, for example a P2WPKH (pay-to-witness-public-key-hash) and a P2PKH (pay-to-public-key-hash, the most common payment type), weigh 22 bytes and 25 bytes respectively, which is a net win of 3 bytes per output.
Don’t get me wrong on all this. I am a huge fan of Segwit and I would like to see it activate ASAP, but the referenced article has kept me puzzled for too long now.
Thank you for your patience.
This is an Op-ed article. The opinions expressed in this article are the author’s own. Bitcoin.com does not endorse nor support views, opinions or conclusions drawn in this post. Bitcoin.com is not responsible for or liable for any content, accuracy or quality within the Op-ed article. Readers should do their own due diligence before taking any actions related to the content. Bitcoin.com is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any information in this Op-ed article.
Do you want to talk about bitcoin in a comfortable (and censorship-free) environment? Check out the Bitcoin.com Forums — all the big players in Bitcoin have posted there, and we welcome all opinions.