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.

[Zarathustra]

The segwit disaster:

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

[danda]

nice writeup.   minor nits:

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 soft fork.

Segwit is a cludgy hacked together and unready software

Better: Segwit is kludgy hacked together software that is not ready.

[franky1]

Segwit deployed as a soft fork is actually safer than a hard fork. A soft fork means that backwards compatibility is maintained. Old versions of Bitcoin software will be able to function with no ill effect when a soft fork is deployed. In contrast, a hard fork requires that every single Bitcoin user upgrade their software to support the new consensus rules. This has the effect of being not backwards compatible and thus forcing users to upgrade to the latest version or risk being kicked off of the Bitcoin network.

change to

Segwit deployed as a soft fork is sometimes safer than a hard fork. A soft fork means that backwards compatibility can still function even if they no longer know what they are processing. Old versions of Bitcoin software will be able to function but without fully checking new features when a soft fork is deployed.

In contrast, a hard fork and softfork both require that every single Bitcoin user upgrade their software to support the new consensus rules, but softforks can still function by just confusing the old clients into not bothering to check what they are processing, making the old node no longer full nodes. but 'compatible nodes'

the danger is that the majority do not upgrade because they have been lied to saying that there is not a problem, and basically passing a blind parcel of data around the network that they dont check.

hard forks with a small priority grace period to kick peoples ass into action can be safer. because by upgrading you regain full node status, and by making it a short priority grace period you wont run into the issues of lazy people avoiding the upgrade because they stupidly think there is no reason to do it straight away.

The other difference is whether to include the witness data in the block size count, and to maintain backwards compatibility while also having the capacity increase, it was decided to not do so.

change to
The other difference is whether to include the witness data in the block size count, and to maintain backwards compatibility while also having the capacity increase, it was decided to not do so. meaning the point of the maxblocksize variable becomes useless because physical data will no longer be 1mb, but more

PS.
if you think the above is Fud. then i dare you to stick with 0.8 for the rest of your life and try to claim that you are still a full node. and pretend that for the next year every real data hitting your hard drive will continue to be less than 1mb.

please try not to play down the risks like a biased fanboy, pretending the world is made of candy floss clouds and everything is perfect.

[achow101]

The segwit disaster:

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

Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum.

nice writeup.   minor nits:

Thanks, I fixed those.

Segwit deployed as a soft fork is actually safer than a hard fork. A soft fork means that backwards compatibility is maintained. Old versions of Bitcoin software will be able to function with no ill effect when a soft fork is deployed. In contrast, a hard fork requires that every single Bitcoin user upgrade their software to support the new consensus rules. This has the effect of being not backwards compatible and thus forcing users to upgrade to the latest version or risk being kicked off of the Bitcoin network.

change to

No (okay, maybe like three words of what you said I might include).

Segwit deployed as a soft fork is sometimes safer than a hard fork. A soft fork means that backwards compatibility can still function even if they no longer know what they are processing. Old versions of Bitcoin software will be able to function but without fully checking new features when a soft fork is deployed.

In contrast, a hard fork and softfork both require that every single Bitcoin user upgrade their software to support the new consensus rules, but softforks can still function by just confusing the old clients into not bothering to check what they are processing, making the old node no longer full nodes. but 'compatible nodes'

I agree that they are just "compatible nodes".

the danger is that the majority do not upgrade because they have been lied to saying that there is not a problem, and basically passing a blind parcel of data around the network that they dont check.

Not true. The standardness rules says that anyonecanspend outputs are non-standard and are thus not relayed. Thus non-upgraded nodes will consider segwit transactions as non-standard and refure to relay them. However, when it sees that the transactions are in a block, it will still be able to validate the block and accept it even though it contains non-standard transactions.

change to
The other difference is whether to include the witness data in the block size count, and to maintain backwards compatibility while also having the capacity increase, it was decided to not do so. meaning the point of the maxblocksize variable becomes useless because physical data will no longer be 1mb, but more

The physical data will be more than 1 Mb for segwit capable nodes. This has never been claimed otherwise.

PS.
if you think the above is Fud. then i dare you to stick with 0.8 for the rest of your life and try to claim that you are still a full node. and pretend that for the next year every real data hitting your hard drive will continue to be less than 1mb.

The real data hitting the hard drive will be less than 1 Mb for a non-segwit capable node. Because it doesn't have the NODE_WITNESS service bit set, then it will not receive blocks and transactions with the witness serialization format. The data in the normal transaction format will still be less than 1 Mb.

