Closed Leonardiae closed 4 years ago
@Leonardiae
f423d9ea050ea1b94c0fb66e9d64b96f4475aa0893fa5f999df73c8738000000
is actually reversed
00000038873cf79d995ffa9308aa75446fb9649d6eb60f4cb9a10e05ead923f4
And third hash is probably a block on the same height.
In BTC it takes long time to mine a block and when it is already mined there's little chance that your block on same height will be selected as best, if you mine it a bit later. So all miners pay attention at network and if new block is created they cancel mining at current height, and start building new block on top of new last block.
In our case we use generatetoaddress
which does not cancel mining until it succeeds. As a result, you can observe a lot of forks with length=1 (when there're 2 blocks on same height) when multiple miners mine blocks.
/-o -> fork with length=1
o-o-o -> current tip
As for "chain A always wins" -> chain A is currently applied chain (in our terms), chain B is any other block. When any new block comes we do POP Fork Resolution between current best chain (A) all tip candidates (essentially, all valid tips). When current tip is better, it says "A is better". When other chain wins, it prints "chain B wins". Debug.log is polluted, yes, but it helps to debug.
@Warchant Thanks for explaining! This is cool stuff to learn more about.
I learned that there can be a lot of forks with length 1 but for me this raises several questions:
Why is another hash selected as new best? I could understand if another block was build on that hash, but this was not the case here. the other hash is selected as new best without a new block being found yet (as far as I have seen).
Why is generatetoaddress being used in this case?
For me as a PoP miner the issue is that I have been PoP mining a block hash (and paid the fees to send the endorsements to the VBK network) and I assume I don't get paid for an endorsement of a block hash that never reaches the needed amount of confirmations.
Actually in this case I got a nice payment :) DONE 11. COMPLETED Paid amount: 866.80518660
Why is another hash selected as new best? I could understand if another block was build on that hash, but this was not the case here. the other hash is selected as new best without a new block being found yet (as far as I have seen).
It is hard to say. With our current setup it is very likely that both blocks on same height will have same POP score. In this case, we fallback to FR by chainwork (native FR in bitcoin). If block won, then it is better either by POP score or has higher chainwork.
Why is generatetoaddress being used in this case?
We did not invest time into changing mining software, generatetoaddress was easiest choice.
Thanks again. Well then I think this is the answer for now. If nessecary in the future I'll circle back to this :)
I noticed in my logs that it often happens that the latest block is being overwritten. I just checked the logs of one of those cases and wonder why this happens in this case:
For some reason there seem to be three different block hashes available for block 9216: f423d9ea050ea1b94c0fb66e9d64b96f4475aa0893fa5f999df73c8738000000 00000038873cf79d995ffa9308aa75446fb9649d6eb60f4cb9a10e05ead923f4 00000001fe0c54d97e2945cb5a757f6e548fb1478407493b2008535770ad68a1
My APM had been endorsing block 9216:00000038873cf79d995ffa9308aa75446fb9649d6eb60f4cb9a10e05ead923f4 (https://testnet.explore.veriblock.org/tx/85D2804449FF1F1A126AE7F3A90C0D347ACD180996BFCE0341C2416E93905CFF) so it ends up endorsing a block that does not being used anymore in the end. (I assume I don't get paid for this endorsement but not sure). //vbtca3af4e9b
I'm not an expert on block forking :) but why was the latest block overwritten twice without a new (9217) block being found and while chain A remains the best chain all the time (as far as I can see)?