Under development, not for use with real money.
- Start by installing Go
- Set your Go variables to match your installed paths are set correctly:
.../go/bin(your install location) is in$PATH(Windows: Add the install location into yourPATHSystem Variable)$GOPATHis set the location of where you want lit (and other projects) to be- optional: If you want to have packages download in a separate location than your installation add
$GOROOTset to another location (Windows: Add )
- Download the lit project with
go get github.com/mit-dci/lit
- Go to the location of your lit installation with your defined gopath variable (
$GOPATHon Linux and%GOPATH%Windows) to the lit location
cd [gopath]/src/github.com/mit-dci/lit
- If you try to build now with
go buildyou will receive several errors such as
cannot find package "golang.org/x/crypto/nacl/secretbox"
...
cannot find package "golang.org/x/crypto/scrypt"
...
cannot find package [packageName]
...
- For each unfound package, you will need to use go to download these libraries into your GOPATH. For each outer package use
go getto download the repositories.
i.e.
go get golang.org/x/crypto
-
Go back to location of the lit folder if you are not already there (Step 1) and try to rebuild the project.
-
You may now want to build
lit-af, the text based client which controls the lit node using
cd cmd/lit-af
go build
-
If you run into any more dependency errors, repeat Step 3 by using
go getfor all of the missing packages. -
To run lit use: (Note : Windows users can take off ./ but may need to change lit to lit.exe in the second line.)
cd GOPATH/src/github.com/mit-dci/lit
./lit -spv my.testnet.node.tld
Great! Now that you are all done setting up lit, you can
- read about the arguments for starting lit here
- read about the folders for the code and what does what here
- head over to the Walkthrough to create some lit nodes or
- check out how to Contribute.
(a lit.conf file is not yet implemented but is on the TODO list)
When starting lit, the following command line arguments are available
-tn3
connect to nodeHostName, which is a bitcoin testnet3 node. Default port 18333
-reg
connect to , which is a bitcoin regtest node. Default port 18444
-lt4
connect to , which is a litecoin testnet4 node. Default port 19335
-ez
use bloom filters unstead of downloading the whole block. This fucntionality hasn't been maintained for a few months and may not work properly.
-v
Verbose; log everything to stdout as well as the lit.log file. Lots of text.
-dir
use as the directory. By default, saves to ~/.lit/
-rpcport
listen for RPC clients on port . Defaults to 8001. Useful when you want to run multiple lit nodes on the same computer (also need the -dir option)
-tip
start synchronization of the blockchain from . (probably doesn't work right now)
-resync
try to re-sync to the blockchain from the height given -tip
has some rpc client code to interact with the lit node. Not much there yet
a hash-tree for storing log(n) items instead of n
Lightning Network Browser Actuated Multi-Functionality -- web gui for lit
websocket based RPC connection
lightning network data connection -- send encrypted / authenticated messages between nodes
some widely used utility functions
portable utxo format, exchangable between node and base wallet (or between wallets). Should make this into a BIP once it's more stable.
Introduces a web API chainhook in addition to the uspv one
A quick channel implementation with databases. Doesn't do multihop yet.
Library to make signatures 64 bytes instead of 71 or 72 or something
integration tests
deals with the network layer, sending network messages and filtering what to hand over to wallit
deals with storing and retreiving utxos, creating and signing transactions
Unlinkable outsourcing of channel monitoring
One instance of lit has one litNode (package qln).
LitNodes manage lndc connections to other litnodes, manage all channels, rpc listener, and the ln.db. Litnodes then initialize and contol wallits.
A litNode can have multiple wallits; each must have different params. For example, there can be a testnet3 wallit, and a regtest wallit. Eventually it might make sense to support a root key per wallit, but right now the litNode gives a rootPrivkey to each wallet on startup. Wallits each have a db file which tracks utxos, addresses, and outpoints to watch for the upper litNode. Wallits do not directly do any network communication. Instead, wallits have one or more chainhooks; a chainhook is an interface that talks to the blockchain.
One package that implements the chainhook interface is uspv. Uspv deals with headers, wire messages to fullnodes, filters, and all the other mess that is contemporary SPV.
(in theory it shouldn't be too hard to write a package that implements the chainhook interface and talks to some block explorer. Maybe if you ran your own explorer and authed and stuff that'd be OK.)