Wednesday, 26 June 2019

A Analysis

Wednesday, 23 December 2015 22:31

One Perspective on Segregated Witness: Love the Feature, Nervous about the Deployment Featured

Written by
Rate this item
(3 votes)

I was recently asked what I thought about Segregated Witness. I am embarrassed to admit that I hadn’t given it much thought. (If you’re not already familiar with it, Bitcoin Magazine has a great introduction to Pieter Wuille’s proposal. For the more technically inclined, I also highly recommend watching Dr. Wuille’s presentation at the Scaling Bitcoin conference.)

Before I continue, the lawyer in me has some disclosures. First, I am not a security expert. Second, I have largely avoided the extensive discussions around the Segregated Witness proposal (except as an occasional lurker). As such, the concerns I have may have already undergone extensive treatment in other venues, most likely by people who are much smarter and much more informed than I am.

Overview: What It Is and How We Get It

Without getting into much detail, the proposal involves separating signatures from transactions and maintaining two separate but related data structures (instead of keeping everything together as is done today). This would allow many participants to cull or ignore certain signature data, which accounts for a large amount of the data in the blockchain. This would benefit scalability and (as a serendepitous side-effect) reduce the likelihood of some double-spend headaches, such as with m-of-n MULTISIG transaction races. This all seems great to me, as far as I understand it.

The next step is addressing the practical problem of how to get participants to abide by the new format and rules. Existing (legacy) participants would have no visibility into the signatures for new transactions, since those would be stored elsewhere, but you don’t want legacy participants rejecting blocks containing new transactions. You’d prefer they validate, but otherwise ignore them. Enter a “clever” hack: create an output format that new participants correctly validate against the new signature data, but one that also validates with the old rules by tricking legacy participants into believing it is spendable by anyone. To mitigate the risk of rogue participants absconding with bitcoins from new transactions, some threshold percentage of miners must agree to support the new transaction format. Once this occurs, new transactions can be included in any subsequent block.1

“In theory, there is no difference between practice and theory. In practice, there is.”
—Jan van de Snepscheut2

This Time Might Be Different

My primary concerns are:

  1. Does an upgrade path that creates transactions that look to legacy participants as if anyone can spend them present unique additional security risks; and
  2. If so, does the proposed deployment strategy sufficiently mitigate that risk?

Motive

I’m not so concerned about participants who value blockchain currencies (miners, parties who pay or receive bitcoins, some speculators, etc.). They already have an incentive to comply. Instead I’ll explore the above questions in the context of those who dislike blockchain currencies (perhaps because such technologies undermine rent extraction, social control, etc.).

Blockchain currencies (and the benefits associated with their adoption) could be set back decades, if people believe they can be “broken”. The details may be unimportant so long as fear of future breakage can be leveraged to marginalize adoption. Breaking a decentralized chain (such as Bitcoin) may persuade would-be adopters to elect privatized blockchain technologies instead. Among many important lessons, Mt. Gox allowed us to glimpse the harmful ripple effects when people lose confidence in any significant part of the ecosystem.3

Means

(Albeit controversial) Fermi-esque estimates of commandeering the blockchain are on the order of US$100-1,000 M. While this may seem like an inconceivable expenditure, it is a rounding error for some nation states that spend such sums in an hour to two or on a single website. It’s also not outside the costs of fraud doing business for some ongoing concerns. Malware exploiting undiscovered vulnerabilities might significantly reduce that figure.

Opportunity?

The deployment strategy associated with the Segregated Witness proposal is one that—as far as I know—is unique in that it contemplates creating transactions that appear to be spendable by anyone using legacy rules. Further, despite theoretical incentives, there appears to be a prisoner’s dillema in spending resources to validate transactions (or at least potentially widespread issue with validation correctness). This means that legitimate participants (including non-miners) can become unwitting coconspirators in an attack. What would an exploit look like? Keep in mind that I am not a security expert, but imagine something like the following:

