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>
Before this commit, we’d unnecessarily use a write transaction within
the FetchChannelEdgesByOutpoint. This is wasteful as the function only
actually reads items from the database, and doesn’t attempt any
mutations at all.
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.
This commit adds a FetchClosedChannel method to the
channeldb, which allows querying based on a known
channel point. This will be used in the nursery to
load channel close summaries, which can be used to
provide more accurate height hints when recovering
from failures.
In this commit, we add the WitnessCache sub-storage system of the
greater database. The WitnessCache is a persistent cache of all
witnesses we’ve encountered on the network. We’ll use this cache to
share any on-chain discoveries between active channels. Eventually
we’ll also use this to enforce the variant that a preimage is only to
be used ONCE on the network.
This commit adds the ChannelFlags field, of type
lnwire.FundingFlags, to the OpenChannel struct,
including serialization for database storage.
This is done to preserve the flags that were
sent during channel opening, currently used
to determine whether a channel should be made
public or not after opening.
In this commit, we fix an existing bug that arose due to incorrectly
crafting the key we use to store channel commitments. Before this
commit, we tried to copy to a slice that hadn’t been allocated yet. As
a result, the key would only have the 0x00 or 0x01 as its value. We fix
this by properly crafting the key using the built-in append function.
In this commit, we fix an existing bug wherein if we closed two
channels, then we were unable to read the channel state afterwards as
we deleted the enclosing bucket.
In this commit, we fix an existing bug wherein we failed to update the
channels state once we accepted a new commitment. As a result, after a
state transition, if the channel state was read from disk, values like
TotalMSatSent wouldn’t be properly updated.
In this commit we’ve extended the TestChannelStateTransition method to
exercise the new state transition related messages. This includes
ensuring that when we add a new dangling commitment, and then the
remote party revokes it, then the on-disk state is update accordingly.
In this commit, we update the CloseChannel method to respect the new
on-disk bucket based structure. Additionally, we now ensure that we
delete the new chainBucket.
In this commit, in addition to the renaming we’ve modified the behavior
of AdvanceCommitChainTail as follows: this method now will simply
atomically advance the commitment tail, set the new commitment to the
prior dangling commitment, and update the on-disk revocation log.
The macho expects the new revocation state to already be stored within
the channel. This method is to be called once the remote party revokes
their current commitment state.
In this commit, we add a new method: RemoteCommitChainTip. This method
allows callers to poll the database state to check if we have an
un-acked commitment for the remote party. If so, then it should be
retransmitted once a communication channel has been re-established with
the channel peer. This method will return ErrNoPendingCommit if we
don’t currently have a dangling commitment.
In this commit, we add a new method AppendRemoteCommitChain. This
method is meant to be used once we extend a new state to the remote
party, but before we actually transmit the CommitSig message. With this
method, we store a fully valid CommitDiff on disk which can be used in
the case that we need to retransmit the state to the party as they
didn’t fully receive it.
In this commit we finalized the structure of the CommitDiff struct by
adding a set of LogUpdates, and also a valid CommitSig message.
The LogUpdate struct houses a messages that were transmitted and
locked-in with the new commitment state. We include the LogIndex along
with the wire messages itself in order to be able to properly
reconstruct the update log upon restart.
The CommitSig message included should be transmitted after the set of
LogUpdates, and fully covers the new commitment state and any new (or
already present) HTLC’s that were included as part of the state.
In this commit, we modify the UpdateCommitment method to accept a full
ChannelCommitment rather than a new transaction, the sig, and a
ChannelDelta. This new structure of this method also takes advantage of
the new bucket structure of the storage schema. Additionally, this
method will now atomically swap in the new passed commitment to point
to the LocalCommitment value within the struct.
In this commit we add a new MarkAsOpen method to the OpenChannel
struct. This method replaces the existing MarkChannelAsOpen method
which targeted the database struct itself.
In this commit we comptely overhaul the existing storage of the
OpenChannel struct to use the new common serialization defined within
the codec.go file. Additionally, we’ve modified the structure of the
channel database on disk. Rather then use the existing prefix based
segmentation, everything is now bucket based. This has resulted in much
simpler and easier to follow code. The bucket progression is:
openChannelBucket -> nodeBucket -> chainBucket -> channelBucket. We add
a chainBucket as it’s possible that in the future we may have several
channels on distinct chains with a given node.
With the above changes, we’re able to delete much of the existing code
within the file, drastically reducing its size.
By adding these two fields, it is now possible to fully reconstruct the
channel’s update log from the set of HTLC’s stored on disk, as we now
properly note both the log index and HTLC index. Prior to this commit
we would simply start the new log index based on the amount of HTLC’s
that were present in the prior state.
In this commit, we restructure the OpenChannel struct to used two
distinct ChannelCommitments: one for the remote party, and one for the
local party. With this, we now partition the local state and the remote
state. Previously, we weren’t properly tracking the state of the remote
party. As a result, there were certain classes of failures we were
unable to properly recover from. With this separation, we can now
handle them, and the OpenChannel struct is slimmer and more
understandable.
In this commit we’ve added a new struct to the package:
ChannelCommitment. This sturct houses all the common data the comprises
a particular commitment state. This will soon replace the open fielded
commitmetn fields within the OpenChannel struct.
In this commit, we add a new files to the channeldb package: codec.go.
This file is similar to the way that serialization is done within the
lnwire package. The goal of this file is to reduce all the duplication
within the common serialization methods across the package.
In this commit htlc channeldb representation have been augmented
with onion blob field, and (de)serialisaion functions have been changed
to make the onion blob persistant.
This commit adds the method DisconnectBlockAtHeight to the channel
graph database, making it possible to "rewind" the database in case
a block is disconnected from the main chain. To accomplish this,
a prune log is introduced, making it possible to keep track of the
point in time where the database was pruned. This is necessary for
the case where lnd might wake up on a stale branch, and must "walk
backwards" on this branch after it finds a common block fro the
graph database and the new main chain.
