This commit adds a new method to the OpenChannel struct:
InsertNextRevocation. This functionality is required in order to
properly implement the new funding workflow and commitment transaction
state machine.
In the prior state machine, we utilized the “initial revocation window”
which would provide both sides with the necessary revocation keys that
they needed to create new commitment states. The version of the
commitment state machine within the specification has been simplified a
bit, and instead essentially incorporates a revocation window of 1. The
window is initially filled at the _opening_ of the commitment
transaction, then never extended, only “slid down” from there on.
This commit modifies the HTLC struct within the channeldb struct in
order to accommodate the additional storage that’s now required as a
result of the change to 2-of-2 HTLC covenant transactions within the
commitment transaction.
This commit is the next phase in a rather major overhaul of the
OpenChannel struct. With this commit we remove the old ours vs theirs
semantics with channel related state variables, and instead encapsulate
all local vs remote state into a ChannelConfig structure for each party
within the channel.
This commit introduces two new structs to the channeled package:
ChannelConfig and ChannelConstraints.
The ChannelConfig struct will eliminate many of the fields on the
OpenChannel struct (ours vs theirs), in favor of having a single config
for both sides (local and remote).
The ChannelConstraints struct will house the channel flow control and
HTLC policies for both sides. The fields of this struct will be used to
control the flow of HTLC’s within the channel. In the occasion that any
of these constraints are violated, either the connection, or the
channel entirely is to be failed.
This commit removes a database migration that was added to fix a bug
introduced within the first alpha release. This migration is no longer
needed as the underlying database scheme has changed since then.
This commit adds a new field to the CommitSig message: HtlcSigs. This
new field will house signatures for each of the HTLC’s on the newly
created commitment state. This addition allows us to implement the new
commitment transaction structure outlined within the specification
which modifies HTLC’s such that the claiming process is now a two-phase
process. The first state transitions an HTLC to the delay+claim state,
and the second state (after the delay has passed) allows the
broadcaster of the commitment transaction to sweep the HTLC’s.
Fixes#61.
This commit modifies the readElement and writeElement functions to add
the capability of reading/writing a slice of btcec.Signature. This new
case is required for the upcoming commit which will modify the
CommitSig message to include a field which houses signatures of reach
HTLC on the commitment transaction.
This commit adds the new set of single funder messages from the
specification. As a result, after this commit and a follow up, all of
our messages will directly line up with those that are detailed within
the specification.
The new set of funding messages are very similar to our prior ones,
aside from the main difference of the addition of several channel level
constraints that give nodes control over their exposure, throughput,
and other values.
This commit modifies the RevokeAndAck message in order to bring it more
in line with the current draft of the specification. The prior version
was based on a version that used a revocation hash for HTLC’s and a
revocation key for commitment outputs. The current commitment design
uses revocation keys uniformly throughout.
This commit removes the original single funder wire messages as they’ve
now been deprecated by the new commitment and HTLC structure within the
latest draft of the specification.
In previous commits we have intoduced the onion errors. Some of this
errors include lnwire.ChannelUpdate message. In order to change
topology accordingly to the received error, from nodes where failure
have occured, we have to propogate the update to the router subsystem.
In this commit daemon have been changed to set the proper hooks in the
channel link and switch subsystems so that they could send and receive
encrypted onion errors.
Within the network, it's important that when an HTLC forwarding failure
occurs, the recipient is notified in a timely manner in order to ensure
that errors are graceful and not unknown. For that reason with
accordance to BOLT №4 onion failure obfuscation have been added.
In this commit BOLT#4 specification message have been added to the
lnwire package. This messsage is needed in order to notify payment
sender that forwarding node unable to parse the onion blob.
In this commit onion routing error from BOLT#4 have been added, the
initial error construction have been splitted on two parts: The first
part which contains the actual data will reside inside the lnwire
package because it contains all necessary function to decode/encode
the data. The second part obfuscation and hmac checking will resides
inside the lighting-onion package because it requires the key
generation.
The latest builds of neutrino and btcwallet include a number of
performance optimizations that should speed up the sync of neutrino
nodes while ensuring all the pessary data is in place for re-org
safety.
This commit fixes a possible panic within the funding manger’s workflow
for pending channels. We now ensure that the local discovery signal
retrieved from the localDiscoverySignals map is always non-nil.
Otherwise, we risk a server panic in the case that a node retransmits
the FundingLocked message after a channel has been fully processed, or
even just sends a FundingLocked message for a non-existent channel.
This commit adds the possibility for the initiator of a
channel to send the update_fee message, as specified
in BOLT#2. After the message is sent and both parties
have committed to the updated fee, all new commitment
messages in the channel will use the specified fee.
This new build of lightning-onion includes the routines necessary to
implement the encryption and decryption of HTLC errors as defined
within the specification.
Support for regtest allows us to create integration tests to verify
interoperability with other implementations. This seems to work, and
allows to connect to `btcd` and indirectly to `bitcoind` so we can run
lnd on the same network as eclair and c-lightning.
For details about my integration framework check this repo:
cdecker/lightning-integration
A rather nasty re-org related bug was recently fixed in the upstream
version of roasbeef’s btcwallet. In order to fix this within the main
lnd build, we update the glide files such that the latest changes will
be pulled in.
This commit fixes a minor bug in the goroutine that’s launched to check
the sync status of a particular node. Previously, the goroutine could
end up infinitely stuck on a send as once the chain has been detected
as synced, it didn't exit.
We fix this now by ensure that the goroutine always terminates after
the initial notification to the caller. Additionally, we not ensure
that both the internal and exterior goroutine are both reading off of
the peer’s quit channel.
If an HTLC’s value is below a node’s dust limit, the amount for that
HTLC should be applied to to the fee used for the channel’s commitment
transaction.
