In this commit, we add recognition of the data loss protected feature
bit. We already implement the full feature set, but then never added the
bit to our set of known features.
In this commit, we fix a minor deviation in our implementation from the
specification. Before if we encountered an unknown error type, we would
disconnect the peer. Instead, we’ll now just continue along parsing the
remainder of the messages. This was flared up recently by some
c-lightning related incompatibilities that emerged on main net.
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 replace all instances of *btcec.PublicKey within the
announcement messages with a simple [33]byte. We do this as usually we
don’t need to immediately validate an announcement, therefore we can
avoid the scalar multiplications during decoding.
In this commit, we add a new signature type. We’ll use this type to
avoid fully decoding a signature on the wire into a btcec.Signature.
This type is only really needed when we need to do signature
validation, as a result, always encoding it is a waste. Several helper
methods have been added to the new struct in order to ensure that we
can use it in the existing codebase without substantial issues.
This commit adds the `lnnet` package which contains an
implementation of the newly created LightningNet interface which
multiplexes the Dial and DNS-related functions to use net
by default and torsvc if a flag is specified. This modularization
makes for cleaner code.
This commit alters the NodeAlias String method to trim null-bytes from
the end of the alias. This is helpful for presentation in contexts such
as the GetInfo response.
In this commit, we add additional detail in the error return hen were’e
unable to properly decode an encapsulated error. This additional
logging was added with the goal of being able to track down a lingering
bug, where at times lnd cannot decode a TemporaryChannelFailure
message.
This changes the circuit map internals and API to reference circuits
by a primary key of (channel ID, HTLC ID) instead of paymnet
hash. This is because each circuit has a unique offered HTLC, but
there may be multiple circuits for a payment hash with different
source or destination channels.
In this commit, we add a new type to the lnwire package:
ChanUpdateFlag. This type represent the bitfield that’s used within the
ChannelUpdate message to give additional details as how the message
should be interpreted.
In this commit we correct an off by one error on the Shutdown and
ClosingSigned message types. Additionally, we fix an error related to
the numbering of the UpdateFee message. With this we, gain proper
compatibility with the other implementations when it comes to
commitment hygiene, and also the cooperative closure process.
Early in the lifetime of the project here were a few files we either
copied entirely, or used as the basis for code within lnd. Before this
PR, this was not recognized by retaining the original copyright. With
this commit, we remedy that by explicitly noting the copyright in the
relevant files.
Fixes#423.
In this commit, we add support within lnwire for the optional dataloss
fields in ChannelReestablish. With these fields, it’s possible to:
verify that the remote node really knows of the state of our prior
local commitment, and also that they’ve sent us the current commitment
point for their current state.
In the event of dataloss, it’s possible for the party which lost data
to claim their commitment output in the remote party’s commitment if
they broadcast their current commitment transaction.
In this commit, we begin implementing the latest spec change to reduce
the attack surface on online channels. In this commit, we introduce a
distinct HTLC base point which will be used to sign the second-level
HTLC transactions for each active HLTC on the commitment transaction of
the remote node. With this, we allow the commitment key to remain
offline, as it isn’t needed in routine channel updates, unless we need
to go to chain.
For Part 1 of Issue #275. Create isolated private struct in
networkHandler goroutine that will de-duplicate
announcements added to the batch. The struct contains maps
for each of channel announcements, channel updates, and
node announcements to keep track of unique announcements.
The struct has a Reset method to reset stored announcements, an
AddMsg(lnwire.Message) method to add a new message to the current
batch, and a Batch method to return the set of de-duplicated
announcements.
Also fix a few minor typos.
In this commit the reestablish message have been added, which serves as
channel state synchronization message. Before exchanging the messages
for particular channel peers have to send it to each other as the
first message in order to be sure that non of the updates have been
lost because of the previous disconnect.
In this commit we add a new type to the lnwire package: FundingFlag.
This type will serve as an enum to describe the possible flags that can
be used within the ChannelFlags field in the OpenChannel struct.
We also define the first assigned flag: FFAnnounceChannel, which
indicates if the initiator of the funding flow wishes to announce the
channel to the greater network.
This is a rewrite of feature vectors in lnwire. This has a few
benefits:
1) a simpler interface
2) separate structs for a plain set of feature bits and a feature
vector with associated feature names
their respective feature sets
3) loosened requirements that bits MUST be assigned in pairs
4) fix endianness of encoding/decoding
This commit fixes an incorrectly calculated size of a
*FeatureVector in the serializedSize() function. go-fuzz
found that when calling NewFeatureVectorFromReader, if
a flag is invalid, it is not added to f.flags. However,
it will skip the index that wasn't included. This
becomes a problem when serializedSize() calculates the
length of f.flags via len() which can lead to an index
out of range since certain flags may be missing.
This commit fixes an existing deviation in the way we encode+decode the
addresses within the NodeAnnouncement message with that of the
specification. Prior to this commit, we would encode the _number_ of
addresses, rather than the number of bytes it takes to encode all the
addresses.
In this commit, we fix this mistake by properly writing out the total
number of bytes, modifying our parsing to take account of this new
encoding.
This commit fixes an existing, unnoticed bug within the lnwire.
NewChanIDFromOutPoint function. Two lingering issues cause the function
to not do anything at all, meaning that the channel ID, would be the
exact same as the actual txid passed in.
The first issue was that the xorTxid function wasn’t actually XOR’ing
the last two bytes. This was due to the fact that the function wasn’t
taking a pointer to the target ChannelID, meaning that the mutation
wouldn’t be seen outside of the scope of the function. Second, we had
our slicing reversed, rather than buf[30:], we were using buf[:30],
meaning that we were weren’t properly filling the buffer with the lower
2-bytes of the passed index.
This commit modifies the main test loop within
TestChannelIDOutPointConversion stricter. With this commit, we now
ensure that the conversion function actually does _something_. This is
the first in a series of commits to fix a recently discovered bug
within the outpoint to channel ID conversion routines.
This is a very simple bug that go-fuzz found. If length of an address
within CloseSigned is greater than 34, a runtime error: slice bounds out
of range happens. An error should be returned instead.
In this commit we reverse the ordering of the MinAcceptDepth and
HltcMinimum fields within the AcceptChannel message. Previously, the
order of these two fields were reversed, meaning the remote peer
would’ve attempted to parse the MinAcceptDepth (as we intended), as
part of the HtlcMinimum, leading to a garbage value.
This commit fixes a diversion from the way the UpdateAddHTLC message is
defined within the specification. We had the HTLC expiry value in the
wrong place on the wire, which meant that we couldn’t parse the
messages as sent by the other LN implementations.
This corrects the fuzz test in TestLightningWireProtocol for
MsgCommitSig to avoid creating an empty slice since the decoded message
only creates a slice when there are greater than zero signatures and an
empty slice is not considered equal to a nil slice under reflection.
This can be tested by running the TestLightningWireProtocol 1000 times
in a loop with and without this change.
This commit does away with the ErrorCode field in order to ensure that
we’re properly compatible with BOLT-0002. In the future the error code
field may be re-introduced as it’s much easier to check against an
internet error rather than interpret a byte slice describing the error.
This commit modifies the NodeAnnouncement message to ensure that it
matches the current spec ordering. The spec was recently modified to
place the feature vector first to allow for future changes to the
fields to be forwards compatible.
This commit updates the encoding/decoding for the onion errors to
properly match BOLT-0004. This commit does to major things: we increase
the max message size to 256 bytes to account for recent modifications
to the ChannelUpdate message, and also fold in the error code into the
failure message encapsulation itself.
This commit adds a new type to the lnwire package: MilliSatoshi. A
milli-satoshi is simply 1/1000th of a satoshi, and will be used for all
internal accounting when sending payments, calculating fees, updating
commitment state, etc. Two helper methods are added: ToBTC(), and
ToSatoshis() to make manipulation of the values easy.
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 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.
This commit updates the OnionPacketSize constant in order to reflect
the size of the onion payload as a result of the recent changes to the
sphinx packet format in the specification.
This commit gives the start for making the htlc manager and htlc switch
testable. The testability of htlc switch have been achieved by mocking
all external subsystems. The concrete list of updates:
1. create standalone package for htlc switch.
2. add "ChannelLink" interface, which represent the previous htlc link.
3. add "Peer" interface, which represent the remote node inside our
subsystem.
4. add htlc switch config to htlc switch susbystem, which stores the
handlers which are not elongs to any of the above interfaces.
With this commit we are able test htlc switch even without having
the concrete implementation of Peer, ChannelLink structures, they will
be added later.
This commit changes the cooperative channel close workflow to comply
with the latest spec. This adds steps to handle and send shutdown
messages as well as moving responsibility for sending the channel close
message from the initiator to the responder.
This commit fixes a deviant in the way we serialize and deserialize the
node announcement message from that which is currently in the spec.
Before this commit we reversed the order of features and addresses.
Instead, on the wire, features should come _before_ the addresses.
We also add a new temporary feature bit to ensure nodes that don’t
directly connect to each other if they don’t have this new update.
However, this will also partition any current tests nets when new nodes
join them as the digest signed has changed, therefore invalidating any
older messages.
Fixes#207.
This commit modifies ReadMessage to no longer return the total bytes
read as this value will now be calculated at a higher level. The
io.Reader that’s passed to ReadMessage is expected to contain the
_entire_ message rather than be a pointer into a stream that contains
the message itself.
This commit does away with all the old manual message equality tests
and replace it with a single property-based test that uses the
testing/quick package. This test uses a single scenario which MUST hold
for all the messages type and all possible messages generated for those
types. As a result we are able to do away with all the prior manually
generated test data as the fuzzer to scan the input space looking for a
message that violates the scenario.
This commit abandons our old bitcoin inspired message header and
replaces it with the bare type-only message headers that’s currently
used within the draft specification. As a result the message header now
consists of only 2-bytes for the message type, then actual payload
itself. With this change, the daemon will now need to switch to a
purely message based wire protocol in order to be able to handle the
extra data that can be extended to arbitrary messages.
This commit fixes a bug lingering in the decoding of the feature
vectors which was masked by the prior method of reading the _entire_
message from the stream before parsing it. The issue was that
performing a zero-byte Read on an io.Reader that’s purely streaming
will result in an indefinite block. We fix this bug by properly using
io.ReadFull in this context.
This commit modifies the Message interface to convert the Command
method to a MsgType method that uses a new set of message type for all
the defined messages. These new messages types nearly exactly match the
message types used within the current draft of the BOLT specifications.
This commit revues the Validate method from the Message interface as
the method is no longer used and is a relic from an older version of
the codebase.
This commit implements the new ping/pong messages along with their new
behavior. The new set of ping/pong messages allow clients to generate
fake cover traffic as the ping messages tells the pong message how many
bytes to included and can also be padded itself.
This commit does to things: moves the prior ShortChannelID struct into
a new short_channel_id.go file, and also implements the new ChannelID’s
currently used within he specification.
These new ID’s are 32-bytes in length and used during initial channel
funding as well as during normal channel updates. During initial
channel funding, the ID is to be a random 32-byte string, while once
normal channel operation has began, the ID is to be (txid XOR index),
where index is the index of the funding outpoint.
Change the name of fields of messages which are belong to the discovery
subsystem in a such way so they were the same with the names that are
defined in the specification.
In this commit announcement signature message has been added which is
needed when peers want to announce their channel to the rest of the
network. This message acts as half proof carrier, nodes exchanges
their half proofs with each other and after that they are able to
construct the full proof.
This commit modifies address handling in the NodeAnnouncement struct,
switching from net.TCPAddr to []net.Addr. This enables more flexible
address handling with multiple types and multiple addresses for each
node. This commit addresses the first part of issue #131 .
This commit modifies the ChannelUpdateAnnouncement to rename the Expiry
variable instead of TimeLockDelta as that is more descriptive of the
purpose of the attribute itself.
When the funding transaction has been confirmed, the FundingLocked
message is sent by the peers to each other so that the existence of the
newly funded channel can be announced to the network.
This commit also removes the SingleFundingOpenProof message.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
This commit removes the String() method from the FeatureVector as it
can produce confusing output when revving a feature vector and not
knowing the strip mapping ahead of time.
This commit creates a distint type for the opaque failure reason within
the UpdateFailHTLC message. This new type is needed as this is the only
variable length byte slice within the protocol and therefore requires a
length prefix in order to serialize/deserialize properly.
This commit modifies the prior HTLCSettleRequest to more closely match
the UpdateFufillHTLC defined within the specification. The only
semantic change is the move from a slice of pre-images (for “multi-sig”
LN) to a single payment preimage.
This commit morphs the prior CancelHTLC into the new UpdateFailHTLC
message and also gets rid of the obsolete HLTCAddReject message while
we’re at it.
The primary change from the CancelHTLC message to the UpdateFailHTLC
message is that the CancelReason is now simply called Reason and that
it’s now an opaque encrypted set of bytes. With this update the failure
messages are now more flexible (they can even carry new
ChannelUpdate’s) and also don’t reveal the exact cause of failure to
intermediate nodes.
This commit renames and modifies the CommitSignature message to more
closely match the CommitSig message defined within the current set of
draft specifications.
The major change within the new message is that we now longer
explicitly specify the update log index of the remote node that this
signature covers. This is due to the fact the revocation message now
also double as acknowledgements of the remote parties recevied
commitment update messages.
