Clearing the FUD around segwit

[achow101]

I wrote a post on my website to try to clear up the misunderstandings that people have and spread about Segregated Witness.

http://www.achow101.com/2016/04/Segwit-FUD-Clearup

If you think I missed something or made a mistake, please let me know and I will change it. Feel free to discuss what I have written however I ask that you keep the discussion more technically oriented and less politically.

If you have any additional questions about segwit, I will try to answer them. If I think it is something that many people will ask or misunderstand, I will add it to the post.

Local rule: no posts about blockstream or claims that blockstream controls core development.

*Disclaimer: I am not one of the developers of Segwit although I have done extensive research and am in the process of writing segwit code for Armory.

 

[solex]

@achow101
Always nice to see a clear write-up. Thanks.

I take issue with "A soft fork means that backwards compatibility is maintained."
Soft-forks are designed to create forward compatibility where none existed. Please see my post on this subject.

"Old versions of Bitcoin software will be able to function with no ill effect when a soft fork is deployed" is seriously economical with the truth. Soft-forks silently de-feature existing versions. With SegWit the old nodes cease to be able to do full validation, and ultimately become just glorified SPV wallets. This is definitely an ill-effect. The bigger a soft-fork change the more useless existing software becomes, without the owners' permission!

"Segwit was in fact originally planned as a hard fork, but the developers realized that it could be done as a soft fork and doing so would be safer than a hard fork."
This proves nothing. Anything can be done as a soft-fork including BIP101.

 

[achow101]

> I take issue with "A soft fork means that backwards compatibility is maintained."
Soft-forks are designed to create forward compatibility where none existed. Please see my post on this subject.

Ok, I didn't realize the distinction. I will edit it accordingly once I get back to my other computer.

> "Old versions of Bitcoin software will be able to function with no ill effect when a soft fork is deployed" is seriously economical with the truth. Soft-forks silently de-feature existing versions. With SegWit the old nodes cease to be able to do full validation, and ultimately become just glorified SPV wallets. This is definitely an ill-effect. The bigger a soft-fork change the more useless existing software becomes, without the owners' permission!

True, from security there is an ill effect and it has already been suggested that I fix it (I posted this on bitcointalk and reddit as well).

 

[Peter R]

I feel this write-up is quite biased. Although it clears up some misconceptions, it hand waves away others, and ignores the most significant criticism that I personally have.

Indeed, segwit fixes malleability and changes hashing from O(n^2) to O(n) for large (and very rare) n-byte transactions; however, I do not think many people ever disputed these facts.

It is not true that segwit is simpler in terms of lines of code than BIP109. For that matter, most nodes could simply change a single character (the "1" to a "2" [or better yet an "8"]) in the #define MAX_BLOCK_SIZE 1000000 statement, recompile, and never experience a problem with the Classic HF.

The argument to dispel the myth that "Segwit is kludgy hacked together software that is not ready" is mostly hand-wavy "the-developers-are-awesome" rhetoric instead of links to actual test plans and experimental results. Furthermore, is not placing the Merkle root for the block's witness data in a transaction rather than in the block's header, not a quintessential example of a "kludge" or a "hack"? What about the accounting trick needed to permit more bytes of transactional data per block without a hard-forking change? What would a kludge or a hack look like to you, then? [1]

Finally, the article fails to mention anything about my personal biggest objections to segwit. This objection is the price discount given to the witness data--not by the market--but instead by developers playing the role of Central Planners.

I'll conclude by pointing out that with a hard forking change to a 4MB block size, we could simulateously implement segwit--without either the accounting trick / fee discount or the Merkle-root kludge. Would not this keep basically everyone happy?

[1] Also, wasn't there a recent revelation that to get segwit ready this spring, corners were being cut that would hurt fraud proofs (one of the purported benefits of segwit) [I can't find the link]?

 

[achow101]

> I feel this write-up is quite biased.

I try not to be so I will be including the cons about segwit. The article will be changing and updating.

