Quote from: Zarathustra on April 02, 2016, 08:19:34 PM

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.

Quote from: danda on April 02, 2016, 08:20:03 PM

nice writeup. minor nits:

Thanks, I fixed those.

Quote from: franky1 on April 02, 2016, 08:34:12 PM

Quote

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

Quote from: franky1 on April 02, 2016, 08:34:12 PM

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

Quote from: franky1 on April 02, 2016, 08:34:12 PM

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.

Quote from: franky1 on April 02, 2016, 08:34:12 PM

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.

Quote from: franky1 on April 02, 2016, 08:34:12 PM

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.

Quote from: franky1 on April 02, 2016, 08:34:12 PM

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.