Segregated Witness removes one of Bitcoin’s data integrity checks

Getting your Trinity Audio player ready...

This is a guest contribution by Jonald Fyookball. If you would like to submit a contribution please contact Bill Beatty for submission details. Thank you.

In 2017, Dr. Peter Rizun noted that Segregated Witness (SegWit) changes the very definition of a Bitcoin as per the whitepaper: “We define an electronic coin as a chain of digital signatures”.

In this article, I would like expand on that topic and add a key observation: breaking the chain of digital signatures is actually removing an integrity check in the Bitcoin ledger.

Bitcoin is a distributed ledger system — a form of database. When it comes to databases in general, there are many different kinds of data integrity. One type,user-defined integrity, refers to a set of rules for a specific application (in this case, Bitcoin).

In Bitcoin, one of the most important types of data are the digital signatures that prove a coin was transferred properly. The fact that signatures cannot be forged is one reason that your coins in storage are safe, even if the network were to undergo a 51% attack.

By defining a coin as a chain of digital signatures (and by implementing Bitcoin to require the signature to be part of the transaction which then gets hashed into the input of the next transaction), Bitcoin establishes an important data integrity check.

To a user, the threat is always that of coins vanishing or being stolen. Bitcoin’s security model ensures that for a coin to move, a corresponding signature has to be produced, and it has to be included in a transaction and published on the blockchain.

Since producing a fake signature is assumed to be hard, no one can steal your coins unless they got a hold of your private keys. When a theft does occur, you can go look at the signature on the blockchain to verify that this is what happened.

This is true for all (non-segwit) coins and transactions in Bitcoin; thus the integrity check is weaved into the fabric of the blockchain, ensuring the security model for all transactions.

How SegWit Removes the Integrity Check

How does the above description change under Segwit? To begin, I’ll quote Dr. Rizun:

“In a Bitcoin, the signatures are an integral part of the chain. Carol can only verify the complete chain of ownership if all the signatures exist because if even a single signature is missing, the chain breaks down…there’s no way to follow it through. A SegWit coin is different because the signatures are all outside of the chain. If even none of the signatures exist, or maybe none of the signatures were even real to begin with, Carol can still validate the chain of custody. I’m using the word custody instead of the chain of ownership, because SegWit really only shows custody.”

So in SegWit, we still have the signature, but it is NOT required to be directly included in the input of the transaction. In fact, it’s explicitly excluded for the purposes of eliminating malleability.

Instead, the signature (“witness data”) is placed elsewhere in its own special section. We still have the data, but what we DON’T have is the data integrity check since it’s not necessary to have the complete transaction (including the signatures) the next time the coin is spent.

How the Security Model Changes Under SegWit

SegWit requires the witness data to be published and committed to the block via a witness root hash. In simple terms, each block must contain a hash value representing the set of signatures for its SegWit transactions.

In both the SegWit and the non-SegWit case, miners are responsible to make sure the signatures are correct before accepting a block. However, with SegWit, the signatures do not directly provide a linkage from one transaction to the next, which is why they are said to be “outside the chain of transactions”.

SegWit supporters justify this structure by pointing out that the consensus rules dictate that miners validate all the signatures, and breaking that model requires a 51% attack.

While that may be true, the security model has undeniably changed. The interwoven integrity check has been discarded and replaced with a complete reliance on miners, rather than having both types of security.

This is akin to wearing a belt AND suspenders for years to make sure your pants never fall down, then one day taking off the belt and proclaiming “I’m still wearing suspenders, what could go wrong?”

How the Threat Model Changes Under SegWit

If we revisit the threat model from the user perspective, what happens in Segwit if your coins go missing? I again give credit to Peter for asking the right question: “can you prove a theft took place?”

In Bitcoin, the signature HAS to be on the chain, and you can look it up on any explorer. Today with SegWit, you can also see the Witness data on an explorer, but what if you didn’t see it?

A user could point to empty witness data on an explorer as evidence, but what if the website made some excuse for its absence and the chain continued anyway? To what lengths does the user have to go to, to convince himself and others of the problem? Philosophically speaking, its impossible to prove the non-existence of something.

Now granted, realistically, its certainly possible that any disappearance of witness data will be a public anomaly that’s just as bad as a miner pretending an invalid signature is valid. Still, the model has changed.

What Are the Real Security Issues?

First, consider the scenario of a miner that fails to publish all the witness data due to a software bug or hardware problem. It might be possible for other miners to accept the block but not all the witness data gets published. If this were ever to happen even once, it would decrease the impact of missing signatures in the future.

Second, what if there someday really is a 51% attack? What if, for whatever reason, 51% of the miners decide to keep building on a block that doesn’t necessarily have all the signatures? In the traditional Bitcoin security model, there has never been any instances of an invalid signature being accepted because the anomaly would be provable.

An actual 51% majority may not even be necessary if Segwit shifts the incentives so that not all the miners are validating the signatures.

What if political pressure is applied to mining pools to steal some funds without a signature? After a certain number of blocks, would other miners capitulate or would the chain split? You could argue that the same thing could happen without SegWit (an invalid signature is accepted as valid), but it seems less likely that this chain would continue.

Concessions

Although I am not pro-SegWit, I want to be as objective and fair as possible and not overstate the problem. In practice, so far, there haven’t been any problems with SegWit that I’m aware of. The signatures are still there, even though the integrity check might not be.

No database design is perfect. There are always trade-offs and some may consider SegWit to be an acceptable trade off, perhaps arguing that Bitcoin has enough redundancy with a large number of archival nodes so that missing witness data is never a problem.

Miners still provide good security, and the threats outlined here might never come to pass.

Contradictions in the Core Roadmap

Segregated Witness is a product of the Bitcoin Core development team and is strongly supported by their followers. Aside from everything written so far, I find there are some “interesting” contradictions in the way they think about things.

I’ll wrap this article up by giving you 2 of them:

1. “Validation”. This is a group that heavily emphasizes the importance of running a full node and “validating everything yourself”. They discourage the SPV security model, and one of the Core developers (Luke Jr) has even said on multiple occasions that if you’re not running a full node, you’re not using Bitcoin. Other BTC supporters rarely if ever contest these statements.

Yet these same people are perfectly ok with tossing out the window the basic assurance that comes from validating each transaction’s signature as a required linkage in the chain. That makes no sense to me.

2. The Role of Miners. This is also a group that loves developers and (non-mining) “full node” operators, but are mistrustful of miners. They have even said that miners don’t get to enforce consensus; that they are only there to “ensure transaction ordering”. Isn’t it funny how they now support a security model that depends on the miners more than ever?

Read the original article on Yours.org.