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.
The daemon by default listens for RPC over a socket.
Before this change, this socket was a TCP/IP network socket (over localhost),
but now we change it to be a unix domain socket by default (if available).
This socket is used not only when sending commands over JSON-RPC,
but also when using the CLI, and to a tiny extent even used when running the GUI.
The type of socket used (and hence this change) is invisible to CLI and GUI users.
JSON-RPC users might want to use either the --rpcsock CLI flag
or set the "rpcsock" config key (to "tcp") to switch back to using a TCP/IP socket.
In practice it seems unix domain sockets are available on
all mainstream OSes/platforms, except for Windows.
closes https://github.com/spesmilo/electrum/issues/7553
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
ThomasV
SomberNight
upgradvisor-bot
Pavol Rusnak
matejcik
bitromortac
yanmaani