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
```
note: why is the first byte cut unconditionally? what if it's non-zero?
Maybe the intention of cutting the first two chars in the hex case intended to
cut a "0x" prefix?? But there was no such prefix with the given format string...
change is no-op as the compact nBits form of both values are equal, that is:
```
>>> from electrum.blockchain import Blockchain
>>> MAX_TARGET1 = 0x00000000FFFF0000000000000000000000000000000000000000000000000000
>>> MAX_TARGET2 = 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>>> Blockchain.bits_to_target(Blockchain.target_to_bits(MAX_TARGET2)) == Blockchain.bits_to_target(Blockchain.target_to_bits(MAX_TARGET1))
True
```
If daemon.taskgroup dies
- in GUI mode, show a crash reporter window to the user,
instead of immediately stopping the whole process.
- in daemon mode, log exception and stop process, as before.
We create a tx when the dialog is created, and re-create it every time
the user moves the fee slider. However, we were not re-creating it if
the user toggles the "Final" checkbox, meaning its value was only taken
into account if the user moved the fee slider after setting the checkbox.
fixes https://github.com/spesmilo/electrum/issues/7547
Alice sends and HTLC: Alice->Carol->Dave
we need a lot of messages back and forth to happen:
- Alice adds HTLC to chan_AC, sends sig, Carol revacks, sends sig, Alice revacks;
- only then Carol adds HTLC to chan_CD, sends sig, Dave revacks, sends sig, Carol revacks
on CI, 0.5 seconds is often not enough for this it seems.
* on channel opening we verify that the peer's dust limit is above 354
sat, the limit for unknown segwit versions
* we constrain the allowed scriptpubkey types for channel closing
* we check that the remote's output is above the relay dust limit for
the collaborative close case
The latest release of appimagetool bundles a new enough version of
mksquashfs. We had been building a fork of mksquashfs but all the
relevant patches there had been upstreamed.
Note: we still need a wrapper when calling mksquashfs, as appimagetool
calls it with "-mkfs-time 0" and we have the SOURCE_DATE_EPOCH env var
set; and these two would conflict.
Two ways to fix: either unset SOURCE_DATE_EPOCH for that context, or
build a wrapper that removes the "-mkfs-time 0". The former would be
cleaner but for some reason I did not manage to build reproducibly
that way. The latter seems to work.
related:
- https://github.com/AppImage/AppImageKit/issues/929#issuecomment-580769875
> Now official squashfs 4.4 makes reproducible images by default
- https://github.com/AppImage/AppImageKit/pull/996
