* 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
* Update funding tx id value upon receiving ChannelStateChanged to WAIT_FOR_FUNIDNG_CONFIRMED
Currently the only time the "Funding tx id" text in GUI is updated is
upon receiving the ChannelRestored event, which means that if the GUI is
not restarted the value keeps showing "N/A".
This regression caused in 438d8e3 is what caused flaky tests during the past few days.
Calling `sender()` inside a `Props()` leads to undefined behavior.
* Add api call to check invoice/paymentRequest and return details in json
* Adding in API call to allow user to check route before making send call
* Added a serializer for route response
* Update README to include new checkinvoice and findroute API calls
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".
Both the GUI and the API should handle AskTimeoutException failures as
specific cases: GUI should ignore them, API should print a pretty
response. Increased ask timeout to 60s.
Akka http server responses with the same format as other errors.
Fixes#414 where eclair-cli would fail to parse the server
timeout response.
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`
