Using `fr.acinq.bitcoin.scala` package prevents confusion with the
bitcoin-kmp packages, and lets us use those 2 libraries at the same
time in the same project.
We previously made a single payment attempt per trampoline fee.
Since our channel selection for the first attempt is deterministic, if we
encountered a local failure with that channel, the retries with higher
trampoline fees were hitting the exact same error, whereas we should
instead try a different channel.
The spec defines `max_accepted_htlcs` and `max_htlc_value_in_flight_msat`
to let nodes reduce their exposure to pending HTLCs. This only applies to
received HTLCs, and we use the remote peer's values for outgoing HTLCs.
But when we're more restrictive than our peer, it makes sense to apply our
limits to outgoing HTLCs as well.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
* Use secp256k1-kmp
We get rid of our old JNI wrapper and switch to bitcoin-lib 0.18 which is based on secp256k1-kmp.
This will give us a consistent secp256k1 library on all our apps (since secp256k1-kmp also provides an Android library).
We also switch from spongycastle to bouncycastle (bitcoin-lib 0.18 uses bouncycastle).
* Set version to SNAPSHOT
Co-authored-by: dpad85 <5765435+dpad85@users.noreply.github.com>
This will allow us to use this key as our static payment point for static-remote-key channels.
We use the BIP84 address for this key as our single address.
The routing hint we get in a Bolt 11 invoice may be obsolete when we attempt
the payment: one of the nodes in the route may have updated his relay fees.
Since this affects a private channel that is not kept in the routing graph,
we need to update the routing hints before injecting them in the router.
This was already done in `PaymentLifecycle` with automatic retries, but when
using MPP we retried in the `MultiPartPaymentLifecycle` instead of inside
the `PaymentLifecycle`, so we need to handle routing hints updates there.
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.
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
