* Added server address in ElectrumReady object
* Assigned remote address to variable to improve readability
* Checking that the master address exists in the addresses map
* set a minimum feerate-per-kw of 253 (fixes#602)
why 253 and not 250 since feerate-per-kw is feerate-per-kb / 250 and the minimum relay fee rate is 1000 satoshi/Kb ?
because bitcoin core uses neither the actual tx size in bytes or the tx weight to check fees, but a "virtual size" which is (3 * weight) / 4 ...
so we want :
fee > 1000 * virtual size
feerate-per-kw * weight > 1000 * (3 * weight / 4)
feerate_per-kw > 250 + 3000 / (4 * weight)
with a conservative minimum weight of 400, we get a minimum feerate_per-kw of 253
* set minimum fee rate to 2 satoshi/byte
users can still change it to 1 satoshi/byte
* use better weight estimations when computing fees
* test that tx fees are above min-relay-fee
* check that remote fee updates are above acceptable minimum
we need to check that their fee rate is always above our absolute minimum threshold
or we will end up with unrelayable txs
* fix ClaimHtlcSuccessTx weight computation
* channel tests: use actual minimum fee rate
test with our absolute minimum fee rate (253), it should be valid and anything below
sould be invalid and trigger and specific error
Because we keep sending them over and over.
Using `CacheBuilder.weakKeys` will cause the serialized messages to be
cleaned up when messages are garbage collected, hence there is no need
to set a maximum size.
* feerate: use satoshi/kb instead of satoshi/byte
* API fixup: convert input feerate from sat/bytes to sat/kw
* fixup: convert input feerate from sat/bytes to sat/kw
* add cleaner access to current feerate
implementation (blocks 2,6,12...) is not exposed, users will call getFeerate()
* fix feerate conversions
a kilobyte is 1000 bytes, not 1024 bytes (thanks @jimpo)
* revert commit 179dadc
keep this PR focused on 1 task only
* rename FeeratesPerKb to FeeratesPerKB
* reproduces bug decoding ipv4-mapped-as-ipv6 addresses
* handle IPv4-mapped addresses
`InetAddress.getByAddress` automatically converted IPv4-mapped addresses
into IPv4 addresses, which resulted in them being serialized as IPv4
addresses instead of IPv6 addresses, invalidating the signature.
We now use `Inet6Address.getByAddress` instead.
* added support for parsing tor2/tor3 addresses
Note that there are currently invalid announcements on mainnet due to
https://github.com/ElementsProject/lightning/pull/1175#pullrequestreview-111994441.
* support signing multiple identical htlcs
We previously resolved the commitment tx output based only on the
`pubkeyScript`, causing us to reuse the same output for multiple htlcs.
We now keep track of which commitment tx output has been used.
* resolve htlcs using the amount too
We may have htlcs with identical `payment_hash` + `cltv_expiry`, but
different amounts.
In that case we need to use the `amount` to differentiate and choose the
correct commitment output for each htlc.
In other cases, when there is no risk of confusion it is ok to only rely
on `pubkeyScript`.
When publishing delayed txes, we need to first watch the parent
transaction in order to know how many confirmations it has.
Electrum relies on hashes of `pubkeyScript`s in order to track
transactions.
In order to do this without having the parent transaction at hand,
we recompute the `pubkeyScript` from the child transaction witness data
and give it to Electrum.
But if the script was a `pay2wsh`, we were using the `redeemScript`
instead of computing the `pubkeyScript`.
This is the root cause of https://github.com/ACINQ/eclair-wallet/issues/17.
* Accept bech32 addresses
Our android wallet will be able to send funds to bech32 addresses
* improve parsing of base58/bech32 addresses
Return appropriate errors when a base58 address is parseable but on the wrong chain
* add test with invalid address (not parseable as base58 or bech32)
* fix invalid version test
* Enforce a minimum fee rate, with a default at 1 satoshi/byte
Same value as bitcoin core's minimum relay fee
* add `minFeeratePerByte` to `FallbackFeeProvider`
and require that `FeeratesPerByte` and `FeeratesPerKw` be always > 0
* add support for mainnet final pubkeyscript
* electrum: add addresses of electrumx servers on mainnet
* electrum: use chain hash to compute addresses and HD key paths
* store db files in a subdirectory of datadir
* add a 'catchall' around deserialization
* use chain-specific key derivation paths for channel keys
* fixed intermittently failing test (we were comparing timestamps...)
* parameters:
- set default `router-broadcast-interval` to 60s
- set default `mindepth-blocks` to 3 blocks
- removed deprecated setting `router-validate-interval`
- reduce fees: block target 1->2
- reduce `MIN_CLTV_EXPIRY` from 9 to 7
Default value in BOLT11 was indeed 9 blocks, but the absolute minimum
value computed in BOLT2 is 7 blocks.
- remove unused `default-feerate-per-kb`
- set default `max-htlc-value-in-flight-msat`=10mBTC
- set default `max-to-local-delay-blocks` to 2000 blocks
* Update README with instructions for mainnet
* Upgrade to bitcoin-lib 0.9.15 (#516)
* use fees from provider, not default ones
Previously we were only stealing the remote's main output when they publish a revoked commit, and were relying on a sufficiently high `channel_reserve` do deincentivize cheating.
In order to also steal the htlc outputs, we need to handle both cases:
- they only publish their revoked commit tx => we claim the htlc outputs directly from the commit tx
- they publish their revoked commit tx, and their 2nd-stage HTLCSuccessTx and HtlcTimeout txes => we claim the output of these htlcs tx
To do that, we need to be able to reconstruct htlc scripts (`htlcOffered` and `htlcReceived`), therefore we need to store `paymentHash` and `cltvExpiry` for each htlc we sign. Note that this won't be needed in the future when we have MAST.
* store `paymentHash` and `cltvExpiry` for each signed htlc
* spend htlc outputs with penalty txs
* added full integration tests on revoked scenario
add electrum router, which manages a set of client
primary client is the one on the longest chain, when a secondary client
has a chain that is longer than master + 2 it becomes the new master.
this will allow us to move away from "dead" electrum servers that are not
up to date with the blockchain.
electrum client: add 'get header' method
electrum: maintain a chain of headers for each client
and switch to the one with the longest chain
electrum: handle case when received header connects to our first header
it can happen when we connect to a server and ask for the last N headers
electrum: automatic reconnection
when we lose connection to our master client, we consider that we are
disconnected.
when we lose connection to a secondary client, we try to find an address
that is not used and connect to it. If there is no such address we wait
a bit and try to reconnect to the failing client
electrum: check that incoming header proof of work is valid
electrum router: migrate to Akka's FSM
electrum: fix match error for `ready` message
add missing copyright headers
move Blockchain to electrum package
electrum: simplify router
electrum client: fix handling of dead subscribers
electrum: move blockchain validation into electrum client
client will now send `ready` notifications and subscriptions messages only when it has a valid and
long enough blockchain
pass execution context as argument
reworked `ElectrumRouter` following
3dc1c2b61c82debeaed8d0d92238c0b5ee5c49c8
renamed `ElectrumRouter` -> `ElectrumMultiClient`
reformat
`var` -> `val`
electrum: rename multiclient -> pool + cleanup
* added a serializer for `UInt64` class
* added a serializer for `OutPoint` class
* use `txid` instead of `txhash` when serializing `OutPoint`
* added a simple serializer for class `InputInfo`
* set a configurable `maxPaymentFee` as safety
Sending a payment will not be attempted if the cheapest route found is
more expensive than this value. Default value is 3%.
This is meant as a protection mechanism, to protect against an
intermediate well-connected node to set outrageous fees.
* reduced default `fee-base-msat` to 1 sat
* (gui) using max fee from node params when sending payment from ui
Implementation should guarantee that in case of a
`BITCOIN_FUNDING_PUBLISH_FAILED` event, the funding tx will *never* be
published (see `commit` method in trait `EclairWallet`).
With that in mind, there is no need for a `ERR_FUNDING_PUBLISH_FAILED`
state, instead we can just permanently close the channel. Note that the
user will receive an error "couldn't publish funding tx".
As soon as we receive a valid closing signature, we will publish the
resulting closing tx instead of our commitment tx if we need to
immediately close the channel (before end of negotiation, e.g. in case
of errors, or in case the counterparty goes OFFLINE).
When the closing signature didn't correspond to one we sent ourselves, we
weren't properly recognizing the publishing tx and went into
`ERR_INFORMATION_LEAK` state.
CMD_CLOSE is now split it to commands:
* `CMD_CLOSE`: this command will succeed only if the current
channel state is in NORMAL, or if the channel hasn't yet been created.
* `CMD_FORCECLOSE`: the channel will publish its current local
commitment (or its best signed closing tx if it has one).
Using `CMD_FORCECLOSE` is more expensive and it incurs a delay before
funds are spendable, but this can be useful in some situations, for
example when the counterparty isn't responding anymore.
Added a new `forceclose` method to the API and a force close button in
the GUI.
(this fixes a regression caused by 24dadff625)
* restore the old node key path
use the same path as before the change in key management so node id will
remain the same after an upgrade
* add a non-regression test
we check that if the seed does not change, then the node id won't change
either, which could be a problem during a node upgrade.
* type-ified `ShortChannelId`
* removed unused `listUnspent` method and test
* updated sqlite version to 3.21.0.1
* ignore `ReadAck` in `PaymentLifecycle`
* 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.
* 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.
* 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.
* This is based on the `option-data-loss-protect` feature defined in BOLT 9.
* At reconnection, when the counterparty proves us that our commitment is outdated, we politely ask them to publish their commitment. This is done by adding a new state `WAIT_FOR_REMOTE_PUBLISH_FUTURE_COMMITMENT`, and introducing a new "future" remote commitment type, in addition to existing "current" and "next".
* Slightly changed the signature of `Helpers`.`claimRemoteCommitMainOutput` so that current/next/future commitments are all handled the same way.
* Made sure that we never publish our local commitment when we know it is outdated, as it would be a cheating attempt and would result in a total loss of funds.
* Support both optional/required modes for option `option_data_loss_protect`
* removed unused `WAITING_FOR_VALIDATION` state
* unwatch connection when peer is dequeued from `initial_routing_sync` waitlist
* Updated testnet electrum servers list
* Added error log in supervisor when throwable is caught
The default error logging does not log the stack.
* filter updates in one pass
* filter stale channels in one pass
* added `strategy` to supervisor logs
* add the downstream htlc to `Forward*` messages
* make `listPeers` return a `Map`
* use `Seq` instead of `List` in db trait, and implement using `Queue`s
Append is a O(1) in `Queue` and O(n) in `List`.
* use a `Map` to store unacked incoming messages
* used `Vector` instead of `List` in decryption
In order to gracefully handle cases when the counterparty goes online while we are in
the middle of processing payments, we need to explicitely ack all
`fulfill`/`fail`/`fail_malformed` messages.
We previously only acked `fulfill` messages.
Also, we now fail timed out htlcs at the right time, which is:
- for dust htlcs, when the commitment tx reaches `min_depth`
- for non-dust htlcs, when the htlc-timeout or claim-htlc-timeout tx
reaches `min_depth`
Moved preimage extraction to `Helper` file.
This fixes#376, #377 and #378.
We now use [akka tcp pull mode](https://doc.akka.io/docs/akka/2.5.3/scala/io-tcp.html#read-back-pressure-with-pull-mode) for both incoming and outgoing connections.
In combination with setting a relatively low value for `akka.io.tcp.max-received-message-size`, this results in less RAM consumption, in particular when validating a whole routing table.
Also improved the router:
- Removed the grouping of `channel_announcement` because batching is done lower in the stack, in the bitcoin json-rpc client. Channels are now validated as they arrive.
- Keep track of all origin peers for every announcement (instead of the first one), in order not to send back the same announcements to peers.
- Better choice of data structures, which increases constant time operation (but don't completely eliminate less efficient access)
- Reworked management of private/not-yet-announced channels
* (gui) added channel fees (base and proportional) and capacity to the list
of channels in network
* (gui) fixed issues with gui being updated from wrong threads
* channel capacity is now saved in network DB along with the tx id when
a channel is discovered. `ChannelDiscovered` now contains the capacity.
A compatibility check for the network DB is added in startup. This check is
separated from the node DB check because a network DB check failure is
less severe and the network DB file can be safely removed with no impact
on the node.
* store channel funding txid in network db
* directly load announcements from disk without re-validating them all
* use dedicated sqlite file for network announcements db
* re-send `ChannelDiscovered` and `NodeDiscovered` on startup
Also removed unused `ChannelDiscovered`.`capacity` field.
This should fix#415.
