* handle overflow for field 'max-htlc-value-in-flight'
* moved serialization of uint64 to codecs class
* moved constraint check
* fix configuration (was using hard coded values)
* using UInt64.MaxValue in test constants
* added a default handler for 'ok' messages in Channel
* update_add_htlc wire message: swap expiry and payment hash fields
see BOLT 2
* fix accept_channel wire encoding
'min depth' and 'hlc min msat' fields we swapped
* gui: set ip to "unknown" when it has not been set in node announcements
* reduced logging for Reconnect events
* peer is now able to switch transports, in case of undetected disconnection
* now using an exponential backoff retry when reconnecting to peers
* put the arguments of the 'open' http method in the same order as the uri
* added support for 'disable' flag in announcements (see lightningnetwork/lightning-rfc/pull/143)
* now responding TemporaryChannelFailure errors to CMD_ADD_HTLC in OFFLINE
* added helper methods for interpreting ChannelAnnouncement flags
* (gui) added image depicting flags of announcement in channels table
* implemented all failures as per lightningnetwork/lightning-rfc/pull/167
* router: don't use channels that have been announced as disabled
* Sphinx: implement BOLT PR 145
see https://github.com/lightningnetwork/lightning-rfc/pull/145
* Sphinx: use simplified onion proposed in PR145
address and hop-payload fields have fused, and we are now routing based on channel short ids
* Updated relayer to take advantage of shortChannelId
* Sphinx: use more meaningful class names
* BOLT 4: use 32 bytes MAC in reply error packet
instead of 20
* wire: add chainHash field to open message (see https://github.com/lightningnetwork/lightning-rfc/pull/135)
* split validateParams() into "funder" and "fundee" versions (fundee also needs to check the chain hash funder sent in their open message)
* Added a PaymentRequest object
* A `PaymentRequest` can be serialized/deserialized with `write`/`read`
static functions in companion
* Amount validation is handled in constructor
* `ReceivePayment` message in payment handler generates a `PaymentRequest`
* Updated tests
* HTLC succeeds if amount is equal or greater than requested amount
* If the amount paid is more than twice the amount expected, the HTLC fails
* (gui) display payment failed cause in notification
* Improved payment request validation messages
