While this isn't neccessary for message ordering consistency, this
does mean that we won't end up processing an HTLCFailChannelUpdate
from a update_fail_htlc prior to it being fully committed (where if
the peer disconnects/reconnects it could theoretically give us a
different result, eg if their next-hop reconnected to them).
Sadly we can't straight up use the new serialization framework as
we have a few different serialization variants, but that's OK, it
looks identical and is just missing the Writeable impl
This removes a bunch of potentially new error handling in writers
and the checks were kinda useless anyway - in normal operation we
unwrap()ed anyway, and we're gonna want to use the serializtion
framework for ChannelMonitor/ChannelManager serialization, which
may generate things larger than 64KB anyway.
I think this might have been my fault due to faulty review
feedback, but fuzzer caught trivial crash here where you try to
send a ping message larger than 16KB (but smaller than the
max-length 64KB) and you crash as message serialization is unwrap()
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.
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.
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
Follows BIP69: https://github.com/bitcoin/bips/blob/master/bip-0069.mediawiki
1. Implements sorting of transactoin inputs.
- BIP says to use "reversed byte-order" for the `prev_hash`. I interpreted this as: little-endian.
- TODO need to add tests
2. Re: improve sorting of TxOut's script_pubkey to use lexicographic ordering, and not length.
From the test-cases i've included it seems that the current code already does lexicographic ordering (and not length based). Am i missing something?
