* type-ified `ShortChannelId`
* removed unused `listUnspent` method and test
* updated sqlite version to 3.21.0.1
* ignore `ReadAck` in `PaymentLifecycle`
The Bitcoin Core `addwitnessaddress` rpc command is deprecated in version 0.16.0. Thus, the example `bitcoin.conf` needs to be extended to with the option `deprecatedrpc=addwitnessaddress`.
Without this change, Eclair will not be able to open new channels and the following error message will be written to eclair.log:
```
WARN akka.actor.OneForOneStrategy akka://default/user/$h/switchboard/peer-0390b6fbf04dd277955ce454c87b270d3c910fa96ef3d78afa4bf17d3b733fb877 - addwitnessaddress is deprecated and will be fully removed in v0.17. To use addwitnessaddress in v0.16, restart bitcoind with -deprecatedrpc=addwitnessaddress. Projects should transition to using the address_type argument of getnewaddress, or option -addresstype=[bech32|p2sh-segwit] instead. (code: -32)
```
* generate all channel keys and secrets from the node key and channel number
* use a key manager
the key manager does not export private keys or secrets.
It exports public keys, and points, and provide methods to sign
transaction.
There is just one exception: it does export revocation secrets, since
we need to send them back when we receive a commitment signature.
* key management: cache private keys and public keys
* add key manager to node parameters
* create an interface for key manager
and an implementation which keeps private keys locally
* generate a new BIP32 key path for each new channel
When we create a new channel we generate a new random BIP32 key path
with 128 bits of entropy
* use a `DirectedWeightedPseudograph`
Because we want a directed graph with multiple weighted edges between two
vertices, and loops allowed.
See discussion in [1] for more details.
* take node fee into account when finding route
Fees vary depending on the amount we want to send, so as a simplification
we use a default `DEFAULT_AMOUNT_MSAT`=`10000000` to compute edges weight.
This fixes#310.
* reuse the same graph for all payments
In `findRoute`, if we have specific updates to add/remove, we don't mutate
the main graph and create a copy instead.
[1]
http://jgrapht-users.107614.n3.nabble.com/Difference-between-a-directed-multigraph-and-a-directed-pseudograph-td4024788.html
Make `Commitment` return `ExpiryTooSmall` and `ExpiryTooBig` when
appropriate, and don't do the check in the `Relayer`.
Be more restrictive when sending HTLCs, so that counterparty doesn't
close the channel when a block just appeared and there is temporarily a
1-block discrepancy between two peers.
Proper management of `FinalExpiryTooSoon` in the payment handler.
On top of that, added more tests and simplified some.
Apparently `BidirectionalDijkstraShortestPath` and
`DirectedWeightedPseudograph` are incompatible, which made tests fail.
There was also a bug in channel pruning when we would remove *valid*
channels from the graph.
Because we want a directed graph with multiple weighted edges between two
vertices, and loops allowed.
See discussion in [1] for more details.
Also, followed @btcontract's suggestion of using a
`BidirectionalDijkstraShortestPath` instead of `DijkstraShortestPath`.
In `findRoute`, if we have specific updates to add/remove, we don't mutate
the main graph and create a copy instead.
[1]
http://jgrapht-users.107614.n3.nabble.com/Difference-between-a-directed-multigraph-and-a-directed-pseudograph-td4024788.html
* moved CoinUtils to eclair-core to expose conversion methods
Parsing and converting string amount to BtcAmount objects, and
displaying BtcAmount as well formatted string is a common use case.
Methods that were developed for the gui module should be exposed from
eclair-core so that they can be reused elsewhere.
* increased timeouts in integration tests
* have bitcoin wallet and watcher use a separate client
* return more information on channel opening
* removed `storedChannels` from `Peer` constructor
1) so that they can be garbage-collected
2) that was a memory leak because closed channel would stay forever
* OpenChannel now accepts a feerate param for the funding Tx
User should be able to override the fee rate of the funding tx that he
sends when he opens a channel. This custom fee is entered as a fee rate
in satoshi per byte, and converted to a fee rate per kw.
The default value of this fee rate does not change, and still aims for
the funding tx to be included in a block within the next 6 blocks,
estimation which is made through the FeeProvider class.
* reworked payment events
and made sure we send events even when `PaymentLifecycle` disappeared, e.g.
when we restart right after having sent a payment.
A `FailureMessage` should include a detailed description. A `transformForUser`
static method is also added to streamline the list of failures associated to a
`PaymentFailure`.
In the GUI, the payment notification shows a message for each failed attempts
when we receive their init message and check their features:
- if they set `initial_routing_sync` and `channel_range_queries` we do nothing, we should receive a
range query shorly
- if they support channel range queries we send a range query
* announcements are pruned before they are sent for `initial_routing_sync` (this was removed by #422)
* is now considered stale a channel that is older than 2 weeks and hasn't any `channel_update` younger than two weeks (again, before #422 we were more lax because of pre-validation pruning)
* pruning was rewritten without use of very expensive `exists` function
* we don't prune anymore on startup
* removed `ThrottleForwarder` and `WriteAckSender`, and handle both TCP read/write backpressure at the `TransportHandler` level, which is much more efficient (e.g. we don't serialize/encrypt outgoing data if OS buffer is already full, which saves RAM and CPU)
* added a simple priority management that reduces priority of routing announcements so that they don't block channel messages on `initial_routing_sync`
* call `doPublish` in `handleMutualClose`
That's more consistent with other closing scenarii, and we weren't
putting a `WatchConfirmed` in case of unexpected closing tx.
* store the unsigned closing tx along with sent `closing_signed`
So that we can identify txes based on txid when they are published,
instead of on their (malleable) signature.
* don't log publish error when tx is already in blockchain
* store the last signed closing tx during negotiation
And use it instead of our local commitment if channel fails before end of
negotiation.
* fixed `SYNCING`->`NEGOTIATING` transition
There were three bugs:
(1) we weren't re-sending our `shutdown`
(2) we were re-sending all previous `closing_signed` instead of restarting
the negotiation
(3) there was even a bug in (2) since
1aee6e8c21
On top of that, had to implement changes as per
https://github.com/lightningnetwork/lightning-rfc/pull/36.
Note that this is unfinished, as there is a corner case where fundee
reuses previous `closing_signed` to compute its next closing fee, even if
it was just disconnected for possibly a long time and network fees have
changed a lot in the meantime.
* watch for closing tx published in `OFFLINE` and `SYNCING`
* added a tx json serializer
* use a separate list for each attempted negotiation
This allow us to properly handle restarting a negotiation after a
reconnect.
The goal of this commit is to avoid recomputing a new
`DefaultDirectedWeightedGraph` for all payments.
Note that this doesn't take into account the fact that "edges between any
two vertices are <i>not</i> permitted". This is what makes tests fail.
This is done by using a `DefaultDirectedWeightedGraph` instead of a
`DefaultDirectedGraph`.
Fees vary depending on the amount we want to send, so as a simplification
we use a default `DEFAULT_AMOUNT_MSAT`=`10000000` to compute edges weight.
This fixes#310.
