getblocktemplate is trash can a bitcoin dev actually write a good one? #6525

The original commit for getblocktemplate was not much more than a rewrite of getmemorypool in terms of code logic (and also it immediately deprecated a working in use getmemorypool - I've no idea why the proper process for handling version control was ignored there ...)

The person who's name is on the commit also bypasses using getblocktemplate for block changes on his pool because getblocktemplate is too slow. That's a pretty telling fact. ... and worse, his solution is to mine empty blocks with no transactions other than the coinbase transaction. This is also the origin of the path that lead to SPV mining.

Is there a reason someone can't design an intelligent getblocktemplate replacement that can hook into the block change processing and supply a new template, with the transactions in the memory pool that are not affected by the block being processed, but build off that new block, once it has been verified as valid? CPUs these days are pretty quick and multi threaded ... I can't see why a few ms delay building a template of already validated, unused transactions should be an excuse for mining empty blocks.

Already working on a more optimised version, no need for your trolling (which happens to expose how clueless you are on how this works right now).

(It's also actually not so bad if you configure bitcoind properly...)

But it's your excuse for mining empty blocks - so it must be pretty bad?

Though on my pool it beats your pool on block changes more than 90% of the time and I use getblocktemplate ...

So I guess that leads to wondering what the reason is for mining empty blocks if you say that if you configure bitcoind "properly" it's fast, but you don't do that ...

Mining empty blocks is always inherently necessary for optimal behaviour. I agree getblocktemplate could implement that for solo miners, but it wouldn't help the case of a mining pool which needs to ensure each user gets the empty block regardless of availability of transaction data.

(also, your false statistics are irrelevant to this discussion, so I will simply ignore them)

This tracker is for technical issues, not for trolling.

Ah ok, thanks sipa, bitcoind's terribly slow getblocktemplate isn't a technical issue - it's expected. Glad that was cleared up.

Then file an issue about the problems it is causing in a respectful way. Even better, submit a pull request to improve it.

Well if it wasn't a well known, long term, high profile issue, that's been ignored by the bitcoin devs, one might then consider that it doesn't need confronting facts to try and make someone take notice of it ... however ...

It's relevant to block size re: the XT "battle", it's relevant to SPV re: recent chain fork, it's relevant to the recent regular transaction 'testing' that has caused bitcoin confirmation delays, it's been bypassed for use on block changes by Luke-jr for a very long time (and he commited the change), he (a supposed "bitcoin dev") has claimed for a long time that not using getblocktemplate but some other way validating the block and sending out an empty block is faster AND justified - and the majority of the network has copied him doing this empty block mining ...

There are threads on the subject on the bitcoin forum and comments about it for a long time. The only "supposed" "bitcoin dev" there, justifies it as OK - as he has yet again attempted to here above claiming it is "inherently necessary for optimal behaviour", but it isn't, and I've even proven that and pointed out how anyone can do that. Even his reply saying he is working on it, directly points to the fact that it isn't OK ... the same person who ran his pool for 5 months only confirming 32 transactions per block ... and he seems to be the one who is working on it again ... doesn't sound good at all ...

FWIW, the reason I am working on improving it is to address other concerns with the codebase, not primarily for the purpose of fulfilling the premature optimisation you are asking for.

Well I know someone who spent a day on it and improved the basic code out of sight without damaging the fungibility of bitcoin by blacklisting like you do. So I presume since you just started on this today we should see something in the next day or 2?

@kanoi You are being rude. In open source if you want something implemented, either do it yourself or if you can't/won't, pay someone to do it. No one owes you any work for free