I think this was originally needed due to incorrect management of group lifecycles,
which our current code is doing better.
also note that if we needed this, in newer aiorpcx, the name of
the field was ~changed from `_closed` to `joined`:
239002689a
maybe fixes https://github.com/spesmilo/electrum/issues/7640
Looks like by default pip is ignoring the locally available setuptools and wheel,
and downloading the latest ones from the internet at build time...
https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/?highlight=no-build-isolation#disabling-build-isolationhttps://stackoverflow.com/a/62889268
> When making build requirements available, pip does so in an isolated environment. That is, pip does not install those requirements into the user’s site-packages, but rather installs them in a temporary directory which it adds to the user’s sys.path for the duration of the build. This ensures that build requirements are handled independently of the user’s runtime environment. For example, a project that needs a recent version of setuptools to build can still be installed, even if the user has an older version installed (and without silently replacing that version).
>
> In certain cases, projects (or redistributors) may have workflows that explicitly manage the build environment. For such workflows, build isolation can be problematic. If this is the case, pip provides a --no-build-isolation flag to disable build isolation. Users supplying this flag are responsible for ensuring the build environment is managed appropriately (including ensuring that all required build dependencies are installed).
If only it were that easy!
If we add the "--no-build-isolation" flag, it becomes our responsibility to install *all* build time deps,
hence we now have "requirements-build-makepackages.txt".
Note: this was causing a weird flake8 error on CI. Presumably due to CI running flake8 via py3.7.
```
flake8 . --count --select=$ELECTRUM_LINTERS --show-source --statistics
./electrum/scripts/update_default_servers.py:1:26: E999 SyntaxError: invalid syntax
#!/usr/bin/env python3
^
1 E999 SyntaxError: invalid syntax
1
```
Historically, there have often been (visual) issues with new versions of qdarkstyle.
The upper bound restriction was mainly there for this reason: to ~force manually testing new versions.
There is no known issue with newer versions atm.
Remove the upper bound, as there have not been issues with newer versions recently,
and this makes it clear to e.g. packagers that it's fine to use newer versions.
Add a lower bound for a version that has been tested in the past and is known to work ok.
related https://github.com/spesmilo/electrum/issues/7361
The <2.1 pin had been put there as dnspython 2.1 added "poetry" as a build time dep,
which pulled in a significant number of transitive dependencies, and it was also
causing issues with our appimage build.
dnspython 2.2.0 was released since, which no longer needs full poetry, only "poetry-core":
da279dec7e
related https://github.com/spesmilo/electrum/issues/7361
trezorlib requires "dataclasses ; python_version<'3.7'", and our min supported python version is 3.6,
so freeze_packages.sh pins down a version of "dataclasses". However, when creating binaries we
use newer versions of python (typically py3.9 atm), for which dataclasses is not available (it's a backport of py3.7 stuff).
Hmhm, what to do... short-term, I am manually removing the dataclasses pin, so it won't be installed in our binaries.
```
Collecting construct==2.10.67
Downloading construct-2.10.67.tar.gz (57 kB)
|████████████████████████████████| 57 kB 2.7 MB/s
Preparing metadata (setup.py) ... done
Requirement already satisfied: cryptography==36.0.1 in ./build/appimage/electrum.AppDir/usr/lib/python3.9/site-packages (from -r /opt/electrum/contrib/build-linux/appimage/../../../contrib/deterministic-build/requirements-hw.txt (line 74)) (36.0.1)
ERROR: Could not find a version that satisfies the requirement dataclasses==0.8 (from versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6)
ERROR: No matching distribution found for dataclasses==0.8
```
follow-up https://github.com/spesmilo/electrum/pull/7202
defaultdict[int] is a type!
```
>>> from collections import defaultdict
>>> d = defaultdict[int]
>>> d[2]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: There are no type variables left in collections.defaultdict[int]
```
Also, prior to py3.9, it is a TypeError.
`drop_to_remote` can be False and at the same time the to_remote output
is not present, because it is below dust. Therefore, we have to explicitly
check if to_remote is present when checking for the allowed script types and
dust limits. This affects channels which have sent only dust values, they
can't be closed unilaterally without this fix.
Fixes a regression introduced by 947693c90d.
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.
SomberNight
vertion
Jeremy Rand
bitromortac
ThomasV
upgradvisor-bot
Pavol Rusnak
matejcik