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.
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.
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
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.
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.
Sadly none of them are really any good without some hand-holding to
generate good input data, and unless sha256 gets stubbed out I'm
not sure they're gonna get good without a symbolic execution fuzzer
