Our current PaymentReceived API is incredibly easy to mis-use -
the "obvious" way to implement a client is to always call
`ChannelManager::claim_funds` in response to a `PaymentReceived`
event. However, users are *required* to check the payment secret
and value against the expected values before claiming in order to
avoid a number of potentially funds-losing attacks.
Instead, if we rely on payment secrets being pre-registered with
the ChannelManager before we receive HTLCs for a payment we can
simply check the payment secrets and never generate
`PaymentReceived` events if they do not match. Further, when the
user knows the value to expect in advance, we can have them
register it as well, allowing us to check it for them.
Other implementations already require payment secrets for inbound
payments, so this shouldn't materially lose compatibility.
This prepares us for requiring payment_secrets for all received
payments, by demonstrating test changes work even prior to the new
requirement.
In order to avoid needing to pipe payment secrets through to
additional places in the claim logic and then removing that
infrastructure once payment secrets are required, we use the new
payment secret storage in ChannelManager to look up the payment
secret for any given pament hash in claim and fail-back functions.
This part of the diff is reverted in the next commit.
In order to reduce code movement in the next commit, this commit
simply tweaks get_payment_preimage_hash!() and related functions in
functional tests to return a payment secret. Further, we ensure
that we always call get_payment_preimage_hash!() with the node
which will ultimately receive the payment.
This adds support for tracking payment secrets and (optionally)
payment preimages in ChannelManager. This potentially makes client
implementations much simper as they don't have to have external
payment preimage tracking.
This doesn't yet use such tracking anywhere.
During the block API refactor, we started calling
Channel::force_shutdown when a channel is closed due to a bogus
funding tx. However, we still set the channel's state to Shutdown
prior to doing so, leading to an assertion in force_shutdown (that
the channel is not already closed).
This removes the state-set call and adds a (long-overdue) test for
this case.
Fixes: 60b962a18e
Previously, if a user simultaneously called
`PeerHandler::process_events()` from two threads, we'd race, which
ended up sending messages out-of-order in the real world.
Specifically, we first called `get_and_clear_pending_msg_events`,
then take the `peers` lock and push the messages we got into the
sending queue. Two threads may both get some set of messages to
send, but then race each other into the `peers` lock and send the
messages in random order.
Because we already hold the `peers` lock when calling most message
handler functions, we can simply take the lock before calling
`get_and_clear_pending_msg_events`, solving the race.
This test failed when ConnectionStyle was set to a SkippingBlocks
variant because of a bug in ChannelMonitor::update_best_block.
Parameterize the test with these styles to catch any regressions.
Define an Electrum-friendly interface for ChannelMonitor where txids of
relevant transactions can be obtained. For any of these transactions
that are re-orged out of the chain, users must call
transaction_unconfirmed.
There is a possible race condition when both the latest block hash and
height are needed. Combine these in one struct and place them behind a
single lock.
When using Electrum, transactions are individually unconfirmed during a
reorg rather than by block. Store the txid of the transaction creating
the on-chain event so that it can be used to determine which events need
to be removed when a transaction is unconfirmed.
Rather than mapping height to a vector of events, use a single vector
for all events. This allows for easily processing events by either
height or transaction. The latter will be used for an interface suitable
for Electrum.
Instead of relying on the user to ensure the funding transaction is
correct (and panicing when it is confirmed), we should check it is
correct when it is generated. By taking the full funding transaciton
from the user on generation, we can also handle broadcasting for
them instead of doing so via an event.
When we force-close a channel, for whatever reason, it is nice to
send an error message to our peer. This allows them to closes the
channel on their end instead of trying to send through it and
failing. Further, it may induce them to broadcast their commitment
transaction, possibly getting that confirmed and saving us on fees.
This commit adds a few more cases where we should have been sending
error messages but weren't. It also includes an almost-global
replace in tests of the second argument in
`check_closed_broadcast!()` from false to true (indicating an error
message is expected). There are only a few exceptions, notably
those where the closure is the result of our counterparty having
sent *us* an error message.
Electrum clients primarily operate in a world where they query (and
subscribe to notifications for) transactions by script_pubkeys.
They may never learn very much about the actual blockchain and
orient their events around individual transactions, not the
blockchain.
This makes our ChannelManager interface somewhat more amenable to
such a client by splitting `block_connected` into
`transactions_confirmed` and `update_best_block`. The first handles
checking the funding transaction and storing its height/confirmation
block, whereas the second handles funding_locked and reorg logic.
Sadly, this interface is somewhat easy to misuse - notifying the
channel of the funding transaction being reorganized out of the
chain is complicated when the only notification received is that
a new block is connected at a given height. This will be addressed
in a future commit.
