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
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
