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.
If the closing tx is already in `mutualClosePublished`, it means that we
already know about it and don't need to re-handle it again. Everytime we
succesfully negotiate a mutual close, we end up publishing ourselves the
closing tx, and right after that we are notified of this tx by the
watcher. We always ended up with duplicates in the
`mutualClosePublished`field.
This fixes#568.
* 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
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".