> It is simply not true that segwit is simpler in terms of lines of code than BIP109. For that matter, most nodes could simply change a single character (the "1" to a "2" [or better yet an "8"]) in the#define MAX_BLOCK_SIZE 1000000 statement, recompile, and never experience a problem with the Classic HF.

You can't just take all of the other changes out of the BIP if you want to support that BIP. To compare them you need to take all of the changes that will happen, including the deployment and other stuff that are a part of BIP109.

> The argument to dispel the myth that "Segwit is kludgy hacked together software that is not ready" is mostly hand-wavy "the-developers-are-awesome" rhetoric instead of links to actual test plans and experimental results

When I was talking about that, I was referring to all of the unit tests that they do and the entire process of ACKing and peer reviewing all of the changes. It isn't something I can link to...

I think the fact that they are on segnet 4 is pretty clear that a lot of testing has been happening and that it is currently being tested.

> Furthermore, is not placing the Merkle root for the block's witness data in a transaction rather than in the block's header, not a quintessential example of a "kludge" or a "hack"?

Okay, I agree, that is a hack.

> What about the accounting trick needed to permit more bytes of transactional data per block without a hard-forking change? What would a kludge or a hack look like to you, then?

The point of that is to maintain compatibility with previous versions. By having to do that to maintain the compatibility, you can then fit more transactions in a block.

> Finally, the article fails to mention anything about my personal biggest objections to segwit. This objection is the price discount given to the witness data--not by the market--but instead by developers playing the role of Central Planners.

yeah, I'm not sure about that. I'm checking it out.

The whole thing about central planning is such BS but that is off topic for this thread.

> I'll conclude by pointing out that with a hard forking change to a 4MB block size, we could simulateously implement segwit--without either the accounting trick / fee discount or the Merkle-root kludge. Would not this keep basically everyone happy?

Probably. Although whether to do a hard fork or soft fork is personal preference and the core devs like soft forks more because they maintain compatibility. Since a hard fork has never been done with the network in its current state, we cannot know how it will go.

 

[cypherdoc]

The point of that is to maintain compatibility with previous versions. By having to do that to maintain the compatibility, you can then fit more transactions in a block.

how do you know for sure? maybe core dev is afraid full node operators disagree with them and will consequently refuse to upgrade. that would be humiliating to them. SF'ing would be a way around that.

The whole thing about central planning is such BS but that is off topic for this thread.

i'm not sure how you can separate out politics from coding since every change in code can be explained by a motive. as far as the decision to impose a 4MB blocksize with a 75% discount you can read my post here. feel free to ignore my political injections and focus on AJTowns explanation of 4MB. there is no reason that the formula can't be a+b<=4MB:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-308#post-11291

Since a hard fork has never been done with the network in its current state, we cannot know how it will go.

i'm not sure why you aren't saying the same thing for the multitude of changes SWSF introduces.
[doublepost=1459654119,1459652983][/doublepost]

"In contrast, a hard fork requires that every single Bitcoin user upgrade their software to support the new consensus rules."

you present a one sided argument. let me quote Jgarzik:

In terms of updates to production software, Segregated Witness pushes complexity up-layer, with a ripple-out impact of changes, from one team (bitcoin core) to many teams out in the ecosystem.

In terms of production planning, SegWit makes work for many more teams beyond core. Miners, exchanges, explorers, wallets and more are much more sensitive to transaction format/signing changes than block size changes.

The logic behind this basket’s pricing is very thin — and again, it is a hazard to insert another point in the code where a developer is setting an arbitrary price ratio.

Hard forks set a higher bar for changing bitcoin’s economic policies — and that’s a good check-and-balance.

https://medium.com/@jgarzik/bitcoin-upgrade-governance-hard-forks-and-segregated-witness-942885e0ce58#.hun3m7wi1

case in point; none of the SPV wallets have to be upgraded with a 2MB HF in contrast to a SWSF.

 

[Peter R]

"Finally, the article fails to mention anything about my personal biggest objections to segwit. This objection is the price discount given to the witness data--not by the market--but instead by developers playing the role of Central Planners."

