ca80fc0286
We need some way to reflect the tradeoff between the possible delay if a payment gets stuck, and the fees charged by nodes. This adds a risk factor which reflects the probability that a node goes down, and the cost associated with losing access to our funds for a given time. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> |
||
---|---|---|
bitcoin | ||
ccan | ||
daemon | ||
doc | ||
secp256k1 | ||
test | ||
.gitignore | ||
.gitmodules | ||
check-bolt.c | ||
close_tx.c | ||
close_tx.h | ||
find_p2sh_out.c | ||
find_p2sh_out.h | ||
HACKING.md | ||
INSTALL.md | ||
LICENSE | ||
lightning.pb-c.c | ||
lightning.pb-c.h | ||
lightning.proto | ||
Makefile | ||
names.c | ||
names.h | ||
opt_bits.c | ||
opt_bits.h | ||
overflows.h | ||
permute_tx.c | ||
permute_tx.h | ||
protobuf_convert.c | ||
protobuf_convert.h | ||
README.md | ||
remove_dust.h | ||
state_types.h | ||
state.c | ||
state.h | ||
TODO.md | ||
utils.c | ||
utils.h | ||
version.c | ||
version.h |
Lightning Protocol Reference Implementation
In this repository we're developing a reference implementation of bitcoin lightning (see: http://lightning.network which proposed the original "lightning network").
This implementation is being developed in parallel with the protocol definition, which you can find on my fork of the protocol description repository.
If you're interested in using the daemon to test payments, the JSON-RPC interface is documented in the following manual pages:
So far, we have inter-node encryption and transaction negotiation.
Routing between non-adjacent nodes is currently done manually using the 'dev-addroute' command; later on daemons will advertise their IP addresses, and publish routes and fees. These details are currently being hashed out on the mailing list and the IRC channel #lightning-dev on Freenode.
Final note: This is very much a testbed and work in progress; expect All The Things to change, all the time.
Welcome aboard!
Rusty.