Why Segregated Witness Will NOT Decrease the Memory Burden on Nodes

Why Segregated Witness Will NOT Decrease the Memory Burden on Nodes

5138
7
SHARE

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).

Also read: Network Alternative Bitcoin Unlimited Closing In On ‘Opponent’ Segwit Proposal

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.

Why Segregated Witness Will NOT Decrease the Memory Burden on Nodes
Net-new-UTXO is a measurement of #outputs – #inputs.

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]

instead of,

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.

  • mably

    And then come Schnorr signatures permitted by SegWit script versioning…

    • Patrick Miller

      Yes, Schnorr sigs aggregation gives us the ability to dramatically reduce UTXO set. This is fairly straightforward.

      To oppose SegWit given how many different scaling options it enables, is a tragedy.

  • mably

    Why are you censoring my comment? Please answer.

    I thought you were against censorship here. Looks like a joke.

    • Gary

      Hi mably,

      I’m very sorry that your post didn’t get approved as quickly as it should; there’s a large backlog of unapproved comments due to some crossed wires about who was to sift through them for spam – I will be taking the time over the next few days to clear this backlog so as comments aren’t left in limbo.

  • Chris Priest

    If you really want to incentivise shrinking the UTXO set size, then the best solution is to remove the blocksize limit denominated in bytes, and replace it with a blocksize limit denominated in outputs. This way, the fee for a transaction with 100 inputs and 1 output is the same as a transactions with one input and one output. The concept of a UTXO that is too small valued to be profitable to spend goes away. All UTXOs are completely free to spend.

    • Patrick Miller

      Schnorr signature aggregation has a similar effect. I believe that what you proposed could be gamed and lead to spam attacks.

  • spiroseliot

    i run node almost three years now and never had a memory problem with them.
    The only system that their node has serious memory problem is ethereum.