Ensure that GetBlockTemplate functions as intended

[str4d]

We have made various changes to the block header and the proof-of-work, but we haven't checked that GetBlockTemplate still functions correctly (as mentioned in #826). A few people in the community Slack have started trying to use it and are encountering the responses inconclusive followed by duplicate-inconclusive when submitting blocks. We should find and fix any issues with GBT, and specify any differences from BIP-22.

[Ban44n]

I would like to suggest a feature for the getblocktemplate spec. It would be great if GBT would include the founders reward and the miners reward separately in the JSON response.

[Ban44n]

I would like to suggest a feature for the getblocktemplate spec. It would be great if GBT would include the founders reward and the miners reward separately in the JSON response.

[artlav]

Clarifications.
Here is an example of two blocks - http://pastebin.com/e8LUw2hY
First was generated based on the data in getblocktemplate.
The second one is the unrelated one later found in the blockchain at the same height.

The first one failed on submitblock with "inconclusive" answer.
Trying to submit it later (when it's no longer on the tip) gives "duplicate-inconclusive".
Incidentally, trying to submit a correct block gives only "duplicate".

Furthermore, trying to change the "inconclusive" block keeps the "inconclusive" word in the answer along with whatever error gets induced, like wrong previous block or too high hash. i.e. "inconclusive-not-best-prevblk"

Trying to change the TX part of the block does not change the "inconclusive" answer, so the problem is likely before the merkle root is checked.

The problem is notoriously hard to debug, since it requires mining a block to check any guesses, so i only have one data point at the moment.

[artlav]

Clarifications.
Here is an example of two blocks - http://pastebin.com/e8LUw2hY
First was generated based on the data in getblocktemplate.
The second one is the unrelated one later found in the blockchain at the same height.

The first one failed on submitblock with "inconclusive" answer.
Trying to submit it later (when it's no longer on the tip) gives "duplicate-inconclusive".
Incidentally, trying to submit a correct block gives only "duplicate".

Furthermore, trying to change the "inconclusive" block keeps the "inconclusive" word in the answer along with whatever error gets induced, like wrong previous block or too high hash. i.e. "inconclusive-not-best-prevblk"

Trying to change the TX part of the block does not change the "inconclusive" answer, so the problem is likely before the merkle root is checked.

The problem is notoriously hard to debug, since it requires mining a block to check any guesses, so i only have one data point at the moment.

[artlav]

Further development.
Please contemplate the coinbase script in the bad block: "0502e3180101".
If i change it to "0502e3180102", then the "inconclusive" vanishes.
Several other values that are not 01 also work.

That extranonce field DOES mean something.
Or it's not extranonce, but something else.

[artlav]

Further development.
Please contemplate the coinbase script in the bad block: "0502e3180101".
If i change it to "0502e3180102", then the "inconclusive" vanishes.
Several other values that are not 01 also work.

That extranonce field DOES mean something.
Or it's not extranonce, but something else.

[artlav]

3 more blocks got mined, one succeeded, others are inconclusive.

The good block does not become inconclusive whatever changes i make.
The bad blocks cease to be inconclusive once i change that coinbase byte.

[artlav]

3 more blocks got mined, one succeeded, others are inconclusive.

The good block does not become inconclusive whatever changes i make.
The bad blocks cease to be inconclusive once i change that coinbase byte.

[artlav]

Ok, with some more instrumentation and logging added, it might be that the problem is merely one of error reporting.

Specifically, the "inconclusive" error happens when the block with the same height was already mined while the one being submitted was mining - by the time the block is done, the blockchain already advanced, and the daemon doesn't explicitly recognize what is wrong, only that something is wrong, giving the "inconclusive" answer.

According to a discussion from 2014, that was a known bad language - it says inconclusive in cases like the block being too late and/or on the shorter chain - http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/20

So, ideally you should print out a more elaborated error if the problem is just a stale block.

[artlav]

Ok, with some more instrumentation and logging added, it might be that the problem is merely one of error reporting.

Specifically, the "inconclusive" error happens when the block with the same height was already mined while the one being submitted was mining - by the time the block is done, the blockchain already advanced, and the daemon doesn't explicitly recognize what is wrong, only that something is wrong, giving the "inconclusive" answer.

According to a discussion from 2014, that was a known bad language - it says inconclusive in cases like the block being too late and/or on the shorter chain - http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/10/20

So, ideally you should print out a more elaborated error if the problem is just a stale block.

[str4d]

@ampyx @artlav I have opened PR #1435 that updates GBT with the additional information necessary to use it with Zcash, and also implements coinbasetxn from BIP 22 (and uses it by default). Please test it and see whether it helps to resolve your issues 😃

[str4d]

@ampyx @artlav I have opened PR #1435 that updates GBT with the additional information necessary to use it with Zcash, and also implements coinbasetxn from BIP 22 (and uses it by default). Please test it and see whether it helps to resolve your issues 😃

[Ban44n]

@str4d This looks like something we can work with. In my current version I use validateaddress to obtain the pubkey for the coinbase transaction. Glad that this is now supplied directly by GBT.

[Ban44n]

@str4d This looks like something we can work with. In my current version I use validateaddress to obtain the pubkey for the coinbase transaction. Glad that this is now supplied directly by GBT.

[str4d]

Postponed to rc1.

[str4d]

Postponed to rc1.

[sammy007]

coinbasetxn is cool, no need to generate txes on pool side, but what about founders? Do we still need to generate it or these transactions also will be includedin template?

[sammy007]

coinbasetxn is cool, no need to generate txes on pool side, but what about founders? Do we still need to generate it or these transactions also will be includedin template?