This commit introduces a new test case that asserts all of the witness
size constants currently in the codebase. We also reintroduce the
AcceptedHtlcSuccessWitnessSize and OfferedHtlcTimeoutWitnessSize
constants that were recently removed for the sake of completeness.
In asserting the witnes sizes, there were three uncovered discrepancies:
* OfferedHtlcSuccessWitnessSize overestimated by about 30% because it
included an extra signature in the calculation.
* ToLocalPenaltyWitnessSize was underestimated by one byte, because it
was missing the length byte for the OP_TRUE. This has implications
the watchtower protocol since the client and server are assumed to
share the same weight estimates used for signing. This commit keeps
the current behavior, with the intention of rolling out negotiation
for which weight estimate to use for a given session.
* AcceptedHtlcScriptSize was underestimated by one byte because it was
missing a length byte for the value 32 pushed on the stack when
asserting the preimage's length. This affects all AcceptedHtlc*
witness sizes.
In this commit, we remove the restriction surrounding the largest
invoices that we'll allow a user to create. After #3967 has landed,
users will be able to send in _aggregate_ a payment larger than the
current max HTLC size limit in the network. As a result, we can just
treat that value as the system's MTU, and allow users to request
payments it multiples of that MTU value.
A follow up to this PR at a later time will also allow wumbo _channels_.
However, that requires us to tweak the way we scale CSV values, as post
wumbo, there is no true channel size limit, only the
_local_ limit of a given node. We also need to implement a way for nodes
to signal to other nodes their accepted max channel size.
Modifies the payment session to launch additional pathfinding attempts
for lower amounts. If a single shot payment isn't possible, the goal is
to try to complete the payment using multiple htlcs. In previous
commits, the payment lifecycle has been prepared to deal with
partial-amount routes returned from the payment session. It will query
for additional shards if needed.
Additionally a new rpc payment parameter is added that controls the
maximum number of shards that will be used for the payment.
This commit fixes the inconsistency between the payment state as
reported by routerrpc.SendPayment/routerrpc.TrackPayment and the main
rpc ListPayments call.
In addition to that, payment state changes are now sent out for every
state change. This opens the door to user interfaces giving more
feedback to the user about the payment process. This is especially
interesting for multi-part payments.
Changes the grpc proto file, generates the protobuf, and
enables a queried way to retrieve payments in the rpc, where
backward compatibility is enforced by returning all payments
in the database by default. Adds a payment index field to
the returned payments of the rpc call.
Update the PendingChannel message from a bool to an enum to
differentiate between the case where the remote party initiated the
channel and we have no record of the channel initiator. The previous
field has not been included in a release of lnd, so we can replace the
field directly.
Move enum out of CloseSummary struct for more general use. This does
not change the encoding of the enum, and will only cause compile time
errors for existing clients. This enum has not been included in a
release yet, so we can make this move without much disruption.
There is an alternative in routerrpc now. It doesn't support REST yet,
but the main rpc SendPayment with its bidirectional streaming isn't
usable via REST either.
SendPaymentSync still serves REST users and cannot be deprecated yet.
This commit extends the RPC interface with GetNodeMetrics will contain
all graph node metrics in the future. Currently only holds betweennes
centrality per node.
The pending closing channels field was present to cover an edge case
where coperatively closed channels were closed before upgrade and
confirmed after the upgrade. This commit deprecates the field and adds
a warning log to cover these edge cases.
Exclusive group is a static property that doesn't need to be updated.
Requiring the exclusive group to be passed into UpdateParams creates a
burden for the caller to make sure they supply the existing group.
This change will be beneficial for users that bump anchor sweeps that
have exclusive groups set.
This change adds a set of errors to the peer struct returned by list
peers. A latest error boolean is added to allow for more succinct
default lncli responses.