please try not to play down the risks like a biased fanboy, pretending the world is made of candy floss clouds and everything is perfect.

You should do the same with playing up the benefits of hard forks.

[franky1]

it will still be able to validate the block and accept it even though it contains non-standard transactions.

= blindly accepting a block that contains data it cannot verify..

can you atleast wear your impartial hat for 1 minute to see how this can be abused..
EG someone makes a nonstandard tx to pay themselves alot of bitcoins and gets it added to pool that wont check it.
(yes its possible to push tx to pools you know of directly..)

please just take off the fanboy hat for 1 minute. and put on the sceptical, impartial, bug finding, risk analysing hat.. just once

[achow101]

it will still be able to validate the block and accept it even though it contains non-standard transactions.

= blindly accepting a block that contains data it cannot verify..

can you not atleast wear your impartial hat for 1 minute to see how this can be abused..
EG someone makes a nonstandard tx to pay themselves alot of bitcoins and gets it added to pool that wont check it.

please just take off the fanboy hat for 1 minute. and put on the sceptical, impartial, bug finding, risk analysing hat.. just once

Sure. This is my impartial view of various scenarios that could attempt to exploit this (also the impartial view that I try to post with).

Scenario 1:
A malicious node (not a miner) creates a transaction that is invalid under segwit rules but valid under old rules and broadcasts it to the network.

Result:
Non-upgraded nodes see the transaction and label it non-standard. They don't relay it and reject it. Segwit nodes see the transaction and they find it invalid. They don't relay it and reject it. Segwit miners do the same as the segwit nodes and the transaction is never included into the blockchain.

Scenario 2:
A malcious miner creates a transaction that is invalid under segwit rules but valid under old rules and includes it into a block he mines.

Result:
A non-upgraded node would validate the block and accept it because it is valid under the old rules. The segwit nodes and miners would see it and reject it because it includes an invalid transaction. If we assume that the segwit miners have a majority of the hash power (as it should be when segwit is deployed with a 95% threshold), then the malicious miner cannot keep up with the network and produce a longer blockchain. The rest of the miners would produce blocks that orphan the invalid one and non-upgraded nodes would go back to the correct blockchain after it grows longer than the malicious one.

If we assume that the malicious miner has a majority of the has power, then we have ourselves a 51% attack which we all know is a problem by itself. This attack is made worse since the old nodes could be tricked to believe that those malicious transactions are legit and that miner can basically trick that part of the network into thinking the miner has more money than he actually does.


Short of a 51% attack, I don't see a problem. Do you have any other scenarios you want me to examine?

[franky1]

Scenario 2:
A malcious miner creates a transaction that is invalid under segwit rules but valid under old rules and includes it into a block he mines.

Result:
A non-upgraded node would validate the block and accept it because it is valid under the old rules. The segwit nodes and miners would see it and reject it because it includes an invalid transaction. If we assume that the segwit miners have a majority of the hash power (as it should be when segwit is deployed with a 95% threshold), then the malicious miner cannot keep up with the network and produce a longer blockchain. The rest of the miners would produce blocks that orphan the invalid one and non-upgraded nodes would go back to the correct blockchain after it grows longer than the malicious one.

If we assume that the malicious miner has a majority of the has power, then we have ourselves a 51% attack which we all know is a problem by itself. This attack is made worse since the old nodes could be tricked to believe that those malicious transactions are legit and that miner can basically trick that part of the network into thinking the miner has more money than he actually does.


Short of a 51% attack, I don't see a problem. Do you have any other scenarios you want me to examine?

ur assuming a pool cannot made a funky segwit without 95%.. if it was impossible.. then that blows apart your whole argument about backward compatibility accepting segwit.

so lets assume a pool got the code on day one and made a funky tx, added it to a block before any of the other pools upgraded. they would treat it as a valid block with a funky tx that they just blindly pass on.

EG lets say segwit is not publicly released for 2 weeks. but a pool grabbed the code from testnet today and made loads of transactions in their pools paying themselves. knowing they have 2 weeks of never being checked

hash power doesnt even come into the argument

[amaclin]

What do you think about the using of segwit?
Let me explain.
Today almost nobody cares about the transaction size and the fees.
What will force the users like casino, exchanges, doublers, etc to abadon their currens software which accepts p2pkh addresses and move to segwit addresses?

[franky1]

What do you think about the using of segwit?
Let me explain.
Today almost nobody cares about the transaction size and the fees.
What will force the users like casino, exchanges, doublers, etc to abadon their currens software which accepts p2pkh addresses and move to segwit addresses?

