Quote from: johnyj on April 03, 2016, 05:24:21 AM

I think I understand Franky1's sense of security here, let me make a simpler example:

As soon as segwit code is out, some malicious miner create an illegal segwit transaction and mined it into a old style block, for example block 420001. All the old nodes will accept this block since they can not verify if the transaction is correct. So this block containing illegal segwit transaction will be berried deep down until the day segwit activates, lets say 425000

After segwit activation, all segwit nodes detected this illegal transaction (because they could not find the witness part at all) and illegal blocks, they have to abandon all the blocks after this block and build from block 420001, since that is the latest block they consider to be valid, so network split into two chains from 420000 and all the transactions after 420001 disappear in segwit nodes after the activation

Your right, SegWit might not be backward compatible if some pool today add 2 tansactions to the block today: Send bitcoin to SegWit address anyone can spend and spend it in second transaction without the signature to normal address. Because witness part where the signatures are stored does not exist today, this SegWit transaction wont be backward compatible after SegWit is activated. This means SegWit transaction signatures has to be just validated only after SegWit activation, so no need to make the block created today invalid if it contains SegWit transaction without the signature in witness part (which does not exist)

Quote from: johnyj on April 03, 2016, 04:16:05 AM

Quote from: knightdk on April 03, 2016, 03:00:38 AM

Quote from: johnyj on April 03, 2016, 02:23:18 AM

Quote from: knightdk on April 03, 2016, 01:37:08 AM

The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output

So the security is to make sure this output can never be spent by old nodes, how can you be sure of that?

Suppose two pools with 60% hash rate, and they are sitting on the side line watching the mined blocks, once 35% of blocks are mined as segwit support, they switch to mine segwit blocks and activate it, then there will be many segwit transactions out there, and then they switch back to original software

Now network are full of anyonecanspend transactions that is free for them to grab, and they have 60% of hash power so their chain become the longest, since majority of the nodes are still old style nodes (as in soft fork you don't need nodes to upgrade), these nodes will build on their chain, and the rest of the segwit nodes will fork into a minority chain since now they reject old style blocks

So it is a mess after this accident, all the people who used segwit transaction will lose their money and they don't even understand what happened

Nope. It's all in the deployment. There is a lock in period (grace period) before the rules go in effect. See BIP 9: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki for how the deployment actually works because they will be using versionbits.

Notice the activation happens after the grace period. What prevent miners from switching back to original version after the activation? If there are so many anyonecanspend transactions to grab. You must collude with miners, so that is the problem with segwit, without miners cooperate, this system will fail, and bitcoin by design should not need devs to collude with miners to implement a change, that is too large degree of central planning

Even if you can collude with miners, in case the segwit upgrade failed, e.g. lots of security problem in live traffic after the activation, because of these anyonecanspend transactions, miners can not roll back to old version, since all these transactions will be spendable if they revert. In that case bitcoin is dead either way: Keep running segwit, customer losing money, roll back, customer losing money

It is important to understand SegWit should be used only for low value transactions, because softfork rules can be changed anytime with 51% of hashpower and future block versions might not use SegWit withness data to check signatures anymore, so really anyone could spend SegWit transactions.

But you should be not surprised because you dont require the signature to be used to spend Bitcoins from SegWit transaction given today Bitcoin consensus rules (which requires hardfork to change) - so keep SegWit only to low valued transactions should be reccomended.

And indeed if SegWit transactions become used for high value transactions then if miners become unprofitable with lowering block rewards, they may use the hashpower to softwork again and get the SegWit transactions themselves legitimately (from anyone fool enought to send anyone can spend transactions by Bitcoin consensus rules).