Quote from: simonbtc on May 01, 2016, 11:53:50 PM

When hashing the transaction data to generate a txid, simply skip over the signature data. Everything else stays the same.

You still must have the block commit to the signature, or otherwise the signatures use in the network can be changed. (e.g. I could go add 200 GB to the size of the chain I give you by adding a megabyte of padding to the signatures in the first 200k blocks). You also need all transaction relay to be changed to be in terms of a new ID which is the hash of the whole transaction, not the txid. (Otherwise I can take a transaction, corrupt the signature, and relay it to everyone fast to block the real transaction from the network.)

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha). But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

Quote from: knightdk on May 01, 2016, 11:56:05 PM

So what happens with transactions that are unconfirmed when that happens? Sure the idea of it sounds simple, but deploying such a hard fork would be a major clusterfuck.

Exactly, thats why we were unable to go forward with the original segwit design that we used in elements alpha: It's nearly impossible to deploy. The improved design is just simply better and a big part of that-- though far from all of it-- is that it's actually deployable.