Mempool single thread bottleneck has little to do with number of transactions/sec, when one can put as much transactions within the block limit.
Agreed. At least "when one can put as much transactions within the block limit". However, the excuse given repeatedly for not simply increasing the maxblocksize is 'consumer hardware can't handle it, leading to nodes being incapable of being nodes any longer'. This experiment shows this assertion to be false, as fixing the broken concurrency model within the node SW allows a fivefold increase in transaction capacity. Which is well and above the ~1.7x that segwit brings -- in the boundary case that all transactions are segwit.
What mempool multi-threading can help is handling spam transactions much more effectively, leaving mempool in much better state.
This multithreading improvement does not discriminate between 'spam' and other transactions. It provides an improvement in throughput for
all transactions.
your statements about core team where "nobody understands concurrency"
I did not state that core has nobody that understands concurrency. To quote: "Whether core has nobody that understands concurrency, or whether they just deem scalability to be a low priority, is a matter of conjecture." Are there other possibilities I am missing to explain this?
Do you deny the following? If so, which parts?:
But the truth is that the core developers have not:
- measured and published such transaction capacity tests
- determined where the lowest bottleneck in system transaction capacity lies
- coded up a fix to remove the lowest bottleneck to system transaction capacity
- measured and published results with the fix for this lowest bottleneck to system transaction capacity
- All this in a time when system transaction capacity is the hottest issue - and has been for about two years.
are nothing but the FUD you spread about them in order to picture your big block developers somehow "superior".
No. I am not spreading FUD about core devs. I am stating some truths about an area of optimization that core devs have not pursued. An optimization that initial experiments show outperforms segwit, as measured by the single metric of transaction throughput capability, by a wide margin. In order to counter the
actual FUD that 'all capable devs are on in the core camp'.
I certainly made no claim that the Bitcoin Cash devs are superior. I just pointed out one instance where the Bitcoin Cash devs have discovered and prototyped an approach to scalability that seems to me to be far superior to what core devs have so far delivered.
We saw their coding skills few days ago when they failed to execute a proper fork.
No. That was not Bitcoin Cash developers.
What's funny that you said few posts above that you don't want to hurt BTC in any possible way, and few posts latter you talk this nonsense about core devs.
Please tell me specifically what you find in what I posted to be "nonsense about core devs".
You can't lie and at the same time cry you only want the truth, inconsistency is killing you.
Also, please tell me what you find to be a lie. If you find discussion of potential improvements to be detrimental to the progress of bitcoin, it would seem that you would properly be labeled either as reactionary or luddite.
Poll