exactly. its being falsely told that upgrading is not a priority and you can happily stay with old versions.... basically making yourself more impotent due to pure ignorance and lack of true information.

a hard fork with a short grace period emphasizes the priority and gets people to upgrade. its happened atleast 3 times before where loads of nodes upgraded in hours... its not a big deal to implement. if you highlight the priority of implementation

[achow101]

ur assuming a pool cannot made a funky segwit without 95%.. if it was impossible.. then that blows apart your whole argument about backward compatibility accepting segwit.

so lets assume a pool got the code on day one and made a funky tx, added it to a block before any of the other pools upgraded. they would treat it as a valid block with a funky tx that they just blindly pass on.

EG lets say segwit is not publicly released for 2 weeks. but a pool grabbed the code from testnet today and made loads of transactions in their pools paying themselves. knowing they have 2 weeks of never being checked

hash power doesnt even come into the argument

Clearly you don't know how segwit works. A segwit output is understood by old nodes as an anyonecanspend outputs. Spending a segwit output has a blank script sig and this is valid because the stack is not 0. So if anyone were to create a segwit transaction now, anyone could spend from the output. Segwit does not allow people to spend from normal p2pkh or p2sh outputs in a special way, they still have to spend from them in the old way. The change of segwit is the new output types and spending from those output types requires an empty script sig and a witness. I suggest that you read the BIPs for the full technical description of segwit and you should really understand how it works. I linked them in the bottom of the blog post.

What do you think about the using of segwit?
Let me explain.
Today almost nobody cares about the transaction size and the fees.
What will force the users like casino, exchanges, doublers, etc to abadon their currens software which accepts p2pkh addresses and move to segwit addresses?

The fees are lower. I'm pretty sure a lot of people care about the fees, especially if you are making many transactions. Those fees do add up. Since the size of the transaction that goes towards the block size count is less, the fees will thus be lower and that incentivises people to use segwit.

[franky1]

ur assuming a pool cannot made a funky segwit without 95%.. if it was impossible.. then that blows apart your whole argument about backward compatibility accepting segwit.

so lets assume a pool got the code on day one and made a funky tx, added it to a block before any of the other pools upgraded. they would treat it as a valid block with a funky tx that they just blindly pass on.

EG lets say segwit is not publicly released for 2 weeks. but a pool grabbed the code from testnet today and made loads of transactions in their pools paying themselves. knowing they have 2 weeks of never being checked

hash power doesnt even come into the argument

Clearly you don't know how segwit works. A segwit output is understood by old nodes as an anyonecanspend outputs. Spending a segwit output has a blank script sig and this is valid because the stack is not 0. So if anyone were to create a segwit transaction now, anyone could spend from the output. Segwit does not allow people to spend from normal p2pkh or p2sh outputs in a special way, they still have to spend from them in the old way. The change of segwit is the new output types and spending from those output types requires an empty script sig and a witness. I suggest that you read the BIPs for the full technical description of segwit and you should really understand how it works. I linked them in the bottom of the blog post.

i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves..  to talk about a different scenario about spending later....

because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.

only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..

as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.

[achow101]

i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves..  to talk about a different scenario about spending later....

because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.

only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..

as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.

Sorry, but I still don't understand your scenario. Can you describe it more specifically with reference to the output type that was used in the outputs?

[Zarathustra]

The segwit disaster:

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

Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum.

You seem to prefer a theymos ruled forum over an uncensored one. No surprise.

[franky1]

i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves..  to talk about a different scenario about spending later....

because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.

only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..

as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.

Sorry, but I still don't understand your scenario. Can you describe it more specifically with reference to the output type that was used in the outputs?

1. malicious pool makes a segwit transaction to pay themselves lots of coins. from an address they dont own to an address they do own. BUT. because its 2 weeks before anyone else has segwit, it appears to others as a funky transaction. in a block.. so they blindly accept it as a block with funky transaction.

2. so now the receiving addresses is technically classed as having lots of funds.. but no one can spend them as they dont have the keys to do so. so the transaction is locked in the block unspendable becuse although people can try making an anyone can spend, it wont be accepted into other blocks as its not technically an anyone can spend..

3. weeks later when the malicious block has over 2000 confirmations. the owner of the privkey that received the funds can then move them because segwit is now live and segwit pools will see that the transaction is spending funds with 2000 confirmations(even though the tx before that is technically invalid)

[johnyj]

The biggest property of segwit is that the more you talk about it, the more FUD you get  

If changing 1 to 2 require 18 months of talk, then changing several thousand lines would require many decades of talk if not centuries

