This commit updates the glide files to point to the latest btcd build
which has had stall detection temporary disabled in order to ensure
smooth neutrino syncs without the false positives currently present in
stall detection.
The latest combined build fixes some issues with re-orgs, and also
ensure that all transaction sent using the neutrino back-end within
btcwallet are inserted into the unconfirmed transaction bucket on disk.
This ensure that they’ll be reliably be re-broadcast.
This commit updates `lnd` to the latest version of our Sphinx repo as
it has included a bug fix to use the proper version within the Sphinx
routing header.
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.
In this commit we’ve updated to the latest versions of roasbeef/btcutil
and ltcsuite/ltcd. With this change we fix two bugs:
* The Bech32HRPSegwit parameter wasn’t being copied over in
applytLiteCoinParams
* btcutil.DecodeAddress wasn’t properly using the passed net params
This commit updates the glide hashes for btcd, neutrino, and btcwallet
to their latest versions. This change was prompted, as we've recently
fixed two bugs: one in btcd, and one in neutrino. The btcd in btcd was
due to not properly setting a pointer, which caused the new gcs related
RPC calls to now respond correctly. The neutrino bug was due to a nil
pointer panic that was triggered by not ensuring that we actually had a
`syncPeer` before referencing it.
This commit updates the glide packages in the repo to point to the
latest btcsuite repos. With this change, we’ll now be able to take
advantage of many of the recent updates to the btcsuite package of
repos. One highlight is that after this commit, we’ll now be using
bech32 by default for p2wkh addresses.
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 new build of lightning-onion includes the routines necessary to
implement the encryption and decryption of HTLC errors as defined
within the specification.
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.
The btclog package has been changed to defining its own logging
interface (rather than seelog's) and provides a default implementation
for callers to use.
There are two primary advantages to the new logger implementation.
First, all log messages are created before the call returns. Compared
to seelog, this prevents data races when mutable variables are logged.
Second, the new logger does not implement any kind of artifical rate
limiting (what seelog refers to as "adaptive logging"). Log messages
are outputted as soon as possible and the application will appear to
perform much better when watching standard output.
Because log rotation is not a feature of the btclog logging
implementation, it is handled by the main package by importing a file
rotation package that provides an io.Reader interface for creating
output to a rotating file output. The rotator has been configured
with the same defaults that btcd previously used in the seelog config
(10MB file limits with maximum of 3 rolls) but now compresses newly
created roll files. Due to the high compressibility of log text, the
compressed files typically reduce to around 15-30% of the original
10MB file.
This commit updates the version of btcwallet that and is pinned against
to point to a version that includes a bug fix that was noticed in the
latest upstream PR’s we’ve included. The culprit bug would attempt to
create a write transaction inside of a greater read transaction which
would cause boltdb to block indefinitely internally. roasbeef’s fork of
btcwallet has been updated to include this fix.
We now pin gRPC against a particular commit version as it seems that
glide has some trouble properly resolving the semantic versioning
constraints for the latest version of gRPC.
This commit updates the version of btcwallet to the newest version
available in roasbeef’s fork. This new version includes the following
changes:
* a fix for the ping/pong deadlock issue with an expiring session
* and a preliminary merging of r btcsuite/btcwallet#469 into
roasbeef’s fork
The first change should solve an issue of lnd’s internal wallet
(btcwallet) being disconnected from the local btcd node. And the second
change should improve the reliability/correctness of the wallet as the
wtxmgr (tx/utxo store) and the waddrmgr (key store) are now updated
under a _single_ database transaction.
This commit replaces aead’s chacha20 library with the official golang
implementation. We should see a bit of a performance increase on amd64
as the assembly for the library uses the SIMD AVX2 instructions in the
inner loop. In the future assembly will be written for other platforms,
so we’ll see a performance increase across the board.
Fixes#146.
This commit removes all instances of the fastsha256 library and
replaces it with the sha256 library in the standard library. This
change should see a number of performance improvements as the standard
library has highly optimized assembly instructions with use vectorized
instructions as the platform supports.
This commit modifies the glide target for btcwallet to pin against a
particular commit that will attempt to auto-reconnect to the btcd node
in the case of a websockets connection drop.
This commit adds an ability to render the channel graph as returned by
the ‘displaygraph’ command. The rendering of the graph itself is
carried about the by the ‘dot’ command which eventually calls out to
graphviz.
Currently the graph is always saved to the same file in the local
directory, but in a later commit the location of the file will be made
configurable.
Finally, the attributes sent to the ‘dot’ command used to render the
graph are still a bit in flux. The parameters will likely be tuned once
the channel graph on testnet grows a bit more.
With this commit we now pin the version of lightning-onion we build
against at a particular build on the Sphinx package as the package will
be modified in order to accommodate for future changes in the spec.
This commit adds a new package “zpay32”: which is used within the
daemon to encode/decode payment requests. A payment request currently
consists of: the public key of the payee, the payment hash to use, and
finally the amount to send over the network. The encoded payment
request consists of the mentioned fields concatenated to each other, a
cc32 checksum is added, then the blob is finally encoded using zbas32.
I call the resulting scheme “zpay32”.
A number of extensions may be explored in future commits including
adding a version byte, adding “hint” routing information,
cryptographically signed receipts and more,
Use [33]byte for graph vertex representation.
Delete unneeded stuff:
1. DeepEqual for graph comparison
2. EdgePath
3. 2-thread BFS
4. Table transfer messages and neighborhood radius
5. Beacons
Refactor:
1. Change ID to Vertex
2. Test use table driven approach
3. Add comments
4. Make graph internal representation private
5. Use wire.OutPoint as EdgeId
6. Decouple routing messages from routing implementation
7. Delete Async methods
8. Delete unneeded channels and priority buffer from manager
9. Delete unneeded interfaces in internal graph realisation
10. Renamed ID to Vertex
This commit modifies both the Sphinx packet generation and processing
for recent updates to the API.
With the version 1 Sphinx specification, the payment hash is now
included in the MACs in order to thwart any potential replay attacks.
As a result, any attempts to replay previous HTLC packets MUST re-use
the same payment hash, meaning that the first-hop node can simply
settle the HTLC immediately, thwarting the attacker.
Additionally, within the Sphinx packet, each hop now gets a per-hop
payload which contains the necessary details (CTLV value, fee, etc) for
the node to successfully forward the payment. This per-hop payload is
protected by a packet-wide MAC.
Olaoluwa Osuntokun
Alex
Jim Posen
Andrey Samokhvalov
Travis Cline
BitfuryLightning