A well-funded attacker clandestinely develops and deploys malignant miners, possibly leveraging various selfish mining and other techniques, possibly exploiting neighboring miners who don’t validate correctly (or at all), etc., to achieve an effective post-deployment hash rate sufficient to affect outcomes (some people claim this a threshold of 51%, but, depending on the sophistication of the attack and the exploits available, disruption could be achieved with less, perhaps significantly less). At first, the malignant miners appear to the rest of the network as legitimate participants. They claim they will enable new Segregated Witness transactions alongside their benign neighbors for a sufficient number of blocks to achieve the threshold adoption rate. The malignant miners optionally wait until some amount of unspent new transactions are accumulated within the blockchain. At some point after new transactions are enabled, the malignant miners cease to support the feature, and instead mine blocks that spend new transaction outputs as if they are old transactions (i.e., anyone can spend them). Any remaining participants who are not aware of the new transaction format (or don’t properly implement transaction validation) will see these transactions and the blocks that contain them as valid and forward them to their peers. This disruption may be temporary, but if it lasts longer than a few days, it may be enough for the attackers—and even opportunistic third parties—to cause a hangover sufficient to dissuade non-enthusiasts from ever returning to the technology.

Mixed Feelings

I don’t think an attack like that described above is likely, but I don’t think it’s complete fiction either. I’m not creative enough to conceive of optimizations that might make such an attack more practical, more harmful, or both. What I mean to highlight is the risk of trusting miners’ representations about their capabilities or intent. Otherwise benign legacy participants could misinterpret new transactions as spendable (which—as far as I’m aware—has not yet been an issue with previous deployments, certainly not at this potential scale). This could open the door to novel exploits that cause real harm, even if such exploits ultimately only amount to a temporary denial of service. In sum, I like Segregated Witness. I’m somewhat nervous (perhaps unnecessarily) about the proposed deployment. If I shouldn’t be, please don’t hesitate to let me know why. I’d love to be wrong.


1 Such deployments are commonly referred to as “soft forks”. The description above is a substantial oversimplification. The idea is to wait until so many miners play by the new rules that those who don’t must comply or risk having their blocks rejected by the rest of the network (thereby depriving them of precious block rewards). What typically happens is M of the last N blocks mined must come from miners who claim to support the feature. This is done by including a version number in each block associated with that feature. M and N could be, 950 and 1,000, respectively, approximating a 95% adoption rate of recently available mining resources.

2 Well, maybe.

3 We have always agreed that Mt. Gox was an institutional failure, not a technology one. Much like with a traditional bank, customers were required to transfer exclusive possession and control of their assets to Mt. Gox in order to enable the desired services. Customers couldn’t even get copies of the private keys used to manage their accounts. As we have seen with the subsequent popularization of MULTISIG wallets, this was sadly unnecessary. Neverless, the reputational harm to blockchain currencies was real.

Read 1853 times Last modified on Wednesday, 23 December 2015 22:35

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

My Twitter Updates

From Instagram
ReggieMiddleton Sranding in front of an actual African slave dungeon at Cape Coast, Ghana. This is where make African slaves were h… https://t.co/COV3w8vIri
About 14 hours ago
From TweetDeck
ReggieMiddleton VeADIR Changelog 19.06: - Asset details charts timespan selection - Google tag manager - Deep link for trust wallet… https://t.co/kswGwcqi00
Friday, 21 June 2019 08:13
From TweetDeck
ReggieMiddleton @gonbop Whoever wants a true stable asset, that's who! Gold is the original "stablecoin".
Tuesday, 18 June 2019 08:09
From TweetDeck
ReggieMiddleton @tjkuba Absolutely, go buy some KG of gold, in fractions or whole, now https://t.co/ameNSGLjEe
Tuesday, 18 June 2019 08:08
From TweetDeck
ReggieMiddleton Changelog of last VeADIR release. Who's the most powerful DiiFi (Distributed Finance) app in the world? Go see for… https://t.co/4zkJS0POgJ
Tuesday, 18 June 2019 07:41

Right add

Newsletter

Tell Us What You Think

Which forensic research are you most apt to buy?
Right add (2)

Contact

Veritaseum

1-718-407-4751

info@veritaseum.com