We remove the `feeThresholdSatoshis`/`feeProportionalMillionths` fields
and only keep the `feeAmount` field, which is renamed to `payToOpenFee`.
Fee aggregation is easier, we just sum the `payToOpenFee`.
We have a background task that periodically checks the blockchain to
detect unexpected transactions, as they could be cheating attempts.
When cooperatively closing a channel, in the `NEGOTIATING` state, peers
exchange signatures in order to converge on a feerate for the mutual
close transaction. Any transaction exchanged during this negotiation
process is valid and may be published, even if the counterparty dies
abruptly before converging, due to e.g. connectivity issues.
Therefore, the electrum background check needs to take those
transactions into account and not flag them as potential cheating
attempts. We already do that when we are in the `CLOSING` state, as
there may be competing mutual closes.
When the recipient is a direct peer, we can use the accurate knowledge
of our local channels instead of hard-coded MPP parameters to choose
the number of routes and the minimum route amount.
This change makes it possible to easily send all local funds in one
payment when we're directly connected to the recipient.
Only implemented for channel relay.
This is backward compatible, any errors returned by existing Phoenix
will be interpreted as generic errors and will return an
`UnknownNextPeer`.
Since Phoenix has a low number of channels and discards the whole public
network graph, we can be more aggressive with what we log without flooding
the logs.
This information will be very helpful to troubleshoot issues when users
send multipart payments.
This rule is redundant. Client app decides what ssl mode is used when
connecting to onion electrum servers. Some users do want to check
certificate when using tor.
For small channels we blindly accept feerate from funder.
This is a temporary fix to allow making payment in high fees
environment and will be removed when "anchor outputs" is deployed
When using MPP, if we can't find a route, we need to add an entry to the
DB. Otherwise when users query their payment status, nothing will be
returned which is a bad UX.
Fixes#1512
We were previously using an encoding that was incompatible with TLV.
We keep the old format, but also understand the channel version when provided
in a TLV field.
If the old format is provided, it will be preferred.
Instead of waiting for latest feerates from the fee provider at startup,
we use the previously stored feerates in the meantime, and proceed with
the initialization.
It makes sense because fees are asynchronous so we are "always late"
anyway.