[achow101]

The segwit disaster:

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

Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum.

You seem to prefer a theymos ruled forum over an uncensored one. No surprise.

No, 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. Also, that thread is really freaking long and I don't want to read it and attempt to debunk all of the false information in one post.

1. malicious pool makes a segwit transaction to pay themselves lots of coins. from an address they dont own to an address they do own. BUT. because its 2 weeks before anyone else has segwit, it appears to others as a funky transaction. in a block.. so they blindly accept it as a block with funky transaction.

This is simply not possible. Anyonecanspend is an output type, not an input type. It is not possible to spend from addresses (from now on I will refer to them as p2pkh and p2sh outputs) that you don't own the private keys for. If it were an anyonecanspend output (like an actual one or one in segwit format) then, as the name of the output suggests, anyone could spend from that output legitimately and create whatever outputs they want.

2. so now the receiving addresses is technically classed as having lots of funds.. but no one can spend them as they dont have the keys to do so. so the transaction is locked in the block unspendable becuse although people can try making an anyone can spend, it wont be accepted into other blocks as its not technically an anyone can spend..

I don't see how that would even be the case. A segwit output would be able to be spent by everyone before segwit's activation because it is anyonecanspend.

3. weeks later when the malicious block has over 2000 confirmations. the owner of the privkey that received the funds can then move them because segwit is now live and segwit pools will see that the transaction is spending funds with 2000 confirmations(even though the tx before that is technically invalid)

See above.

[Zarathustra]

The segwit disaster:

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

Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum.

You seem to prefer a theymos ruled forum over an uncensored one. No surprise.

No, 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. Also, that thread is really freaking long and I don't want to read it and attempt to debunk all of the false information in one post.

LOL. You drive a personal attack against 'every single person' there by accusing all of them of using personal attacks. You are a joke.

[franky1]

fail

you do realise that its not actually an anyonecanspend script. and as soon as someone without segwit tried to spend it in an anyonecanspend.. it wont get accepted by legit ethical pools...

for instance. lets assume that i knew someone else made a segwit next month. and i knew of 1 pool that had not upgraded. by saying that old clients can spend segwit. means that i can push the transaction to an old pool and spend someone segwit..

it is said it is LIKE an anyonecanspend and treated as an an anyonecanspend, for the sole laymen purpose and analogy purpose of a node not understanding what it is and blindly passing it on.. not because it actually is an anyonecanspend. otherwise thats another way of breaking bitcoin.. by old clients spending segwit transactions.(which u think is possible)

only a malicious miner can bend their rules and accept a malicious transaction into their block, to be treated as funky by everyone else blindly accepting it as funky. but if USERS tries to make a transaction and pushed it to a pool. unless the pool was malicious and wanted strangers to spend their previous tx, then it wouldnt get in a new block. so people cant spend the funky tx...

this is why i have used the word funky instead of anyonecanspend. because the anyonecanspend was for analogical reasons not technical

my scenario is about the block creation by a malicious pool. not the user creating transactions (which pools would dump)

[achow101]

you do realise that its not actually an anyonecanspend script. and as soon as someone without segwit tried to spend it in an anyonecanspend.. it wont get accepted by legit ethical pools...

Yes, I know. Maybe I wasn't clear, but I meant BEFORE segwit's deployment. Right now, you can create a transaction that has a segwit output. Right now that output is an anyonecanspend output.

Pools would not accept an attempt to spend a segwit output as anyonecanspend AFTER segwit's deployment.

blindly passing it on..

They do not blindly pass on segwit transactions because those are considered non-standard and thus rejected.

not because it actually is an anyonecanspend. otherwise thats another way of breaking bitcoin.. by old clients spending segwit transactions.(which u think is possible)

See above.

only a malicious miner can bend their rules and accept a malicious transaction into their block, to be treated as funky by everyone else blindly accepting it as funky. but if USERS tries to make a transaction and pushed it to a pool. unless the pool was malicious and wanted strangers to spend their previous tx, then it wouldnt get in a new block. so people cant spend the funky tx...

AFTER segwit's activation, such malicious transactions spending segwit outputs as anyonecanspend are invalid.

this is why i have used the word funky instead of anyonecanspend. because the anyonecanspend was for analogical reasons not technical

Anyonecanspend is technical, not analogical. An OLD node validates segwit outputs as anyonecanspend because under the old rules they are anyonecanspend.

my scenario is about the block creation by a malicious pool. not the user creating transactions (which pools would dump)

Miners won't mine an an invalid block.