Mined two blocks with a single hash

[dooglus]

Hi.

I don't know if this is a bug or not, because I don't really understand the design.

I just mined two blocks in the same second because the same "stake modifier" was used two blocks in a row. The result of the hash was very low, which is what you need to mine a block, but then the exact same very low hash was used to mine another block, on another output from another address in the same second.

I'm talking about these two blocks (35004 and 35005):

http://khashier.com:2750/block/eb18e05bd9118378029445df411086f3bc6ab17ed818014c6648b887860a6a4c
http://khashier.com:2750/block/8061d8a894e22d2a40c813be6856ed07361ab79101c5a5c55363623eef2386d9

I added some debug to show the comparison between the hash and the target (both right shifted 224 bits to hide the insignificant bits). See how the same hash is used, and the same modifier:

  000038a8 <=     cfec (14)
CheckStakeKernelHash() : using modifier 0xae486833e969e2af at height=33032 timestamp=2014-07-11 12:33:10 UTC for block from height=32880 timestamp=2014-07-11 06:38:01 UTC
CheckStakeKernelHash() : pass modifier=0xae486833e969e2af nTimeBlockFrom=1405060681 nTxPrevOffset=149 nTimeTxPrev=1405060681 nPrevout=1 nTimeTx=1405355226 hashProof=000038a8c86aacde8681725c904abfc52e63c02b5d85bb3356edf2c50d4e0971

  000038a8 <=     bcc8 (14)
CheckStakeKernelHash() : using modifier 0xae486833e969e2af at height=33032 timestamp=2014-07-11 12:33:10 UTC for block from height=32881 timestamp=2014-07-11 06:38:01 UTC
CheckStakeKernelHash() : pass modifier=0xae486833e969e2af nTimeBlockFrom=1405060681 nTxPrevOffset=149 nTimeTxPrev=1405060681 nPrevout=1 nTimeTx=1405355226 hashProof=000038a8c86aacde8681725c904abfc52e63c02b5d85bb3356edf2c50d4e0971

Edit: I see this is only possible because I was staking using two outputs which themselves were mined at exactly the same time, in these blocks:

Transaction 55c00702d2...8d4b Appeared in Clams 32880 (2014-07-11 06:38:01)
Transaction 1cb68c4e39...2d4e Appeared in Clams 32881 (2014-07-11 06:38:01)

and they in turn were staked from outputs which themselves were mined together:

Transaction f73f152fa5...f6d3 Appeared in Clams 31250 (2014-07-08 10:44:59)
Transaction 113b44afcb...42fd Appeared in Clams 31249 (2014-07-08 10:44:59)

So it looks like in the future, whenever I am able to stake one of this pair, I am able to stake the other one at the same time as well.

This could be fixed by including the txid in the hash as well.

src/kernel.cpp says:

//   block/tx hash should not be used here as they can be generated in vast
//   quantities so as to generate blocks faster, degrading the system back into
//   a proof-of-work situation.

but that's talking about the hash of the block or tx we're creating, not of the tx we're staking from.

[dooglus]

It happened again:

http://khashier.com:2750/tx/b86611bf855b2c2d137b979401199a089a527b32c6020ce62fb113cb0c0e2b0d
http://khashier.com:2750/tx/96a17e428876cded69c85fd5db02ccfb2419df064ef248936e3f6769b5e7a038

I traced them back to their origin. This pair of twins has survived 4 generations from the initial distribution:

Transaction 96a17e4288...a038 Appeared in Clams 36282 (2014-07-16 15:29:22)
Transaction b86611bf85...2b0d Appeared in Clams 36283 (2014-07-16 15:29:22)

Transaction 34145c9742...d7f6 Appeared in Clams 35005 (2014-07-14 16:27:06)
Transaction 15c6983408...b0bb Appeared in Clams 35004 (2014-07-14 16:27:06)

Transaction 1cb68c4e39...2d4e Appeared in Clams 32881 (2014-07-11 06:38:01)
Transaction 55c00702d2...8d4b Appeared in Clams 32880 (2014-07-11 06:38:01)

Transaction 113b44afcb...42fd Appeared in Clams 31249 (2014-07-08 10:44:59)
Transaction f73f152fa5...f6d3 Appeared in Clams 31250 (2014-07-08 10:44:59)

Transaction f964ee0871...3f8b Appeared in Clams 6030 (2014-05-16 13:14:37)
Transaction c94e37971e...f995 Appeared in Clams 7372 (2014-05-16 18:20:38)

[nochowderforyou]

Yeah, I had some time and can finally confirm, the are sticking together when staked.

The hashProof was not updated during the original stake because of how close the timing was together and now they are 'locked' because they share the same hashproof.

The reason I suspect this happened originally is because of the high coinAge vs low difficultly when the addresses were imported. Generally it would be difficult to see this on other PoS coins but all PoS coins should display this behavior under these circumstances.

Including the txhash from a transaction that has already been created seems to be good solution. I can understand not including the currently block/tx hash but like you suggest the txhashes that were created from previous stakes and already included in the blockchain are for the most part immutable.

Thank you for detailing this!

I will get a testnet up this weekend to try out the fix and put in a pull request so you can take a look

[dooglus]

I tried making a fix for this.

It seems like all I need to do is use:

ss << nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n << nTimeTx << txPrev.GetHash();

instead of:

ss << nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n << nTimeTx;

in kernel.cpp, after some specific trigger block height. But I don't know how to find what height we're currently working on. Do we need to pass it in as an extra parameter?

[dooglus]

I pass nHeight into the relevant functions now, so we can decide whether to include the previous transaction hash or not.

I've done a little testing and it seems good.

[l0rdicon]

I just started testing myself and agree this seems to work as expected. I
have a pair that were entangled like yours (on tablet so don't have
addresses at the moment) and they did produce different hash proofs when I
staked them.

In black coins somewhat recent update they used the same method of using
the previous txhash to calculate the hash proof.

All in all I think it's a good sign this will resolve the issue

On Jul 25, 2014 4:24 AM, "Chris Moore" notifications@github.com wrote:

I pass nHeight into the relevant functions now, so we can decide whether
to include the previous transaction hash or not.

I've done a little testing and it seems good.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[dooglus]

#41 fixes this.