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.