"yeah, I'm not sure about that. I'm checking it out. The whole thing about central planning is such BS but that is off topic for this thread."

Wait, are you disagreeing that the developers are attempting to set a different price for the witness data than for the other data? This is fact--although Adam Back uses the euphemism that they're "solving an economic bug." What exactly are you saying is BS?

 

[Bloomie]

I am terribly sorry for being off-topic, but if I may quote what OP wrote about this forum in the Bitcointalk version of this thread.

I don't want to post in that cesspool of a forum.

...

I prefer a forum where you can have a semi-intelligent discussion about the merits of the various software proposals instead of a forum where every single person has a bias towards one specific proposal and uses personal attacks and spreads misinformation about other proposals.

You do realize that on Bitcointalk, people who attempt "semi-intelligent discussion about the merits of various software proposals" typically get:

1) Attacked by sociopathic trolls;
2) Personally insulted and called all sorts of names;
3) Have their posts deleted;
4) Banned

Usually in that order, and it's documented all over reddit and other places.

Now compare that to this forum, where people just post about whatever the hell they want and where no one with an opposing view has ever been banned or had their post deleted, EVER.

 

[cypherdoc]

@Bloomie

ah, that explains it. i thought this post by @achow101 smelled trollish.

 

[AdrianX]

It's crazy that real debate can only happen where Point 3 and 4 are guaranteed should you be critical of Blockstream or present an opposing view to the Core sensors.

I think you can add ignored to the list, while Mike and Gavin are clearly independent thinkers there points and criticisms are outright ignored, after points 1 and 2 have failed, and 3 and 4 would be preserved negatively.

 

[freetrader]

For those who would argue that SegWit "solves several important problems at the same time, including transaction malleability and the safety of future script upgrades"

Core developer Eric Lombrozo explains it:

the Bitcoin scripting language does not have too much complexity, but in principle we could have more opcodes now, especially with SegWit it allows us to completely replace the script...

Listen to him at around 19:00 in his interview on Bitcoin Uncensored:

 

[cypherdoc]

When I say that this new SW enabled wide open script versioning system gives core dev a blank check to speak on behalf of all full nodes from here on out, I mean it. Watch Johnson Lau's video presentation again where he gives great graphics using everyday checks to illustrate how transactions get signed in Bitcoin currently and under SW. The scriptprivkey which is defined by the current Forth like script system literally defines how signatures on bitcoin get done. SW proposes to change all of that by allowing your "checks" to go unsigned across the network. Old nodes don't realize this hack so how can it be considered safe and compatible? Just because you call it a SF? Deception runs high.

 

[Zarathustra]

I am terribly sorry for being off-topic, but if I may quote what OP wrote about this forum in the Bitcointalk version of this thread.



You do realize that on Bitcointalk, people who attempt "semi-intelligent discussion about the merits of various software proposals" typically get:

1) Attacked by sociopathic trolls;
2) Personally insulted and called all sorts of names;
3) Have their posts deleted;
4) Banned

Usually in that order, and it's documented all over reddit and other places.

Now compare that to this forum, where people just post about whatever the hell they want and where no one with an opposing view has ever been banned or had their post deleted, EVER.

https://bitcointalk.org/index.php?topic=1423718.msg14403519#msg14403519

 

[achow101]

you present a one sided argument. let me quote Jgarzik:

You're good at taking quotes out of context aren't you?

In terms of updates to production software, Segregated Witness pushes complexity up-layer, with a ripple-out impact of changes, from one team (bitcoin core) to many teams out in the ecosystem.

In terms of production planning, SegWit makes work for many more teams beyond core. Miners, exchanges, explorers, wallets and more are much more sensitive to transaction format/signing changes than block size changes.

This is true, I do not disagree with this. Introducing segwit does require that many more people to a lot more work, and this would be a good reason to not support segwit if it is only supposed to increase capacity. However, it is not just for capacity increases, but rather to also fix transaction malleability. Fixing transaction malleability requires that all wallet developers are going to have to do a lot more work to fix the issue. Even if segwit was a hard fork, developers of all kinds of Bitcoin software would still have to change their code to do so.

