I 'member.

Keep at it old boy, you're hilarious.

Point of Clarification

The Miners are the ones blocking segwit installation, you know the ones you depend on making new blocks and including transactions and keeping BTC secure.
Those are the guys blocking segwit, the ones your entire BTC network depends on.
Maybe they know more than you do or they just don't care what you think.  

 

FYI:
Combining BU & 8MB & Not Voting , Over 70% is refusing to install segwit.
In a normal race , that is a LandSlide.
What is strange is the pro-segwitters are too stupid to grasp that NO ONE WANTS SEGWIT or LN.  

Larger BlockSizes and keeping the Transactions ONCHAIN is what everyone wants.

Gotcha. How about if spammy looking transactions were filtered by each node when they are first broadcast? I suppose ultimately we'd be working toward prioritizing transactions based on their merits... I also see that it's risky to start judging transactions and dropping them, but perhaps there should be an obligation for the transaction creator to be legitimate and respectful of the limited blockspace? 

I understand that multi-ithreading could open up a can of worms...  It still seems like raising the blocksize would be quite easy, and is the logical way forward. ( inb4 "OH MY GOD HARD FORK....") BTW Synthetic Fork seems like a decent proposal from the Chinese.

Why bitcoin unlimited requires a hard fork? Without hard fork, it is possible to implement? What is the advantages to use BU instead?

That could improve a bit if there few blocks like this. But even if you can work the issue of shared access & deps, then what if there 100 such blocks ? Or 1000 ?

It can maybe just improve the resilience if there is few of them, but it's  just pushing the pb one thread away, and there isnt an infinity of processing power on a computer, even with threads.

Hence the real solution is more on how to avoid wasting processing on those blocks, rather attempting at processing them as long as no better block is validated. Instead of increasing this wasted time on several thread to buffer a bit the excessive processing time.

If there is only a couple of them possibly being processed at the same time, that can help.

But still the goal is to avoid wasting processing time on them, not wasting more of it on multiple thread.

And there can still be this issue on single tx no ? It's not necessarily coming up only with solved blocks ?

And in that case there can still be many degenerate tx with sigops not coming only from the pools.

The thing is i'm also thinking on general blockchain problem, because i'm trying to generalize blockchain stuff with a generic engine, and trying to generalize issue not depending on a particular blockchain topography or other blockchain network specific thing.

Maybe for the current bitcoin configuration that can work, but if you take POS coins for example, where blocks can be sent more easily, or other configuration, it can be more of a problem.

Even if there are multiple core, there is still not an infinity of cores. If there is a finite amount of such block who has to be processed, a finite amount below the number of core, that can be ok.

Otherwise it's just pushing the problem away using more of finite resources.

Optimisation can be seen in differents ways.

Here the concern is resources availabilty. The goal is too keep resources available a maximum, to keep the processing capacity at maximum possible, which include not wasting it on useless computation.

If the solution to maximise capacity in case of useless long block is to monopolize the ressource to check them, it's not really a big win. Ok that remove some of the processing from the main thread, it doesn't mean it's free either, or that those resources could not be used for something more useful.

With the nature of blockchain there will always be some time wasted to invalidate some long stuff, but if the goal is to optimize this, need to find a way to avoid this processing in a way that is shorter than actually validating it. Otherwise it's just pushing the problem away. If there was always some idle core who has nothing better to do than checking useless block, I say ok it's a win, otherwise it's not solving the pb.

With the thread thing it can ceil the waste to the time of longest block, which can maybe be a win in some cases.

lol oh look someone used cores 2017 script buzzword "conservative" (becoming too obvious now)

seriously the script readers need to spend more time reading code and running bitcoin scenario's rather then script reading "recommended by.."

segwit is not a fix. malicious people wont use segwit keys. they will stick to native keys. segwit solves nothing
the real solution is to let nodes flag what they can cope with and then pools see the node consensus and then the pools make their own pool consensus of what they will produce that the nodes can accept.

as for bloat/spam.
a more effective method is to have a real 'priority' formulae that actually solves the problem.
a more effective method is to have tx sigop limits to solve the issues
a more effective method is to not be kissing dev's asses, and think about CODE solutions

Maybe we could activate segwit, implement Schnorr sigs, stop worrying about O(n^2) attacks, and enjoy the other benefits like Lightning, tree multisignature, fungibility, etc.

/common sense