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.
