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
- allow 'spend max' when opening a channel (fixes#5698)
- display amount minus fee when 'max' buttons are pressed
- estimate fee of channel funding using a template with dummy address
- Move 'handle_error_code_from_failed_htlc' to channel_db,
and call it from pay_to_route, because it should not be
called when HTLCs are forwarded.
- Replace 'payment_received' and 'payment_status'
callbacks with 'invoice_status' and 'request_status'.
- Show payment error logs in the Qt GUI
- In the invoices list, show paid invoices for which
we still have the log.
- use InvoiceInfo (NamedTuple) for normal operations,
because lndecode operations can be very slow.
- all invoices/requests are stored in wallet
- invoice expiration detection is performed in wallet
- CLI commands: list_invoices, add_request, add_lightning_request
- revert 0062c6d695 because it forbids self-payments
lnpeer (and interface) response-handling-code should not run in the
network main_taskgroup as the remote could force an exception
to be raised and that would kill the whole network instead of just the peer
e.g. Alice sends upd1, upd2, upd3, commitment_signed, upd4, upd5.
Bob receives all of these; and sends a revoke_and_ack but there is
a disconnect before Alice receives the revoke_and_ack.
During reestablish, if Bob claims to have received the commitment_signed,
Alice must not replay the msgs before that; but she should replay upd4 and upd5.
In recv_rev() previously all unacked_local_updates were deleted
as it was assumed that all of them have been acked at that point by
the revoke_and_ack itself. However this is not necessarily the case:
see new test case.
renamed log['unacked_local_updates'] to log['unacked_local_updates2']
to avoid breaking existing wallet files
Even if we haven't signed them yet (did not send commitment_signed).
Alternatively, if they are not yet signed, we could discard them here,
like we do already for remote updates above (chan.hm.discard_unsigned_remote_updates).
One of these two options must be done, and before this commit we were not doing either.
"current" used to be "oldest_unrevoked"; and pending was "oldest_unrevoked + 1"
but this was very confusing...
so now we have "oldest_unrevoked", "latest", and "next"
where "next" is "latest + 1"
"oldest_unrevoked" and "latest" are either the same or are offset by 1
(but caller should know which one they need)
rm "got_sig_for_next" - it was a redundant sanity check, that really
just complicated things
rm "local_commitment", "remote_commitment", "set_local_commitment",
"set_remote_commitment" - just use "get_latest_commitment" instead
Replay un-acked local updates (including commitment_signed) byte-for-byte.
If we have sent them a commitment signature that they "lost" (due to disconnect),
we need to make sure we replay the same local updates, as otherwise they could
end up with two (or more) signed valid commitment transactions at the same ctn.
Multiple valid ctxs at the same ctn is a major headache for pre-signing spending txns,
e.g. for watchtowers, hence we must ensure these ctxs coincide.
