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.
