Browse Source
This fixes three bugs: - too large targets: the fixme in target_to_bits, which meant that we could not handle targets where the first bit was non-zero. This however cannot happen due to these being over MAX_TARGET. (difficulty 1) - too small targets: in bits_to_target, very small targets were not handled well: ``` >>> Blockchain.bits_to_target(0x03008000) 32768 ``` We could not process headers with targets smaller than the above value. (note that these small targets would only occur at astronomically high mining difficulty) - non-canonically encoded targets: we would not accept headers that had targets encoded in compact form (nBits) in a non-canonical way. I think this bug could actually be triggered by mining such a header. E.g. consider the target "1167130406913723784571467005534932607254396928" ``` Blockchain.target_to_bits(1167130406913723784571467005534932607254396928).to_bytes(4, "big").hex() '13345600' ``` Bitcoin Core when used to e.g. mine a block would encode this target as 0x13345600 in compact form. However, AFAICT, when validating Bitcoin Core would equally accept 0x14003456 which decodes to the same target. We were however rejecting such non-canonical compact nBits. ``` >>> from electrum.blockchain import Blockchain >>> Blockchain.bits_to_target(0x14003456) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/user/wspace/electrum/electrum/blockchain.py", line 548, in bits_to_target raise Exception("Second part of bits should be in [0x8000, 0x7fffff]") Exception: Second part of bits should be in [0x8000, 0x7fffff] >>> Blockchain.bits_to_target(0x13345600) 1167130406913723784571467005534932607254396928 ```patch-4
2 changed files with 66 additions and 9 deletions
Loading…
Reference in new issue