We'll do the validation during construction of the runtime so that we
can safely use the AppPreRelease field externally without needing to
normalize it.
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.
This commit introduces the Signature interface which will be used by our
witness construction methods instead of passing in raw byte slices. This
will be used later to inject various kinds of mock signatures, e.g.
73-byte signatures for simulating worst-case witness weight.
It can happen that the receiver times out some htlcs of the set if it
took to long to complete. But because the sender's mission control is
now updated, it is worth to keep trying to send those shards again.
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.
With mpp it isn't possible anymore for findPath to determine that there
isn't enough local bandwidth. The full payment amount isn't known at
that point.
In a follow-up, this payment outcome can be reintroduced on a higher
level (payment lifecycle).
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.
This commit removes the overflowQueue from the link. We do so in order
to promote better UX for senders, so that HTLCs are failed faster when
the commitment is full. This gives the sender the opportunity to try
another, more open path, rather than perceive the HTLC as being stuck.
At the same time, we remove the total number of active goroutines in lnd
by a factor of N where N is the number of active channels.
