This was done to calculate the bip32 root fingerprint but it broke
the digitalbitbox. The keystore already had a different way to get
the root fingerprint for existing wallets, specifically handling this
case; the code in base_wizard used when creating new wallets was
duplicating that code originally and was then forgotten to be updated.
Now these codepaths are unified.
closes#5816
- no more passing around "invoice" in GUIs, invoice "paid" detection is now handled by wallet logic
- a tx can now pay for multiple invoices
- an invoice can now be paid by multiple txs (through partial payments)
- new data structure in storage: prevouts_by_scripthash
- type: scripthash -> set of (outpoint, value)
- also, storage upgrade to build this for existing wallets
had a trace where we tried to send "funding_locked" before being initialized:
D | lnpeer.Peer.[iq7zhmhck54vcax2vlrdcavq2m32wao7ekh6jyeglmnuuvv3js57r4id.onion:9735] | Sending FUNDING_LOCKED
E | lnworker.LNWallet | Exception in on_update_open_channel: AttributeError("'LNTransport' object has no attribute 'sk'")
Traceback (most recent call last):
File "...\electrum\electrum\util.py", line 999, in wrapper
return await func(*args, **kwargs)
File "...\electrum\electrum\lnworker.py", line 674, in on_update_open_channel
peer.send_funding_locked(chan)
File "...\electrum\electrum\lnpeer.py", line 876, in send_funding_locked
self.send_message("funding_locked", channel_id=channel_id, next_per_commitment_point=per_commitment_point_second)
File "...\electrum\electrum\lnpeer.py", line 102, in send_message
self.transport.send_bytes(raw_msg)
File "...\electrum\electrum\lntransport.py", line 93, in send_bytes
lc = aead_encrypt(self.sk, self.sn(), b'', l)
AttributeError: 'LNTransport' object has no attribute 'sk'
- persisted states are saved
- state transitions are checked
- transient states are stored in channel.peer_state
- new channel states: 'PREOPENING', 'FUNDED' and 'REDEEMED'
- upgrade storage to version 21
When no (supported) authentication is passed to the JSON-RPC server,
return a 401 HTTP error code instead of 403. This indicates to the
client that authentication is required, and also requests that to be
sent using the "basic" method. The previously-returned code 403 is now
only returned if authentication is passed but not valid.
There are some JSON-RPC clients out there that only send authentication
after a 401 code requested it. Those fail to connect to the Electrum
RPC interface even if the correct password is configured. Those same
clients can e.g. connect to Bitcoin Core successfully, which already
implements logic matching this change.
See also https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses.
SomberNight
Janus Troelsen
ThomasV
roth
Riccardo Casatta
Daniel Kraft