See https://github.com/ACINQ/bitcoin-lib/pull/31.
We still have to use `Array[Byte]` for low-level cryptographic primitives, and `akka.util.ByteBuffer` for tcp connections. In order to reduce unnecessary copies, we used `ByteVector.view(...)` as much as possible.
Took the opportunity to do a project-wide optimize imports. We might as well do it now since pretty much all files have been touched already.
NB: temporarily use bitcoin-lib 0.10.1-SNAPSHOT because maven central is very slow and we can't access the recently release 0.10 for now.
Add methods to delete channels and tags channels as pruned in batch which is much
more efficient in sqlite.
* Network db: minor changes in unit tests
Test pruning a few 1000s channels at once.
* NetworkDb API: use Iterators and not Seq
It's more consistent with our code base.
There are several separate but related changes in this PR:
(a) Fast close on scenarii where we have nothing at stake (instead of going to `CLOSING` state). The previous process was not only slower (we had to wait for confirmations), but it never resolved when the funding tx hadn't been confirmed. Note that there is still an edge case where the funding tx never gets confirmed, we are fundee and we have something at stake (`push_msat` > 0).
(b) When *fundee*: after a timeout (5 days), if the funding tx hasn't reached `min_depth`, we cancel the channel.
(c) When *funder*: there is no timeout on the funding tx: however on restart, if we detect that our funding tx was doublespent, then we cancel the channel. Just because there is a doublespend doesn't mean that something malicious is going on: e.g. fee was to low, the tx was eventually removed from mempools and we just spent the inputs on something else).
Commits:
* set proper channelid in logs on restore
* fast close if we have nothing at stake
* added fundingTx and timestamp to DATA_WAIT_FOR_FUNDING_CONFIRMED
Also added migration codecs and tests
* implemented funding timeout for fundee
After a given delay, fundee will consider that the funding tx will never
confirm and cancels the channel.
Note that this doesn't apply to the funder, because our implementation
guarantees that we have sent out a funding tx, and the only way to be
sure that it will never be confirmed is that we double spend it. We just
can't rely on a timeout if we want to be safe.
* Electrum: detect if a wallet transaction has been double-spent
If it's in the mempool, or if it's been confirmed, then it's not double spent.
If it's not confirmed and not the mempool, we check if we have a transaction in
our wallet that sspends one of the inputs of our tx. If we find one, then it's been
double spent.
This will work with our funding txs, but not with their funding txs.
* fix regression with dataloss protection
The fast close causes a regression with dataloss protection, because
if we have nothing at stake we won't publish anything in case of
error (even if our peer asks us to).
This fixes#854.
