Quote from: IadixDev on February 21, 2017, 02:37:34 PM

Quote from: franky1 on February 21, 2017, 02:18:33 PM

Quote from: IadixDev on February 21, 2017, 11:44:32 AM

Quote from: jbreher on February 20, 2017, 04:26:08 PM

No filtering required. When a potentially solved block arrives, spawn a thread to start validating it. When another potentially solved block arrives, spawn another thread to start validating it. First one to validate is the one you build your candidate for the next round atop.

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.

100 blocks?
1000 blocks?

um theres only 20ish pools and the chances of them all having a potential solved block all within the same few seconds is small
at most devs and pools have to worry about is a couple potential blocks competing to be added to the blockheight so dont throw fake doomsdays into a narrative,

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.

im not seeing the big devastating problem your saying dev's should avoid. these days most computers have multiple cores (including raspberry Pi) so if an full node implementation has a '64-bit' release. then automatically you would think devs have already programmed it so that it is already shifts processing resources across the different cores rather than queuing up on a single core.
so the problem and solution should have been solved by just having a 64bit version of a bitcoin full node