Also, they don't have to support segwit because of the forwards and backwards compatibility. Those services could, in theory, not upgrade and not have any major problems.

The logic behind this basket’s pricing is very thin — and again, it is a hazard to insert another point in the code where a developer is setting an arbitrary price ratio.

I'm sure that I agree with that change either, but the point of it is to provide a negative incentive to not bloat the UTXO set. It encourages people to consume UTXOs rather than create them because consuming them is cheaper. (I am assuming this is talking about the whole witness discount thing)

Hard forks set a higher bar for changing bitcoin’s economic policies — and that’s a good check-and-balance.

That is just an opinion (it says so right in the header of that section). It isn't a fact, but people can have their own opinions about whatever they want.

case in point; none of the SPV wallets have to be upgraded with a 2MB HF in contrast to a SWSF.

You don't have to upgrade to still be able to receive and send bitcoin after segwit activates.

SW proposes to change all of that by allowing your "checks" to go unsigned across the network.

Well, no, not really. Old nodes that don't upgrade won't be relaying those transactions because they are seen as non-standard. They only nodes that will be relaying segwit transactions are segwit nodes and those will be relayed with the signatures.

Old nodes don't realize this hack so how can it be considered safe and compatible? Just because you call it a SF? Deception runs high.

It is safe because they reject those transactions for being nonstandard by the old rules but nonstandard transactions are still allowed in blocks so that is the compatibility.

 

[freetrader]

but nonstandard transactions are still allowed in blocks so that is the compatibility.

Pfft.

If a feature degrades the security of older nodes, then I don't really view it as being compatible.

I think that's being disingenuous with the use of the term.

See also: 'safe'.

 

[cypherdoc]

@achow101 So why won't franky1's attack work?

 

[achow101]

@cypherdoc Franky1 is either misunderstanding Bitcoin or I am misunderstanding his attack.

He claims (at least from what I understand) that he could take any currently existing output without owning the private key necessary to spend from it and spend it in a segwit transaction without a signature prior to the fork. After the fork, it would cause a lot of problems if this were possible.

There are a few distinctions to make. There is no such thing as a segwit transaction. Rather there are segwit output types which are spent in a very specific way.

The problem with this attack is that he is not understanding that segwit does not change how current output types must be spent in the input. If you take a random currently existing output such as a p2pkh output, you still will be spending from that output after the fork in the exact same way as before the fork. Segwit does not change that. Therefore, his attack cannot work because he does not own the private keys necessary to spend from such an output.

 

[cypherdoc]

@achow101

yeah, that sounds right. seems to me your response to him should be that an attacking miner cannot self mine an invalid unsigned tx into his block as that would render the entire block invalid.

 

[freetrader]

Am I misunderstanding franky1, or is his attack based on creating an invalid tx which is too deep for the software to revert even after it detects it as invalid (once a node upgrades to SegWit too many blocks have been built on top of this tx)?

What would prevent the invalid block from being built on while SegWit nodes are in a hashing minority?

@cypherdocThe problem with this attack is that he is not understanding that segwit does not change how current output types must be spent in the input. If you take a random currently existing output such as a p2pkh output, you still will be spending from that output after the fork in the exact same way as before the fork. Segwit does not change that. Therefore, his attack cannot work because he does not own the private keys necessary to spend from such an output.

He stated the attacker would later be paying from an address he does control.

Why would this not work if we assume the network refuses to revert a deeply buried invalid tx?

---

And conversely, if we assume that nodes, upon being upgraded to SegWit, will throw away the part of the (already built) chain from the point where they detect the invalid transaction - are we looking potentially at a multi-week rollback? In that case such an invalid tx would have effectively forked the chain...

It's not entirely clear to me why franky1's attack is not a big problem.

 

[achow101]

@freetrader his attack is based on the assumption that such a transaction could be created in the first place. It cannot because he cannot spend outputs he does not own. Segwit does not change that behavior of validating the signatures of p2pkh and p2sh outputs.