The bit has been reused for zeroconf and there is a dependency on
scid_alias, which causes issues with lnd 0.15.1-beta.
We just change the bit, which will reflect in our invoices (for
receiving). For receiving, we check both old and new bits for backward
compatiblity.
Cherry-picked from `39f83ab2a1dce07ea783488a9709c43f37b6966c` of branch
`android-phoenix-trampoline-bit`. This is a hotfix for version
0.4.15-android-phoenix so that we don't embed unrelated changes.
We add a new TLV-compatible field to `funding_signed`/`commit_sig` and send additional commitment signatures for a set of feerates (1, 2, 5, 10 sat/B) (only when there are no htlcs).
We also gracefully handle the case where remote decides to use one of those additional signatures to unilaterally close the channel. This creates yet another remote-close scenario, named _custom_, on top of the existing with _current_/_next_/_future_.
Note that:
- since we use static remote key, there isn't anything to do in case of a custom close, since there are no htlcs
- codecs haven't been updated, there is no need.
Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
PhoenixAndroidLegacyMigrate is a message to signal migration readiness.
PhoenixAndroidLegacyMigrateResponse is the response confirming that the
peer acknowledges that this phoenix app is ready to migrate.
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.
