Good work, that explains it. You may also wish to decrease the time interval as well since transactions change so frequently. I noticed a long time ago when proxying to p2pool that stratum updates were few and far between. I suggest 60 seconds instead of 10 minutes... The stratum specification says it should be under 90 seconds IIRC.

Dear users mikesw, phongnui, orionberry and cobramining, you are still trying to log in with a regular username instead of a bitcoin address. Your username MUST be a valid bitcoin address to be able to mine here. Note that I've blocked a few IP addresses that are using invalid usernames. If you have confirmed that you have a correct username and are still having trouble connecting, message me your IP address and I'll unblock it.

All DE miners have been migrated to the new server seamlessly; it appears no miners were lost or had any downtime in the transfer. The new server is substantially more powerful than the old one, with equivalent performance to the main solo pool. Miners will not notice any difference, but this is to further minimise block change latencies and risk of orphans being produced. Additionally this server has DDoS protection as the main pool server does. You may wish to check your ping times since it's in a slightly different location, though they should be very respectable if you're in or near DE.

You can run the bitcoin core software in "pruned" mode which will take up no more than 2GB and it will still propagate transactions. If you are confusing terminology and thinking about "mining" and not "processing transactions" which is designed to make you money from bitcoin block generation, then no - you cannot meaningfully use an ordinary CPU to do bitcoin mining; it is all done with specialised hardware these days called ASICs.

Try:
https://www.viabtc.com/tools/txaccelerator/

This doesn't alter what's going on inside p2pool that mines an empty block (whatever that is). Perhaps the merged mining is the culprit... that almost certainly causes far more losses than any gains people think mining bullshit worthless coins might have. At 5-10% more reward due to transactions currently,  one really should try and mine transaction containing blocks as much as possible.

Because of the way the soft fork works, unless a consensus is reached, the other nodes will simply reject all those blocks as invalid until the 95% is reached, so if a miner mines segwit blocks they end up being seen as invalid by all the other nodes and all the mining work is wasted. Once another 2 blocks are mined elsewhere on the network, even the miner's node will switch to the non-segwit mined blocks.

It's in the p2pool code itself. If I recall correctly I believe a bug report was made a long time ago but the cause never found and a fix never committed.

And at a time when fees are potentially up to 2BTC 

That's nonsense; the two are unrelated.


There are many many threads on the forum about empty blocks. Search and you will find your answers. It has been answered thousands of times before.

https://bitcointalk.org/index.php?topic=1085800.0

You can't "redirect" a block; it is found at a particular address and can't be changed.

Lauda your tolerance and persistence is commendable. However your effort is wasted. Selectively ignoring about 4 bitcointalk trolls in this argument will make your life much more enjoyable and any discussions regarding scaling much more useful as it increases the signal to noise ratio to about 100x higher.
EDIT: Of course people who respond by taking offence means they know they're trolls themselves, otherwise why would they get offended and think I was talking about them?

Marketing bullshitspeak is the reason.

That would have zero effect. The transactions are INCLUDED IN THE BLOCK so if anything, ignoring the transactions in the first place means the node has to request them from the other node that sent it the block.

Now if you're talking about local block generation mining, bitcoind already does extensive ordering of transactions putting spammy transactions ultra low priority and likely not even stored in the mempool, so there's little room to move there. Filtering can always be improved but the problem isn't local block generation but block propagation of a intensely slow to validate block.

On the client software side with cgminer it would be over 95% with what hardware is currently out there and knowing what is embedded on most of it. At the pool server end with ckpool it's probably less than 5% at present.

I'd be happy to write a new client with emphasis purely on performance and scalability from scratch... if someone wanted to throw large sums of money at me to do so and keep sending me more indefinitely to maintain and update it.

You missed the point of my original response entirely then - you CAN'T spawn a thread to validate it because of the locking I said before. If you spawn a thread to validate the block, nothing else can do anything in the meantime anyway - you can't process transactions, you can't validate other blocks. This is, again, a limitation of the code rather than a protocol problem but it would take a massive rewrite to get around this.

This is a block and the transactions it contains we're talking about, not a simply broadcast transaction, and we don't want to start filtering possibly valid blocks...

Nice to see the preciousblock feature. I assume you submit your block and then send the preciousblock message?

It is a bit too harsh. While I'm continually frustrated by some of the limitations of the bitcoind client and the lack of emphasis on things that I am concerned about (since mining with it is my personal interest), it does not pay credence to how such code realistically evolves and the difficulties of keeping massive rewrites safely in check while evolving the client in multiple directions. I'm not much of a c++ coder myself so I can't do anything much to help but at least I do understand what's involved in maintaining such a massive project. It is impossible to know what issues will become problematic in the future when first starting a project; they only become apparent as it evolves and need to be tackled in a methodical manner. Emphasis has only been placed on speed of block processing, propagation, and work template generation in recent times and the improvement is already substantial but has a very long way to go. If the client was written from the ground up now with emphasis in those areas, knowing what we already do now know, it would no doubt look very different. Some things, though, are protocol limitations and not the client. Things like the quadratic scaling issue are in the current bitcoin protocol design and no amount of client rewrites without a protocol change will get around that. I'm not arguing for one only. Both need to be addressed.