This patch got a bit bigger than I'd intended, but primarily this
unifies force_shutdown() handling so all the callsites at least
look similar. It also fails backwards any HTLCs which were
completely pending (ie hadn't been committed to) and ensures we
broadcast our local commitment transaction. It also adds a
force_close_channel method to ChannelManager to expose
force-closure.
In case we are in AwaitingRemoteRevoke and we go to claim an HTLC
(at which point we've already given up the money to the next hop in
the payment) we just write it to holding_cell_htlc_updates.
However, we should be ensuring we *also* write it to our
channel_monitor as we need to make sure we can still claim it after
a force_shutdown() or otherwise after hitting the chain.
We don't bother doing anything smart, we just return an Err in
case we have a pending outbound HTLC with the payment_hash provided
for the send.
This doesn't resolve the TODO as users can still send duplicative
payments that have the same payment_hash as was already sent,
though the docs are updated and hopefully users do so on their own.
For some reason we were only setting "announce_publicly" when
Channel::new_from_req had announce_publicly set to true and the
open_channel message had the relevant flag set. However, this
resulted in us rejecting peers for sending unsolicited
announcement_signatures messages, despite them having indicated,
and us having accepted, their announce-bit-set open_channel.
Add test for DisconnectPeer event
Update DisconnectPeer with optional ErrorMessage
Manage error for funding_transaction_generated
Add disconnect_socket to SocketDescriptor trait
this was a TODO and also briefly discussed in https://github.com/rust-bitcoin/rust-lightning/pull/43#pullrequestreview-135649551
I'm not fully sure how to remove the `Option`, and make it completely required. Would love suggestions. So, have omitted that for now. Plus, better to make smaller, incremental changes.
Test Plan:
`cargo build`
`cargo test`
This constants defines the maximum value of `open_channel.funding_satoshis`,
currently it's defined to be 2^24 according to the BOLT #2 specification.
Also a test was added to check that the constant is never over 2,1x10^15
(maximum satoshis in bitcoin) if modified.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
This structure replaces the (Sha256dHash, u16) tuple that was being used
for the funding output.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
It obviously was nonsensical prior, though its now way more
complicated...there's refactoring work to be done here, but it
should at least kinda sorta work now.
