Introducing Flexible Transactions. Does SegWit benefit from a Hardfork?

[TomZ]

I've been asked one question quite regularly and recently with more force.
The question is about Segregated Witness and specifically what a hard
fork based version would look like.

Segregated Witness (or SegWit for short) is complex. It tries to solve
quite a lot of completely different and not related issues and it tries to
do this in a backwards compatible manner. Not a small feat!

So, what exactly does SegWit try to solve? We can find info of that in the
benefits document.

• * Malleability Fixes
  * Linear scaling of sighash operations
  * Signing of input values
  * Increased security for multisig via pay-to-script-hash (P2SH)
  * Script versioning
  * Reducing UTXO growth
  * Compact fraud proofs

As mentioned above, SegWit tries to solve these problems in a backwards
compatible way. This requirement is there only because the authors of
SegWit set themselves this requirement. They set this because they wished
to use a softfork to roll out this protocol upgrade.
This post is going to attempt to answer the question if that is indeed
the best way of solving these problems.

Full post at;

http://zander.github.io/posts/Flexible_Transactions/

[iFixBTCmemoryIssues]

I've been asked one question quite regularly and recently with more force.
The question is about Segregated Witness and specifically what a hard
fork based version would look like.

Segregated Witness (or SegWit for short) is complex. It tries to solve
quite a lot of completely different and not related issues and it tries to
do this in a backwards compatible manner. Not a small feat!

So, what exactly does SegWit try to solve? We can find info of that in the
benefits document.

• * Malleability Fixes
  * Linear scaling of sighash operations
  * Signing of input values
  * Increased security for multisig via pay-to-script-hash (P2SH)
  * Script versioning
  * Reducing UTXO growth
  * Compact fraud proofs

As mentioned above, SegWit tries to solve these problems in a backwards
compatible way. This requirement is there only because the authors of
SegWit set themselves this requirement. They set this because they wished
to use a softfork to roll out this protocol upgrade.
This post is going to attempt to answer the question if that is indeed
the best way of solving these problems.

Full post at;

http://zander.github.io/posts/Flexible_Transactions/

I, nor my clients, will run any software with Segwit code.

Can you write code for the malleability fixes with-out directly using any Segwit code? I see an idea, I take what I need and voila.

[TomZ]

I, nor my clients, will run any software with Segwit code.

Can you write code for the malleability fixes with-out directly using any Segwit code? I see an idea, I take what I need and voila.

Well, someone needs to write the code first, but, yes, you can fix the malleability problems without using SegWit. You can make Lightning work on top of Bitcoin based on this proposal without issues, as far as I can tell.