In this commit, we modify the Linux installation instructions to use the
pre-built archives rather than install from the ppa. We do this as
typically the ppa lags behind the latest releases, and also by
downloading it in this new manner, we're able to verify the sha256 sum
of the installed Go release.
In this commit, we aim to revamp the `INSTALL.md` file in order to make
it easier to parse, and more explicit. We've added a table of contents
to allow users to skip down to relevant sections and obtain a snapshot
of the contents of the document. Additionally, we've now modified the
headings to express a more clear delineation of the various sections.
- Provides clarity to the sample `lnd.conf` to reduce friction on a first-time mainnet set up of lnd (avoiding the `loadConfig: debug-htlc mode cannot be used on bitcoin mainnet` error)
- Removes `debughtlc` from the sample `lnd.conf` since it is not something most people would use anymore
- Adds link to `sample-lnd.conf` with proper line-wrapping
Every time I try to update lnd by following these instructions it fails. Most recently like this:
$ make
Compiling dependencies.
dep ensure -v
# Bringing vendor into sync
grouped write of manifest, lock and vendor: failed to export github.com/lightninglabs/neutrino: fatal: failed to unpack tree object 838f7ba74d217d188efc223604bd280b4e3f0238
: exit status 128
Makefile:116: recipe for target 'dep' failed
make: *** [dep] Error 1
I found that if I `make clean` before running `make` then it doesn't fail.
We will be slowly phasing this out, though abruptly
discontinuing support would be a more extensive change.
For now, we will ensure that this feature is not
recommended to users setting up a new wallet.
This commit satisfies the auto-build functionality desired in #722 without changing anything in the docker folder. This allows development and testing to continue to build and use images locally, but external users get a very lean Docker image they can use. The size difference is appreciable.
REPOSITORY TAG IMAGE ID CREATED SIZE
lnd latest 3634dcf5df68 17 seconds ago 1.19GB
lnd-single latest b295cc248447 30 minutes ago 56MB
Right before merging this PR, an Automated Build repository should be configured on the appropriate account (lightningnetwork?) on Docker Hub with the name of lnd in order to match documentation.
I see there are already some repositories created, however I think best practice for Docker is to have a single repository and different tags for different architectures. The included image is based off of Alpine, but in the future we could extend into multiple Dockerfiles (example: ARM support, or being Ubuntu based).
So in this proposed scenario, lightningnetwork/lnd:latest would be alpine, but lightningnetwork/lnd:ubuntu would be an ubuntu-based image, for example.
(With thanks to @alingenhag for https://github.com/f-u-z-z-l-e/docker-lnd/ from which I borrowed heavily)
According to install.md, the minimum version of Go supported at the
moment is 1.9, so update the Go version referenced in Contribution
Checklist to 1.9 as well.
In this commit, we modify the docs in order to clarify that both btcd
and bitcoind are supported as chain backends. Many users expressed
confusion as the old set of docs stated that we "require" my btcd fork,
rather than clarifying that *if* you want to use btcd, then you must use
my fork.
The port numbers used in the ZMQ examples are inconsistent between:
- The initial explanation of ZMQ
```
They must be combined in the same ZMQ socket
address (e.g. `--zmqpubrawblock=tcp://127.0.0.1:28332` and
`--zmqpubrawtx=tcp://127.0.0.1:28332`).
```
- The sample bitcoin.conf
```
zmqpubrawblock=tcp://127.0.0.1:18501
zmqpubrawtx=tcp://127.0.0.1:18501
```
- The lnd command-line example:
```
lnd --bitcoin.active --bitcoin.testnet --debuglevel=debug --bitcoin.node=bitcoind --bitcoind.rpcuser=REPLACEME --bitcoind.rpcpass=REPLACEME --bitcoind.zmqpath=tcp://127.0.0.1:28332 --externalip=X.X.X.X
```
I changed the sample bitcoin.conf port numbers to 28332 so they match the rest of the examples.
It seems that at some point the installation docs of the
https://github.com/lightninglabs/lightning-dev-site/ was identical to
this file (without page navigation + next steps).
Seems that this commit did not get ported to this repo:
1ad7d3189d
In this PR the info for macaroons and noencryptwallet is copied over
from the above mentioned commit.
This commit adds a tutorial on fuzzing with the go-fuzz library
into the docs folder. It includes an introduction to fuzzing,
setup and installation steps to run go-fuzz with lnd, tips to
generate a valid corpus for use with go-fuzz, and finally it
includes a small explanation of the test harness that was used
to find bugs in lnd.
This commit updates the installation docs to specify the min golfing
version. Additionally, we ensure that users running on linux will
download the latest version of golfing from their ppa. Finally, we also
now link directly to the golfing page of pre-compiled binaries for
users that seek to grab the source directly from the official goading
website.
Fixes#263.
This commit modifies the travis build script, and our local test script
to ensure that the race condition builds are conducted in a parallel
build. After this commit two travis builds will be kicked off for each
push/commit: one that runs the race condition tests in isolation, and
another that runs the integration tests then the coverage tests.
In order to do the above cleanly, the integration tests are now guarded
behind a build flag. In order to run the integration tests, one now
needs to specify the `-tags rpctest` flag when running the `go test`
command.
This commit adds a basic set of instructions for installing the necessary
gRPC dependencies to be able to drive `lnd` from node.js. In the future,
this section will be expanded with additional example
scripts/applications.
This commit adds a basic set of instructions for installing the necessary
gRPC dependencies to be able to drive `lnd` using Python. In the future,
this section will be expanded with additional example
scripts/applications.
This commit adds a document which outlines some of the traits desired
in future contributions to the daemon. It’s my hope that this document
will allow new contributors to quickly get up to speed on what is
desired in new contributions, possibly directly speeding up review
times.
