• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

$50 available to determine what is wrong with this block

Steve Sokolowski

New member
Hi,

Two years ago, on February 18, 2017, I posted a thread at https://www.dash.org/forum/threads/100-available-to-assist-with-transaction-id-problem.13181/ in this forum where developers were very helpful with resolving a problem submitting blocks to the Dash daemon. Now, I spent 12 hours on Saturday and 14 hours Sunday on a similar problem and was hoping to reward the first person who can solve the entire issue with $50.

I'm trying to upgrade the Prohashing mining pool to be compatible with the latest Dash changes, since I was told that the network is going to upgrade soon. My understanding is that the changes consist solely of adding additional payees to the coinbase transactions of blocks, and of appending the length a new field "coinbase_payload" to the end of the coinbase transaction, followed by the field itself.

I purchased a D3 miner for testing and mined 300 blocks on the testnet that were not accepted by the daemon. The most common error messages are "bad-txnmrklroot" and "bad-cb-type." "bad-txnmrklroot" occurs when I submit the following mined block:

0000002010173bbd94ac346868fc7788a99bbbc12347b80aa2fb8ba741e2030100000000d129bce13cd9a06d30a3146594b43b05bc2f71a05c48b50c8030ea6d58c5896c31e7695ca344011cb3e33fb70101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f4b4000476e7695c08f800000217000000142f70726f68617368696e672e636f6d010000002f0000000002c0d8b03d000000001976a9147a91f74e67aa90497868504f580489b411e3f38388acc0d8b03d000000001976a914a3c5284d3cd896815ac815f2dd76a3a71cb3d8e688ac00000000260100f4b4000075fc0c6906e8c07d784bb78401b0664bce33f436c1b2b90b53bbe29291151379

My potentially flawed understanding of what this serialized block means is the following:

00000020 - version
10173bbd94ac346868fc7788a99bbbc12347b80aa2fb8ba741e2030100000000 - previous hash
d129bce13cd9a06d30a3146594b43b05bc2f71a05c48b50c8030ea6d58c5896c - hash of the coinbase tx
31e7695c - time
a344011c - target
b3e33fb7 - nonce
01 - number of transactions
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f4b4000476e7695c08 - first part of tx sent to the customer for mining (coinb1 in stratum protocol)
f800000217000000 - customer's submitted nonce
(142f70726f68617368696e672e636f6d010000002f0000000002c0d8b03d000000001976a9147a91f74e67aa90497868504f580489b411e3f38388acc0d8b03d000000001976a914a3c5284d3cd896815ac815f2dd76a3a71cb3d8e688ac00000000 - end of traditional coinbase transaction
26 - length of "coinbase_payload"
0100f4b4000075fc0c6906e8c07d784bb78401b0664bce33f436c1b2b90b53bbe29291151379 - "coinbase_payload") - second part of stratum coinbase transaction sent to customer (coinb2)


Calling "submitblock" with this hex returns "bad-txnmrklroot."

I tried removing the "26" (length of coinbase_payload) and that returned "unable to parse block" in a 500 error. I tried sending the transaction as it would have been constructed previously to the miners with the additional payees but not with the coinbase_payload, so that the hash was the hash of the coinbase transaction without the extra coinbase_payload, and then appended the coinbase_payload to the transaction. That yields a "bad-cb-type" error, which to me seemed promising because that error appears after the "bad-txnmrklroot" error in the Dash source code, implying that the "bad-txnmrklroot" error was solved by not including the coinbase_payload in the hash.

However, I could not resolve the "bad-cb-type" error and decided to concentrate my efforts on including the coinbase_payload in the hash because I located documentation at https://dash-docs.github.io/en/developer-reference that makes no mention of omitting the coinbase_payload from the hashing operation. But because the documentation doesn't make clear what information is included in the coinbase_payload and why it is necessary, it's possible that my understanding of which way is correct is wrong. Even if the coinbase_payload should not be hashed, that still doesn't explain why a "bad-cb-type" error occurs.

I tried reversing the hash of the coinbase transaction in the hashMerkleRoot field, as some coins (particular equihash coins) do, but that still resulted in a "bad-txnmrklroot." I thought that would have a low probability of success anyway, given that this operation was never necessary for Dash previously.

Unfortunately, due to reduced litecoin prices compared to last time, we are only able to offer half as much compensation this time around, but hopefully someone will still come to the rescue and help us get this issue resolved before we have to discontinue Dash mining due to the fork.

If there are two answers that equally solve the problem, then the first person will be paid, or you can agree to split the difference.

Thanks,

-Steve Sokolowski
 
DIP3 coinbase txes should be of a version 3 https://github.com/dashpay/dips/blob/master/dip-0002.md#special-transactions and type 5 https://github.com/dashpay/dips/blob/master/dip-0004.md#coinbase-special-transaction i.e. this
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f4b4000476e7695c08 - first part of tx sent to the customer for mining (coinb1 in stratum protocol)
should actually look like this
03000500010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f4b4000476e7695c08 - first part of tx sent to the customer for mining (coinb1 in stratum protocol)
Hence full tx would be:
03000500010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f4b4000476e7695c08f800000217000000142f70726f68617368696e672e636f6d010000002f0000000002c0d8b03d000000001976a9147a91f74e67aa90497868504f580489b411e3f38388acc0d8b03d000000001976a914a3c5284d3cd896815ac815f2dd76a3a71cb3d8e688ac00000000260100f4b4000075fc0c6906e8c07d784bb78401b0664bce33f436c1b2b90b53bbe29291151379

