Post
Topic
Board Bitcoin Discussion
Re: Clearing the FUD around segwit
by
franky1
on 02/04/2016, 21:14:45 UTC

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