[Bitcoin-ml] Can we decide on a roadmap now?

[Tom Zander]

On Saturday, 2 September 2017 21:07:46 CEST Nagai via bitcoin-ml wrote:
> > > Parallel transaction validation
> > Doesn't require any changes in the protocol.
> 
> The transactions in block sorting thing that you just discussed.

There was not much discussion, I found a fatal flaw in the design and 
deadalnix had problems accepting this.

I actually pointed out in this email that we can do massive parallel 
transaction validation with zero changes in the block-structure.

https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-August/
000182.html

It is also useful to note that his idea for changing the transaction order 
had nothing to do with this specific speed optimization. It was a change that 
would solve a problem introduced by his merkle-tree changes.
There were no scaling benefits to any of his hardfork proposals.

> > Similarly, I fail to see any need for this.
> 
> Reason 1)  You think malleability fix is not needed.

I do believe a fix for malleability is needed. I wrote FlexTrans on that 
premise.
I just don't believe one is needed in the next 12 months or so, as there is 
no product nearing completion that is requires a fix on main chain.

A product like Lightning Network can be developed on a testnet with any sort 
of malleability fixes, when it gets closer to being “ready” this priority 
gets higher. But it is madness to push a hard fork that fixes malleability 
while nobody actually needs it.

> Reason 2) You think that no one needs SMF while FlexTrans exists.

Malleability is a known issue since long before mtgox.
Earliest reference I found is May 2011.
https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410

Sure, we have seen some annoyance due to this. But what I just don't 
understand is the strong desire of everyone to come up with their own quick-
fix solution right now. And people pushing for inclusion.

A “Simple Malleability Fix” will still be something that will stay around in 
bitcoin cash validation until the end of time.
If we want to keep things fast and maintainable we minimize that kind of 
hot-fixes. 

The reason I object to a SMF is simply because this is a problem that has 
been known for over 6 years. Everyone in Bitcoin works around it. Yes, it 
should be fixed eventually.
At this point nobody gains by pushing out a quick fix.
Especially since it doesn't actually fix things for all transactions, just 
new transactions.


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel