If a peer receives a channel reestablish message shortly after the
channel has been closed, it will resend its own channel reestablish
message. In the meantime the other peer could also have seen the channel
being closed and will also resend its own message. This leads to a
resend loop that never terminates.
To avoid two peers getting into this situation, we now allow only one
such resent message per conection.
There are different versions of clang-format being installed on
different versions of ubuntu that apparently produce different
results when formatting the proto files. This is likely too much
of a hurdle for new contributors to also manually install the
correct version of a command line tool just to format stuff.
This provides users an alternative over the SAFECOOKIE authentication
method, which may not be as useful if users are connecting to a remote
Tor sevrer due to lnd not being able to retrieve the cookie file.
In this commit, we update to a new version of `x/crypto` that drops
broken ARM assembly that can cause a segfault in systems like raspis.
The broken assembly was removed in this commit to the runtime:
8b774103d3.
Fixes#4052.
This commit migrates the payments in the database to a new structure
that allows for multiple htlcs per payments. The migration introduces a
new sub-bucket that contains a list of htlcs and moves the old single
htlc into that.
This commit extends the htlc fail info with the full failure reason that
was received over the wire. In a later commit, this info will also be
exposed on the rpc interface. Furthermore it serves as a building block
to make SendToRoute reliable across restarts.
This commit converts the database structure of a payment so that it can
not just store the last htlc attempt, but all attempts that have been
made. This is a preparation for mpp sending.
In addition to that, we now also persist the fail time of an htlc. In a
later commit, the full failure reason will be added as well.
A key change is made to the control tower interface. Previously the
control tower wasn't aware of individual htlc outcomes. The payment
remained in-flight with the latest attempt recorded, but an outcome was
only set when the payment finished. With this commit, the outcome of
every htlc is expected by the control tower and recorded in the
database.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
If we are the initiator, we check that our starting balance after
subtracting fees are not less than two times the default dust limit.
This commit adds a similar check for the non-initiator case, checking
that the remote party has a starting balance of reasonable size.
