* Initialize the database outside the node param constructor
* Do not create folders during StartupSpec
* Simplify syntax for instantiating test Databases
* Rework parameter passing to database initialization
* Force UTF-8 file encoding on all platform.
* Use bitcoin-lib 0.11, which embeds libsecp256k1
* Unit tests: generate dummy sig from 32 random bytes
We now use a version of bitcoin-lib which embeds JNI bindings for libsecp256k1,
and it will only sign data that is 32 bytes long (in Bitcoin and LN you always
sign data hashes, not the actual data).
* Use maven 3.6.0 and a different mirror
* RoutingSyncSpec: don't create databases at init time
We called nodeParams which created a new in-memory sqlite database everytime we created "fake" routing info
* don't spam with channel_updates at startup
Previous logic was very simple but naive:
- every time a channel_update changed we would send it out
- we would always make a new channel_update with the disabled flag set
at startup.
In case our node was simply restarted, this resulted in us re-sending a
channel_update with the disabled flag set, then a second one with the
disabled flag unset a few seconds later, for each public channel.
On top of that, this opened way to a bug: if reconnection is very fast,
then the two successive channel_update will have the same timestamp,
causing the router to not send the second one, which means that the
channel would be considered disabled by the network, and excluded from
payments.
The new logic is as follows:
- when we do NORMAL->NORMAL or NORMAL->OFFLINE or OFFLINE->NORMAL, we
send out the new channel_update if it has changed
- in all other case (e.g. WAIT_FOR_INIT_INTERNAL->OFFLINE) we do nothing
As a side effect, if we were connected to a peer, then we shut down
eclair, then the peer goes down, then we restart eclair: we will make a
new channel_update with the disabled flag set but we won't broadcast it.
If someone tries to make a payment to that node, we will return the
new channel_update with disabled flag set (and maybe the payer will then
broadcast that channel_update). So even in that corner case we are good.
* quick reconnection: bump channel_update timestamp
In case of a disconnection-reconnection, we first generate a
channel_update with disabled bit set, then after we reconnect we
generate a second channel_update with disabled bit not set.
If this happens very quickly, then both channel_updates will have the
same timestamp, and the second one will get ignored by the network.
A simple fix is to bump the second timestamp in this case.
* set channel_update refresh timer at reconnection
We only care about this timer when connected anyway. We also cancel it
when disconnecting.
This has several advantages:
- having a static task resulted in unnecessary refresh if the channel
got disconnected/reconnected in between 2 weeks
- better repartition of the channel_update refresh over time because at
startup all channels were generated at the same time causing all refresh
tasks to be synchronized
- less overhead for the scheduler (because we cancel refresh task for
offline channels (minor, but still)
Use bitcoin-lib v0.10 which has finally been synced to maven central.
Fix transactions unit test (the check in the test was using the whole locktime and not
the last 24 bits).
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.
* Upgrade to JDK11
Eclair can be built and used on Oracle JDK 1.8 or OpenJDK 11.
JavaFX is now embedded in eclair-node-gui and does not need to be installed separately.
* Install: update java download links
OpenJDK 11 is now our recommendation. Tell users to download java from https://jdk.java.net/11
* README: Rewrite installation instructions
* Correctly parse short channel id
* Add test for RPC APIs
* Put akka.http.version in parent project pom
Co-Authored-By: araspitzu <a.raspitzu@protonmail.com>
* Implement "GetHeaders" RPC call
* Add checkpoints and pow verification
* Don't resolve server address too soon
* Add testnet checkpoints
* Store headers in a sqlite wallet db
* Use 1.4 protocol
Request protocol version 1.4 (this is the default setting in Electrum wallet).
Retrieve and store all headers as binary blobs in bitcoin format.
* Insert headers in batch
* Optimize headers sync and persistence
We assume that there won't be a reorg of more that 2016 blocks (which
could be handled by publishing a new checkpoint) and persist our headers
except for the last 2016 we have received: when we restart, we will ask
our server for at least 2016 headers.
* Persists transactions
Transactions are persisted only when they've been verified (i.e. we've receive
a valid Merkle proof)
* Disable difficulty check on testnet and regtest
On testnet there can be difficulty adjustements even within a re-targeting window.
* Update checkpoints
* Use proper Ping message
`version` can not longer be sent as a ping as we did before.
* Don't ask for Merkle proofs for unconfirmed transactions
* Improve startup time
We now store a new checkpoint and headers up to that checkpoint as soon as our
best chain is 2016 + 500 blocks long
* Properly detect connection loss
* Update electrum mainnet servers list
Using the list from Electrum 3.3.2
* Don't open multiple connection to the same Electrum servers
We want to keep connection to 3 different servers, but when we have less than 3 different
addresses it's pointless to attempt to keep maintain 3 connections.
* updated to scalatest 3.0.5
* use scalatest runner instead of junit
Output is far more readable, and makes console (incl. travis) reports
actually usable.
Turned off test logs as error reporting is enough to figure out what
happens.
The only downside is that we can't use junit's categories to group
tests, like we did for docker related tests. We could use nested suites,
but that seems to be overkill so I just removed the categories. Users
will only have the possibility to either skip/run all tests.
* update scala-maven-plugin to 3.4.2
NB: This requires maven 3.5.4, which means that we currently need to
manually install maven on travis.
Also updated Docker java version to 8u181 (8u171 for compiling).
* 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
Service pattern matching code visually separates each method and
params to improve the code readability and maintenance. Route completion
is handle on a case by case basis, for each call. This enables better error
management and useful feedback to the caller.
Added custom rejections to handle cases where the given rpc method or
params are not found or not correct.
HTTP code should now be consistent with the error returned.
