Matt Corallo [Sun, 26 Aug 2018 20:35:26 +0000 (16:35 -0400)]
Return a malformed HTLC message when ephemeral pubkey is garbage
This resolves a spec-compliance bug with BOLT 4 where we simply
failed to deserialize the message and thus could never return an
HTLC failure message. However, note that BOLT 4 incorrectly hints
that a non-malformed message should be used ("...MUST report a
route failure to the origin node") which we cannot do as we cannot
derive a SharedSecret to encrypt a regular update_fail_htlc message
UpdateFailHTLC isn't really an error anymore now that its handled
async after channel commitment (as required by BOLT 2), and since
its unused this is free. To resolve the TODO which intended to use
it for HTLC failure when trying to route forwards, we instead opt
to merge all the HTLC update events into one UpdateHTLCs event
which just contains a CommitmentUpdate object.
Matt Corallo [Tue, 21 Aug 2018 20:57:41 +0000 (16:57 -0400)]
Do not return UpdateFailHTLC updates until the HTLC is committed
This fixes a violation of BOLT 2 and will let us consolidate some
HTLC update handling. Good bit of code movement, but is mostly
refactor to store HTLC failure status in pending_htlcs in Channel.
Matt Corallo [Thu, 16 Aug 2018 14:31:10 +0000 (10:31 -0400)]
Fix PaymentReceived/sha256 handling in full_stack_target
Sha256 in fuzztarget was updated some time ago to use XOR instead
of the first byte of a real SHA256 run and somehow received and
sent payments got crossed in full_stack_target.
Antoine Riard [Wed, 25 Jul 2018 02:34:51 +0000 (02:34 +0000)]
Logging interface
Implement error, warn, info, debug and trace macros, internally calling
an instance of Logger, and passing it to every main structures
Build-time or client-side filtering.
Issue #54
Matt Corallo [Thu, 2 Aug 2018 10:23:53 +0000 (06:23 -0400)]
Fix panic on reorg through the funding_locked-generating block
We had a TODO to handle "lost confirmation" in block_connected,
which we recently did in block_disconnected (calling force_shutdown
in case we get too many blocks disconnected) but didn't handle the
case where we had a simple reorg through the block that resulted in
us generating a funding_locked.
Matt Corallo [Wed, 1 Aug 2018 20:13:04 +0000 (16:13 -0400)]
Fix types in Channel::funding_tx_confirmed_in
This should have no effect in a real system but was causing the
full_stack_target fuzz test to fail due to a block with a null hash
being disconnected.
Matt Corallo [Sat, 28 Jul 2018 23:15:45 +0000 (19:15 -0400)]
Add pending-HTLC-failure to and unify force_shutdown() handling
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.
Matt Corallo [Thu, 26 Jul 2018 21:53:10 +0000 (17:53 -0400)]
Fix force_shutdown() bug where we lose knowledge of a preimage
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.
Matt Corallo [Thu, 26 Jul 2018 19:44:27 +0000 (15:44 -0400)]
Handle duplicate payment_hash send_payment()s
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.
Matt Corallo [Thu, 26 Jul 2018 18:33:01 +0000 (14:33 -0400)]
Properly calculate Channel::announce_publicly
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.