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.
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?
Add test for DisconnectPeer event
Update DisconnectPeer with optional ErrorMessage
Manage error for funding_transaction_generated
Add disconnect_socket to SocketDescriptor trait
Summary:
Implementing these, taking inspiration from the surrounding code since i'm a rust n00b.
Test Plan:
```
cargo build
cargo test channel_reestablish
```
output:
```
running 3 tests
test ln::msgs::tests::encoding_channel_reestablish_with_secret ... ok
test ln::msgs::tests::decode_channel_reestablish_bad_length ... ok
test ln::msgs::tests::encoding_channel_reestablish_no_secret ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 14 filtered out
```
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`
* commitment transaction number, as used in locktime/sequence
fields is actually different from commitment transaction number,
as used for revocation state. This is confusing and never stated
in the spec, so we have to do the conversion.
* max_htlc_value_in_flight is never constrained in the spec, but
we were requiring it be <= channel size. Instead just clamp the
values the peer sends us when storing.
* channel_id calculation was incorrect, we now do some crazy
conversion hops, which we shouldn't, but will need to change our
types to fix.
* Our channel_reserve_satoshis value was too low, just change the
constant and leave the TODO to figure out what it really should
be for now.
