This release makes major performance improvements, includes a few bug fixes and several new features. It is fully compatible with 0.6.0 (and all previous versions of eclair).
Eclair now uses write-ahead logging in Sqlite (#1871). WAL is better suited to our DB access patterns, and is both much more performant and safer than the default rollback journal that we were using previously. > 1. WAL is significantly faster in most scenarios. > 2. WAL provides more concurrency as readers do not block writers and a writer does not block readers. > 3. Disk I/O operations tends to be more sequential using WAL. > 4. WAL uses many fewer fsync() operations.
This small change improves performance by more than 5x.
Invoice generation (#1878) and handling of incoming payments (#1880) are now processed in parallel, resulting in a higher throughput under load.
Improved Postgres support
This is the continuation of an effort to make PosgreSQL production-ready. The database schema has been reworked (#1866) and is now better organized, with appropriate types for timestamps (#1862). There have been several concurrency-related bug fixes.
We have also added
Upfront shutdown script
This release adds support for
It can be useful to protect against future hacks of your node, because the attacker won't be able to close your channels and send the funds to an address that he controls. However, it doesn't prevent the attacker from exfiltrating funds by paying lightning invoices, so you shouldn't rely on this feature alone to make your node hack-proof.
This option is disabled by default, but can be enabled in your
Transaction publishing improvements
This release reworks our internal transaction publishing architecture (see #1844 for details). The new architecture is more flexible, provides better logging and makes it easy to add dynamic fee bumping in the future for anchor output channels. It will also make it easier to automatically use CPFP to ensure funding transactions confirm before the 2016 blocks timeout is reached.
This release updates a few APIs:
Miscellaneous improvements and bug fixes
You will need
To import our signing key:
To verify the release file checksums and signatures:
Eclair builds are deterministic. To reproduce our builds, please use the following environment (*):
Use the following command to generate the eclair-node package:
That should generate
(*) You may be able to build the exact same artefacts with other operating systems or versions of JDK 11, we have not tried everything.
This release is fully compatible with eclair v0.6.0. You don't need to close your channels, just stop eclair, upgrade and restart.
a658fa26f Set version to 0.6.1-SNAPSHOT (#1813)
76894bd2e Add additional PRNG (#1774)
9a20aade0 Allow plugins to inject their own routes into API (#1805)
d437ea1ed Improve API plugin support (#1819)
98cae455f Rename pending_relay to pending_commands (#1822)
e8c33baf5 Various improvements and fixes (#1817)
f829a2e8c Add json type hints on channel data (#1824)
4dc2910c4 Make result set an iterable (#1823)
6f6c458a2 Add metrics on channels processing time (#1826)
43a89f865 Add a random delay before processing blocks (#1825)
af618bc44 Symmetrical HTLC limits (#1828)
dbecb28d9 Include routing hints in parseinvoice API call response (#1833)
2b6d564d2 Expose eclair datadir to plugins (#1837)
bd6bad1bf Fix eventually statements (#1835)
a7bb2c2b2 Do not store
BSC support (#1306)
Generalisation of ethereum family implementation to easily integrate BSC support.
last minute request to change some wording.
Add BSC support
This marks the first minor release of the 0.13.x cycle. This release is primarily a maintenance release including several bug fixes that didn't make it into 0.13.0, a series of fixes for introduced regressions, and a few small optimizations.
This release does not contain any database migrations.
Verifying the Release
In order to verify the release, you'll need to have
Once you have the required PGP keys, you can verify the release (assuming
You should see the following if the verification was successful:
That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the
Verifying the Release Timestamp
From this new version onwards, in addition time-stamping the git tag with OpenTimeStamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts:
Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:
Alternatively, the open timestamps website can be used to verify timestamps if one doesn't have a
These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.
Verifying the Release Binaries
Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved.
The release binaries are compiled with
Finally, you can also verify the tag itself with the following command:
Verifying the Docker Images
To verify the
Building the Contained Release
Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming
Additionally, it's now possible to use the enclosed
⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️