An often requested feature is to use the abandonchannel API in regular
builds and not only dev builds to get rid of stuck channels that had
their funding transaction invalidated.
The initial reason for putting the call behind the build flag was a
safety concern to make sure nobody uses this on active channels by
accident.
This log can be "spammy" while nodes throughout the network have yet to
upgrade to v0.13.0-beta, which includes several enhancements to prevent
the broadcast of zombie edges/updates.
Fixes#5325.
Corrects a problem introduced in #5281 that caused the synced_to_chain
flag in the GetInfo call to never become true when the router subsystem
is running in Neutrino mode (channel validation turned off).
Since the breacharbiter will publish an adjusted justice tx after
detecing a spend from the breached commitment, we could get into a race
where sometime it would not get the second spend before publication,
resulting in a deadlock on the publTx channel.
Now we instead wait for the publication of this adjusted tx before
notifying the second spend.
Fixes#5307.
Corrects some typos in the REST annotations for the routerrpc subserver.
Unfortunately these mistakes aren't caught by the current version of the
grpc-gateway library. But we intend to update to v2 soon which will
output alerts as mentioned in #5307.
This commit updates the btcd version to a more recent one in which a bug
was fixed that lead to SegWit and Taproot not being activated properly
on signet.
This update is not strictly necessary for lnd to work but we include it
in case anyone wants to install btcd through lnd's Makefile.
The Core devs decided to us the same bech32 HRP for Signet as is used
for the current Testnet3. This might be okay for on-chain addresses
since they are compatible in theory. But for invoices we want to use a
distinct HRP to distinguish testnet from signet.
Also see spec PR
https://github.com/lightningnetwork/lightning-rfc/pull/844 for more
information about the reasoning.
In some rare instances it can happen that the nodes don't find each
other again after one of them has been re-created and the other one has
been restarted in the SCB tests. By making sure the re-created has the
same P2P port again as before, we make sure they can connect to each
other again successfully for executing DLP.