Fixes#481.
Prior to this commit, payments stored in the channel DB only kept a
record of the payment hash. This is a problem as the preimage is what
serves as proof of payment and a user should be able to look up this
value in the future (not just immediately after payment).
Instead of storing both the payment hash and the preimage, we store the
preimage only since the hash can be derrived from this using a SHA256.
In the RPC listpayments command, we now give the preimage in addition to
the payment hash.
We no longer need to hand off new channels that come online as the
chainWatcher will be persistent, and always have an active signal for
the entire lifetime of the channel.
This commit changes the name of the UpdateFee method to
UpdateChannelPolicy, to mimic the recent proto change.
It also reads and validates the passed TimeLockDelta,
and sends it to the gossiper for announcing it to the
network, and to the switch for updating the forwarding
policy of the links.
In this commit, we remove the blocks_till_open from
PendingChannelsResponse as in its current state, the values that are
assigned to this field don’t accurately reflect the naming. This has
caused a good bit of confusion amongst users lately. As a result, we’re
temporarily removing this field until we have proper incremental
notifications within the chain notifier.
In this commit we rename the lnrpc.PendingChannelRequest and
lnrpc.PendingChannelResponse to
lnrpc.PendingChannelsRequest/lnrpc.PendingChannelsResponse. We do this
as we strive to ensure that the naming scheme across the RPC interface
is consistent.
On testate as times the fee estimation can swing widely. As we
currently don’t yet use vsize everywhere internally, we’re forced to
manually scale to weight for the moment. If the returned fee rate is
too low, then it can cause our estimate to go to zero. This also has
the effect of meaning that the chanCloser doesn’t currently advance if
the initial starting fee is zero.
In this commit we fix a cosmetic bug within our RPC output for list
channels. We have a policy of always showing SAT instead of mSAT
externally. This led to user confusion, as if Alice or Bob ended up
with a fractional amount of satoshis, then the sum of trimmed amount
would be silently sent to miner’s fees. An example being: Alice ending
up with `8998999 mSAT` (`8998.999 SAT`). Bob similarly ends up with
`1001001 mSAT` (`1001.001 SAT`). `8998.999 + 1001.001 = 10000.0 SAT`.
However, we can't express that fractional amount (totaling `1 SAT`
across both commitment transactions) so it goes to miner fees.
To remedy this on the RPC interface level, we’ll now detect if we have
a dangling satoshi, and properly list it as going towards the miner fee
on the commitment transaction.
Fixes#468.
In this commit, we further constrain the candidacy for an “active”
channel. In addition to being present within the link, it *must* also
have the RemoteNextRevocation set. Otherwise, this indicates that we
haven’t yet processed a FundingLocked message for this channel.
In this commit, the relevant RPC’s have been modified to properly
parse, and pass through the new fee control related parameters for each
of the RPC’s.
For a calls to ListChannels we now only set the
ActiveChannel.Active=true if the link is found by the
htlcswitch. This is done to be able to make it possible
to tell if a newly opened channel has been added to
the htlcswitch, such that we can synchronize on this
during tests before we attempt to close the channel.
This helps catch issues in the RPC tests faster by putting a timeout
on all SendPayment requests. Otherwise, if a payment stalled, the test
would run until the test suite timeout, 10 minutes. Also simplifies
some code with a helper function and using SendPaymentSync where
possible.
In this commit we modify the primary InvoiceRegistry interface within
the package to instead return a direct value for LookupInvoice rather
than a pointer. This fixes an existing race condition wherein a caller
could modify or read the value of the returned invoice.
This commit changes the rpcserver to rely on the new zpay32
package, and support the new payment request options available
in the BOLT-11 invoice format.
