Quote from: franky1 on April 03, 2016, 12:28:57 PM

Quote from: knightdk on April 03, 2016, 04:36:04 AM

What about a segwit transaction would make it so that he can ignore the signatures? Why would he be able to spend from an input he does not own? 1

The input does not dictate how the output is spent, the output does. 2

If the output says that it needs a signature in the scriptsig (e.g. a p2pkh output), then it needs a signature in the scriptsig regardless of segwit activation. 3

1. because the block was made before other pools had segwit.. so they would blindly accept the block containing the funky transaction!!!!!!!!!
again. the malicious transaction would be put into a block by a malicious pool BEFORE others had segwit. knowing that old nodes would blindly not care about it because they dont understand it and wont check for signatures because they cant see the witness(signature) area

2. exactly.. the initial transaction in the malicious block has NO signed input. but is not checked because its a funky tx.

3. all the scriptsig crap is stored OUTSIDE of the tx, in the witness area.. old clients wont see it and blindly accept it without a signature.. thats the whole point of segwit.

now when a second transaction is made later it is grabbing the OUTPUT of the first transaction (not the input) which basically says 1MaliciouspoolAddress gets the coin. and uses the OUTPUT as an input for the second transaction.. and signs for it normally. because the pool owns the key for 1MaliciouspoolAddress and the confirmed block is saying that 1MaliciouspoolAddress now owns coins thanks to the funky tx before segwit

You do present a valid flaw of a hypothetical one-time remotely possible transaction that may or may not exist. Do you have a solution that does not involve a hard fork? Because I am sure a hard fork also has many more hypothetical flaws.