Posts

avatar of @edicted
25
@edicted
·
·
0 views
·
2 min read

I really don't understand how ref_block_num and ref_block_prefix numbers are generated.

Someone who knows what they are talking about:

Let's discuss the ref_block_* parameters a little: The ref_block_num indicates a particular block in the past by referring to the block number which has this number as the last two bytes. The ref_block_prefix on the other hand is obtain from the block id of that particular reference block. It is one unsigned integer (4 bytes) of the block id, but not starting at the first position but with an offset of 4 bytes.

The purpose of these two parameters is to prevent replay attacks in the case of a fork. Once two chains have forked, the two parameters identify two different blocks. Applying a signed transaction of one chain at another chain will invalidate the signature.


One thing I noticed though is that ref_block_num never goes higher than 65536

This is to stop someone from using a very old block number. They don't want people to sign a transaction using an old block... because if their was a fork a hacker would be able to rebroadcast the public transaction on the other chain.

Me:

So not only does ref_block_num & ref_block_reference stop users from repeating a transaction on the same chain, it also prevents users from repeating a transaction on a forked chain. This was obviously very intriguing for me, because Hive just forked away from Steem and I was totally confused about how this would be accomplished.

Essentially, as long as ref_block_num references a block AFTER a hardfork, it would be impossible to broadcast that same transaction onto another fork. This is because the signatures of the 2 blocks on the separate forks would be completely different. Pretty cool. They really thought of everything, eh?

Because ref_block_num is only the last two bytes of the block number in question, it is impossible to reference a block that is very old. 2 bytes is 16 bits, so the maximum length of an unsigned integer stored in this structure is 2^16 or 65,536. Therefore, every 65,536 blocks the ref_block_num overflows back to zero and the process starts all over again. With 3 second blocks, this only ends up being about 54.6 hours per cycle.

Posted Using LeoFinance