We are slowly dropping support for non-segwit outputs, as proposed in
https://github.com/lightningnetwork/lightning-rfc/pull/894
We can thus safely allow dust limits all the way down to 354 satoshis.
In very rare cases where dust_limit_satoshis is negotiated to a low value,
our peer may generate closing txs that will not correctly relay on the
bitcoin network due to dust relay policies.
When that happens, we detect it and force-close instead of completing the
mutual close flow.
It's useful to have the release notes directly inside the repository
instead of relying on Github: that lets for example users read them offline.
It also lets us fill the release notes every time we add relevant features
on `master` instead of having to do them all at once when we decide to make
a release.
When using Tor, your onion address is by default added to your
list of public addresses and advertised through the gossip layer
to allow peers to find your node and connect to it.
We now allow opting out of that mechanism by setting
`tor.publish-onion-address = false` in your `eclair.conf`.
This will ensure your onion address is not advertised, and peers
will not be able to connect to you unless you've connected to
them first.
We now query blockchain watchdogs over Tor when it's activated.
Some watchdogs are automatically disabled because they have no
support for Tor.
We also let users change the list of watchdogs that should be run
from their `eclair.conf`.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
It can be useful for newcomers to have a high-level view of the main
components in eclair. This will help them quickly find where they should
start digging into actual code to achieve what they want.
We're leaving a lot of details out to ensure this document stays up-to-date
and doesn't need to completely change every time we slightly rework internal
details of our architecture.
We keep the GetRoutingState API available in the router as it's useful to
query network information locally (or between actors), but we stop sending
that data to remote nodes.
We now use a regular release zip, and use it in the awseb bundle.
The default logback configuration now logs to a file, like
`eclair-node`, and we use a dedicated logback configuration for AWS
beanstalk.
By default the front reads the node secret key from the node seed in
the standard `.eclair` directory.
When we have a trusted relationship with some of our peers (business
relations, family members, our own mobile wallet, etc) it makes sense to
relax the feerate mismatch constraint.
This must be done per-node, to avoid leaving the gates open for attackers.
