In this commit, we follow up to the prior commit by ensuring we won't
accept a co-op close request for a chennel with active HTLCs. When
creating a chanCloser for the first time, we'll check the set of HTLC's
and reject a request (by sending a wire error) if the target channel
still as active HTLC's.
In this commit, we fix a bug that at times could cause any dangling
HTLC's to be sent to miner's fees if a user attempted to close out a
channel cooperatively that still had pending HTLC's. We'll first prevent
this at the RPC level by rejecting any attempts to trigger a co-op
channel closure while a channel still have dangling HTLC's.
In this commit, we modify the existing invoice RPC macaroon permissions
to target a more specific entity: “invoices”. As a result of this
commit, once node operators update, they’ll need to regenerate their
readonly.macaroon as it now needs this additional entity encoded within
it.
In the prior commit, we added a new set of permissions and also a new
entity: “invoices”. We’ll add this set of entities to the read and
write permissions accordingly as well to ensure that the existing
macaroons have access to all the items that the invoice.macaroon does.
In this commit, we add a new invoicePermissions slice. This contains
all the permission that a holder of an invoice.macaroon is able to
access, and no others. We also include read and write access to
addresses as this may be useful from the PoV of a merchant or exchange.
In this commit, we raise the min channel size to 20k satoshis. This
will be evaluated before we check for dusty commitments. The goal of
this is to ensure ample room for fees at current, and future fee
levels.
In this commit, we fix a bug in the query routes RPC that could at
times lead to a panic. This would happen if the number of returned
routes was less than the number of expected routes. To remedy this,
we’ll return the minimum of the number of requested routes, and the
number of routes actually returned.
This commit adds wallet_best_block_timestamp to the gRPC interface.
This is done in order to allow clients to calculate progress while
lnd syncs to the blockchain. wallet_best_block_timestamp is exposed
via the GetInfo() rpc call. Additionally, IsSynced() returns the
WalletBestBlockTimestamp as the second value in the tuple
that is returned, providing additional detail when querying about the
status of the sync. The BtcWallet interface has also been updated
accordingly.
This commit was created to support the issue to
[Add progress bar for chain sync] (lightninglabs/lightning-app#10) in
lightning-app
This commit adds a new interface named NetInterface and two
implementations of it: RegularNet & TorProxyNet. These two structs
are used in config.go in an attempt to clean up the code and
abstract away the dialer and DNS functions.
This commit adds Tor support. Users can set the --TorSocks flag
to specify which port Tor's SOCKS5 proxy is listening on so that
lnd can connect to it. When this flag is set, ALL traffic gets
routed over Tor including DNS traffic. Special functions for
DNS lookups were added, and since Tor doesn't natively support
SRV requests, the proxySRV function routes connects us to
a DNS server via Tor and SRV requests can be issued directly
to the DNS server.
Co-authored-by: MeshCollider <dobsonsa68@gmail.com>
This commit reworks the macaroon authentication framework to use the
v2 macaroon format and bakery API. It also replaces the code in each
RPC method which calls the macaroon verifier with interceptors which
call the macaroon verifier instead. In addition, the operation
permissions are reworked to fit the new format of "allow" commands
(specifically, entity/operation permissions instead of method
permissions).
Since a ChannelPoint's funding txid can now be get/set as raw bytes or
a string, we first need to check what type it's currently set to before
accessing it.
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.
This commit modifies the relevant RPC’s to enforce the max payment size
as defined in BOLT-0002. With this commit the largest payment possible
is now 2^32 mSAT, or 4,294,967 satoshis.
This commit adds a new reqQuit channel within SendPayment. The inner
goroutine will use this channel to detect if the request itself has
exited or not. Without this method, we’d possible leak a goroutine if a
client never closed the payment stream.