As for other changes, pls see https://github.com/dashpay/dash/blob/v0.13.0.0/doc/release-notes.md#mining. Two implementations can be found at https://github.com/UNOMP/node-merged-pool/pull/17 (tested) and https://github.com/tpruvot/yiimp/pull/335 (not tested/no results yet).
 
Thanks for the help! It seems as if the system is a little farther along now. The "bad-cb-type" and "bad-txmrlkroot" errors have gone away by implementing the method described in the pull request.

Unfortunately, the daemon now returns a result of "inconclusive." The mining server then calls "getblock" to determine whether the daemon gets the block, and finds that a block with a different hash is present at the target height on the testnet. Here is one of the blocks that returned an "inconclusive" result:

00000020c0df8915f0758b69da5ea6ea4fd254a18965507f1cb97d6d0c7b3300000000000de0ed58c6f853fba5265a3c3b7b887183f86daf7d1c6f29bdf2211af2f1d40fcfff6a5ca304181ba5022be40103000500010000000000000000000000000000000000000000000000000000000000000000ffffffff27035db7000402006b5c08f8000005fb000000142f70726f68617368696e672e636f6d150000002f0000000003809e4730000000001976a9147a91f74e67aa90497868504f580489b411e3f38388ac98a6ce2e000000001976a914870ca3662658f261952cbfa56969283ad1e84dc588ace8f77801000000001976a914870ca3662658f261952cbfa56969283ad1e84dc588ac000000002601005db70000b27216c47724d45d56ea176d4a6816d6697712ef240a7880e20ec81c29f6b42a

"Inconclusive" seems to be in mining.cpp, line 828, and appears to be the last possible error, so I'm hoping that if the reason for this can be figured out, the issue will be resolved.
 
But isn't this ok-ish? Someone found a block while you were mining, so your block is an orphan one now. (FYI: someone is mining with 100Ghs+ on testnet today)
 
But isn't this ok-ish? Someone found a block while you were mining, so your block is an orphan one now. (FYI: someone is mining with 100Ghs+ on testnet today)

But this happened twice at separate times.

I'm going to wait until tomorrow and try again before declaring this finished and issuing a payout. If it returns true, then I'll just assume the testnet was orphaning blocks.

If I can't get it to confirm at least one block, then I don't feel comfortable enough with releasing this to production, given the expensive possibility that 1% of the network's hashrate could be wasted due to a bug. I'll talk to you tomorrow!
 
But isn't this ok-ish? Someone found a block while you were mining, so your block is an orphan one now. (FYI: someone is mining with 100Ghs+ on testnet today)

Unfortunately, this error is still present this morning, so I don't believe it's related to whatever mining someone else is doing with the testnet. The result is still "inconclusive," and when the daemon is queried for the hash of the block at that height, a different hash than the one that we submitted is returned.

What information can I provide to help move forward with this issue?
 
Hmmm... Well, let's see:
1. Does this happen for every block? Have you mined at least one block successfully?
2. How often do you query daemon for a new block template?
3. Does your pool use "-blocknotify" or "-zmqpubhashblock"/"-zmqpubrawblock" to stop working on an old block and query for a new template?
 
Thanks for the tip. I was successfully able to completely certify that Dash mines correctly.

The cause of the last problem was that the crossbar WAMP server was not running in the development environment. When a coin has a new block, blocknotify executes a program that forwards the block template to a WAMP channel. All the mining servers subscribe to this channel to know when a coin has a new block. In this case, because the WAMP server was not running, new blocks were not received, and the large amount of hashrate on the Dash testnet was always finding at least one block between the time I restarted a mining server and when the D3 found a block.

As I'm sure you're aware, it's usually more difficult to set up the development environment and keep it working than to actually write code. It's taken me two days to compile Komodocoin, which is the next coin I have to deal with that changed its block template, because they introduced a new dependency and it requires the creation of a Debian 9 virtual machine (8 isn't supported.)

If you could post the coin and address you would like payout in, I'll make sure my brother issues the payout tomorrow morning. We can pay in any of the coins listed at https://prohashing.com, at the bottom, in "live coin status."

Thanks again for your help! I once asked the Verge community some questions about their algorithm and I got nine troll replies, and Gregory Maxwell is impossible to work with when I asked the Bitcoin Core developers for help. The Dash developers are, by far, the best developers of any coin, and they realize that third-party developers can't read minds and will not develop for a coin without documentation and support.
 
Glad you solved it! No need for a payout, I'm happy to help keeping mining space as much decentralized/diversified as possible. We all as a community depend on this after all ;)

PS. Thanks for your kind words :)
 
[...]
Thanks again for your help! I once asked the Verge community some questions about their algorithm and I got nine troll replies, and Gregory Maxwell is impossible to work with when I asked the Bitcoin Core developers for help. The Dash developers are, by far, the best developers of any coin, and they realize that third-party developers can't read minds and will not develop for a coin without documentation and support.

Thanks for the kind words, much appreciated - the crypto space is highly abrasive sometimes but we will continue to stick to our netiquette standards nevertheless.
 
Heh, just noticed new coins on my donation address sent from Prohashing pool address. Thanks! :)
 
Back
Top