In this commit, we remove a ton of unnecessary indentation in the
processRemoteAdds method. Before this commit, we had a switch statement
on the type of the entry. This was required before when the method was
generic, but now since we already know that it’s an Add, we no longer
require such a statement.
In this commit, we remove the DecodeHopIterator method from the
ChannelLinkConfig struct. We do this as we no longer use this method,
since we only ever use the DecodeHopIterators method now.
In this commit, we modify the msgStream struct to ensure that it has a
cap at which it’ll continue to buffer messages. Currently we have two
msgStream structs per peer: the first for the discovery messages, and
the second for any messages that modify channel state. Due to
inefficiencies in the current protocol for reconciling graph state upon
connection (just dump the entire damn thing), when a node first starts
up, this can lead to very high memory usage as all peers will
concurrently send their initial message dump which can be in the
thousands of messages on testate.
Our fix is simple: make the message stream into a _bounded_ message
stream. The newMsgStream function now has a new argument: bufSize.
Internally, we’ll take this bufSize and create more or less an internal
semaphore for the producer. Each time the producer gets a new message,
it’ll try and read an item from the channel. If the queue still has
size, then this will succeed immediately. If not, then we’ll block
until the consumer actually finishes processing a message and then
signals by sending a new item into the channel.
We choose an initial value of 1000. This was chosen as there’s already
a max limit of outstanding adds on the commitment, and a value of 1000
should allow any incoming messages to be safely flushed and processed
by the gossiper.
In this commit, we fix a quick in the main autopilot handling. If we’re
unable to establish a channel to a peer for w/e reason, then we’ll
disconnect the peer. With this tactic, we avoid unnecessarily building
up tens of peers for no reason at all.
In this commit, we fix an existing bug that would at times cause us to
spiral out of control and potentially created thousands of outbound
connections. Our fix is simple: limit the total number of outstanding
channel establishment attempts. Without this limit, we have no way to
bound the number of active goroutines.
Fixes#772.
In this commit, we update the pinned versions of lightning-onion as
well as btcwallet.
The newest lightning-onion instance adds some logging statements when
garbage collecting expired shared secret hashes.
The new btcwallet version fixes a recently introduced bug which would
cause us to remove all unman transactions on restart if the full node
new of any of them. Instead, we’ll now only remove these unmanned
transactions if it’s reported that the transactions were double spends,
or orphans.
In this commit we modify the storage location of the sphinx replay
database to be under the precise network, and not only the graph sub
directory. Before this commit, due to the usage of filepath.Dir(), the
db would lie under /graph/, rather than say, /graph/simnet.
In this commit, we fix an existing bug in the funding manager, that can
be triggered if the user is connecting to a node over Tor, and then
attempts to open a channel. An existing fix was added for the case that
the receiving node established the channel, but this now makes that case
symmetric.
In this commit, we fix a bug that was uncovered by the recent change to
lnwire.MilliSatoshi. Rather than manually compute the diff in fees,
we’ll directly compare the fee that is given against the fee that we
expect.
In this commit, we add an additional check within
validateCommitmentSanity due to the recent change to unsigned integers
for peer balances in the channel state machine. If after evaluation
(just applying HTLC updates), the balances are negative, then we’ll
return ErrBelowChanReserve.
In this commit, we add logic to account for an edge case in the
protocol. If they initiator if unable to pay the fees for a commitment,
then their *entire* output is meant to go to fees. The recent change to
properly interpret balances as unsigned integers (within the protocol)
let to the discovery of this missed edge case.
lnwire.MilliSatoshi is now a signed integer, as a result, we’ll return
a different error if our balances go to negative due to the inability
to pay a the set fee.
In this commit, we fix a bug introduced by the recent change of
lnwire.MilliSatoshi to be an unsigned integer. After this change an
integer underflow was left undetected, as a result we’ll now
momentarily cast to a signed integer in order to ensure that both sides
can pay the proper fee.
In this commit, we modify lnwire.MilliSatoshi to be an unsigned
integer. We do this as all values within the specification are meant to
be unsigned unless otherwise specified. Our usage of signed integers to
this date has caused some compatibility issues with the other
implementations, so this is the first step to reconciling these
compatibility issues.
In this commit, we modify the way we obtain the current best header
timestamp. In doing this, we fix an intermittent flake that would pop
up at times on the integration tests. This could occur as if the wallet
was lagging behind the chain backend for a re-org, then a hash that the
backend knew of, may not be known by the wallet.
To remedy this, we’ll take advantage of a recent change to btcwallet to
actually include the timestamp in its sync state.
In this commit, we update lnd to now access the deterministic
keychain.KeyRing struct in order to obtain our identity public key.
With this change, if the user recovers their wallet with the same seed,
then they’ll have access to the same prior node identity. This change
also makes it easy for us to support node key rotation in the future by
bumping up our requested index.
In this commit, we modify the mechanics of the wallet to only allow
derivation of segwit-like addresses. Additionally, the ConfirmedBalance
method on the WalletController now only has a single argument, as it’s
assumed that the wallet is itself only concerned with segwit outputs.
In this commit, we modify the way we generate the secrets for
revocation roots to be fully deterministic. Rather than use a special
key and derive all sub-roots from that (mixing in some “salts”), we’ll
use the proper keychain.KeyFamily instead. This ensures that given a
static description of the channel, we’re able to re-derive our
revocation root properly.
In this commit, we modify the funding flow process to obtain all keys
necessary from the keychain.KeyRing interface. This ensure that all
keys we generate are fully deterministic.
In this commit, we remove references to raw keys from the main
ChannelConfig struct and instead replace it with usage of
keychain.KeyDescriptor. We do this, as the ChannelConfig as it stands
is a near complete static description of a channel. In the future, it
will be possible to export these static descriptions as backups. We
prefer the KeyDescriptor of a plain PublicKey, as the KeyLocator
portion of the struct allows a stateless signer to re-derive the keys
as needed when signing.
In this commit, we update the SignDescriptor struct to instead use the
keychain.KeyDescriptor struct inplace of a raw public key. We do this
as this allows for a recovery mode, where the caller doesn’t know what
key was used exactly, but remembers the precise KeyDescriptor. A
stateless signer is still able to re-derive the proper key, as it’s
given the full path.
The new version of the internal core of btcwallet now uses KeyScopes
rather than address types to derive particular addresses. As a result,
in this commit, we update our API usage to ensure that proper addresses
are still derived.
In this commit, we remove two methods from the WalletController
interface which were previously used by the funding reservation process
(NewRawKey) and the p2p network (FetchRootKey) in order to derive
various keys for operation. This methods are no longer necessary as the
KeyRing interface implements the functionality in a deterministic
manner.
In this commit, we add a new package to lnd: the keychain package. The
role of this package is to house all the interfaces that lnd will use
to generate the various keys it needs to create contracts and operate
within the network. Additionally, we also use this package to define a
deterministic key derivation scheme, that can be implemented by any
software/hardware that partially understands BIP43-like derivation.
The first version (v0) of the keychain schema is very simple. We re-use
BIP43, with a slight twist. Re-using BIP43 lets us leverage all the
existing libraries out there as far as compatibility. The purpose used
is 1017, and the coin type, the particular coin type of the chain where
the keys are meant to be used. Within our schema, we define multiple
“key families”. Each key family is actually just manifested as a new
“account” within the BIP44/43 family. With this schema, if we have
static description of the keys used within a channel, given the seed,
and the “KeyLocator”, we can re-derive all keys necessary be able to
re-sign for the channel.
In this commit, we add a new method to the RPC service:
ForwardingHistory. This method will allow callers to query for the
completed payment circuits in a particular time slice, skip a series of
events, and also paginate within a time slice.
In this commit, we extend the switch as is, to record details
concerning settled payment circuits. To do this, we introduce a new
interface to the package: the ForwardingLog. This is a tiny interface
that simply lets us abstract away the details of the storage backing of
the forwarding log.
Each time we receive a successful HTLC settle, we’ll log the full
details (chans, fees, time) as a pending forwarding log entry. Every 15
seconds, we’ll then batch flush out these entries to disk. When we’re
exiting, we’ll try to flush out all entries to ensure everything gets
recorded to disk.
We’ll need this value within the link+switch in order to fully populate
the forwarding event that will be generated if this HTLC circuit is
successfully completed.
In this commit, we add the incoming+outgoing amounts if the HTLC’s that
the payment circuit consists of. With these new fields, we’ll be able
to populate the forwarding event log once the payment circuit has been
successfully completed.
In this commit, we add a new storage namespace to channeldb: the
ForwardingLog. This log will be used by higher level sub-systems to log
each successfully completed HTLC. Each payment circuit will be
summarized as a “ForwardingEvent”. A series of events can then be
queried via a time slice query. In a time slice query, the caller
specifies a time range, a number of events to skip, and the max number
of events to return. Each query will return the index of the final
item. As we have a max number of events we’ll return in a response,
callers may need to use this last offset index to seek further by
skipping that number of entries. Combining these fields, callers are
able to query the time series, skipping an arbitrary amount of events,
and capping the max number of returned events.
Olaoluwa Osuntokun