The invoice package can be used to encoded and decode invoices
in the format defined in BOLT-0011. This format utilizes bech32
encoding to create invoices that can be shared and understood
by the different Lightning implementations.
This commit adds a new debug mode for lnd
called hodlhtlc. This mode instructs a node
to refrain from settling incoming HTLCs for
which it is the exit node. We plan to use
this in testing to more precisely control
the states a node can take during
execution.
In this commit, we fix a lingering issue in the execution
of the lnd container, after the new macaroon based
authentication was added. With the new authentication
feature, if the datadir was changed, but `lncli` wasn't
updated to point to the macaroon path, then none of
the commands would work.
To fix this, we simply omit setting the data directory.
This commit fixes two incorrect links in the readme to
dev.lightning.community and api.lightning.community. The two links were
lacking the http:// prefix, and Github's parser didn't automatically
recognize the new TLD. As a result, the links wouldn't automatically
show as clickable. With this commit, we've added the prefix, ensuring
that the links are properly clickable.
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 commit corrects a minor formatting error when logging the pending
channel ID within the logs. Previously, the logging directives and
parameter could cause the pending chan ID to display in a double-hex
encoded format. We fix this by ensuring that we properly slice the chan
ID before printing it, and also ensure that we use the %x formatting
(which will hex encode the bytes) everywhere.
Fixes#331.
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.
Changes the second docker-compose command to "run" instead of "up",
since this was failing for several people. Also removes the use of
the --num_conf flag to lncli openchannel, as this was removed in
0dfe733.
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 reduces the neutrino.WaitForMoreCFHeaders parameter when
instantiating a neutrino instance as a lower value will allow the tests
to complete more quickly.
This commit updates the glide build to point to the latest version of
neutrino which has a number of bug fixes related to re-org handling
with several hundred blocks, and also a number of fixes that should
eliminate the number of flakes within the ChainNotifier tests for the
neutrino back end.
This commit fixes an existing bug in the way we perform validation of
the timelock information as the final hop in the route. Previously, we
would assert that the outgoing time lock in the per-hop payload would
exactly match our time lock delta.
Instead, we should be asserting two things:
1. That the time lock in the payload is >= the expected time lock
2. That timeout on the HTLC is exactly equal to the payload
This commit fixes an oversight in the path finding code when converting
a path into a route. Currently, for the last hop, we’d emplace the
expiry delta of the last hop within the per-hop payload. This was left
over from a prior version of the specification.
To fix this, we’ll now emplace the _absolute_ final HTLC expiry with
the payload, such that, the final hop that verify that the HTLC has not
been tampered with in flight.
This commit implements some missing functionality as we’ll now properly
validate and generate the various channel flow control constraints
during initial channel funding.
With this commit, we take an additional step towards full spec
compliance as we’ll now properly send over the required channel
reservation, max HTLC’s, and other parameters during the funding flow.
When processing the desired parameters by the remote party, if we think
they’re unreasonable, then we’ll send an Error message and end the
funding flow.
This commit removes the revocation_delay field from the HTLC proto as
we no longer need this field since the switch to 2-layer HTLC’s. The
2-layer HTLC construction no longer has the CSV delay directly in the
HTLC script itself.
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 commit is a follow up to the prior commit, as since we reversed
the order of the pubkeys in the multi-sig scripts, then we also need to
reverse the order of the signatures that we use when attempting to
spend the funding output directly.
When creating the script for the funding output, we were reversing the
order of the public keys due to an incorrect assertion of the return
value of the bytes.Compare function. To fix this, we now flip the
order, allowing us to properly create channels as specified within the
specification.
This commit adds to methods to the ChannelReservation struct: one for
generating the channel constraints we require for the remote party, and
one for validating their desired constraints, and committing them to
our ChannelConfig.
With these two new methods, we can now begin to properly store and
adhere to the current set of channel flow control constraints.
This commit fixes an existing w.r.t the way that we constructed all
commitment transactions. We were computing the hash that the obfsucator
was derived form correctly, but we were using the first 6-bytes, rather
than the last 6 bytes.
This commit fixes a prior bug in the logic for registering a new spend
notification. Previously, if the transaction wasn’t found in the
mempool or already confirmed within the chain, then
GetRawTransactionVerbose would return an error which would cause the
function itself to exit with an error.
This issue would then cause the server to be unable to start up as the
breach arbiter would be unable to register for spend notifications for
all the channels that it needed to be watching.
We fix this error simply by recognizing the particular JSON-RPC error
that will be returned in this scenario and treating it as a benign
error.
This commit fixes a prior mishandled error when attempting historical
confirmation dispatches. In the prior version of this code fragment, if
the transaction under the spotlight wasn’t found within the mempool, or
already in the chain, then an error would be returned by
b.chainConn.GetRawTransactionVerbose, which would case the function to
exit with an error. This behavior was incorrect, as during transaction
re-broadcasts, it was possible for transaction not yet to be a member
of either set.
We fix this issue by ensuring that we treat the JSON error code as a
benign error and continue with the notification registration.
This commit adds a new config option to allow callers to optionally
disable connection bootstrapping. This may be desirable for several
reasons, but primary, we add this so we can keep our integration tests
under the same context as before bootstrapping existed.
This commit adds a new primary goroutine to the server struct:
peerBootstrapper. If peer boostrapping isn’t disabled in the config,
this new goroutine will be launched to attempt to establish a set of
initial connections for a new node. The logic is pretty straight
forward: first a set of initial connections is attempted, if after our
first epoch, we don’t have enough connections yet, then we’ll attempt
to query for an additional set. In each iteration, if we haven’t been
successful, then we increase our exponential backoff in order to not
spam any of our bootstrapping sources.
This commit adds a new interface the to discovery package:
NetworkPeerBootstrapper. The NetworkPeerBootstrapper interface is meant
to be used to bootstrap a new peer joining the network to the set of
existing active peers within the network. Callers are encouraged to
utilize several boostrappers in series as redundant sources of
information. The MultiSourceBootstrap function will takes a set of
boostrappers, and compose their outputs into a single unified set of
addresses.
Two concrete implementations of the NetworkPeerBootstrapper interface
have been added as a part of this commit: the ChannelGraphBootstrapper
and the DNSSeedBootstrapper. The former will utilize the authenticated
node advertisements within the calling nodes view to boostrap new
connections. The latter will use a set of BOLT-0010 compliant DNS seeds
to query. This DNS seeding more will likely be used by nodes initial
joining the network, as they may not yet have the channel graph as they
haven’t connected to any peers.
