Quote from: achow101 on March 13, 2017, 01:19:55 PM

Quote from: AliceWonderMiscreations on March 13, 2017, 07:58:29 AM

Seriously - I think what happened is when SegWit was developed, it was developed with the design constrain that it must be doable with a soft fork and that is why it became overly complex.

Segwit was originally developed as a hard fork. It only became a soft fork after luke-jr figured out that the way it was as a hard fork could be fairly trivially done as a soft fork.

Can you please explain how Segwit is more complex than FlexTrans (with specific details about the proposal, not just hand wavy analogies)? I don't think it is more complex, in fact, I think it is simpler than FlexTrans as everything in the transaction is in a known location, you don't need to go searching for tags.

Quote from: tomtomtom7 on March 13, 2017, 09:51:53 AM

To prevent a false dichotomy, I would like to note that Christian Decker's BIP 140 (https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki) also fixes maleability.

In my opinion in better way then both FlexTrans and SegWit.

BIP140 does not do as much as Segwit or FlexTrans does.

SegWit splits the TX into two parts, to try and keep compatibility with old transactions instead of just using a new version number. It does this by subtly changing the meaning of the fields so that older clients think they are validating the transaction but they really are not, rather than just knowing that they aren't capable of properly validating that transaction version. Specifying a new version number for the transaction lets you be honest with old clients and you can't possibly make the mistake of misinterpreting the context (SegWit or not) resulting in application of the wrong interpretation to the field. Miners who don't upgrade can validate a transaction that is not actually valid because of this segregation. This can result in orphans because a transaction that would be valid if SegWit simply didn't exist is not valid in the context of SegWit, so bugs in detection of the context can result in confirmations that shouldn't confirm yet follow the old rules.

By using a tag based system, FlexTrans allows you to skip fields that are not used in the transaction, simplifying most transactions as you do not have to parse and interpret fields that that are not there. This also makes the transactions smaller (and thus cheaper) than SegWit transactions. A prime example of this is script version. FlexTrans provides for script version, but you don't actually have to use it until there is a new version and you need to specify that new version. SegWit requires every transaction to have a byte specifying the script version even though there presently is only one version. Currently every SegWit transaction wastes a byte.

The tagged structure of FlexTrans makes it easier to extend in the future, just add new tags, which will work just fine with soft forks because old clients will simply ignore any tags they don't support, just like we can use html tags and attributes that some browsers don't support. Just like we often do with JSON APIs - adding new fields that older clients can just ignore so they don't break because we added some new feature.

SegWit works by moving data into the coinbase which really isn't what the coinbase is for. That's a hack, that's not simplicity, it always complexity when you re-appropriate like that.

A tag-based transaction, btw, gets rid of the need to modify the meaning of fields or do hacks like the signatures in coinbase hack. You simply add new fields. Simple Elegance.

Additionally, because of the coinbase hack, SegWit requires an additional merkle-tree, FlexTrans does not.