Core Lightning — Lightning Network implementation focusing on spec compliance and performance
Go to file
Rusty Russell 293bebbe2d daemon/peer: handle narrow reconnect race on close.
Usually if we get a packet while closing (onchain event), we're going
through pkt_in which discards it.  However, if we're reconnecting, we
simply process the init packet and get upset because they've forgotten
us.

Hard to reproduce, but here's the log (in this case, test-routing --reconnect
and we have just done mutual close):

We reconnect in STATE_MUTUAL_CLOSING, send INIT pkt:

   +19.397025114 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Init with ack 1 opens + 9 sigs + 8 revokes + 1 shutdown + 1 closing

While waiting for response, we see the mutual close...
   +19.398732602 lightningd(4637):DEBUG: reaped 6370: bitcoin-cli -regtest=1 -datadir=/tmp/bitcoin-lightning2 getblock 2a63b209e17aedc5b1bcc6c2f9e044f97c9c3ca136fc64a719f704d2f632df5f false
   +19.401834422 lightningd(4637):DEBUG: Adding block 5fdf32f6d204f719a764fc36a13c9c7cf944e0f9c2c6bcb1c5ed7ae109b2632a
   +19.405167334 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Got UTXO spend for 8bb48a:0: 7f5e422f...

   +19.412543610 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: anchor_spent: STATE_MUTUAL_CLOSING => STATE_CLOSE_ONCHAIN_MUTUAL

And we also see it buried "forever" (10 blocks in test mode), so we forget peer:
   +19.423045014 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Anchor at depth 13
   +19.426775063 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: check_for_resolution: STATE_CLOSE_ONCHAIN_MUTUAL => STATE_CLOSED
   +19.427613109 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: db_forget_peer(023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898)
   +19.428130685 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: db_start_transaction(023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898)
   +19.501027511 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: db_commit_transaction(023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898)

Now, we get their reply, but they've forgotten us:
   +19.520208608 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Decrypted header len 5
   +19.520872035 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Received packet LEN=5, type=PKT__PKT_INIT
   +19.520999082 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Our order counter is 19, their ack 0
   +19.521078913 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: They acked 0, remote=16 local=15
   +19.521447174 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Queued pkt PKT__PKT_OPEN (order=19)
   +19.522563794 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Queued pkt PKT__PKT_OPEN_COMMIT_SIG (order=19)
   +19.523517319 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:BROKEN: Can't rexmit 2 when local commit 15 and remote 16
   +19.524613177 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:UNUSUAL: Sending PKT_ERROR: invalid ack
   +19.526638447 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: Queued pkt PKT__PKT_ERROR (order=19)
   +19.527508022 023ec94fb93c669154ba7b08907276e8c8661b2e65d80fc2c089215d5395574898:DEBUG: peer_comms_err: STATE_CLOSED => STATE_ERR_BREAKDOWN

We should never transition from STATE_CLOSED to STATE_ERR_BREAKDOWn,
and that's what this check prevents.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-03-02 22:51:49 +10:30
bitcoin lightningd: simple wallet support. 2017-02-21 15:19:02 +10:30
ccan ccan: Added ccan/intmap 2017-02-02 11:29:47 +10:30
contrib pytest: Separating new lightningd and legacy lightningd RPC client 2017-01-23 10:37:34 +01:00
daemon daemon/peer: handle narrow reconnect race on close. 2017-03-02 22:51:49 +10:30
doc doc: Adding compiled manpage 2017-02-27 14:55:53 +01:00
libsodium@fce6852d64 libsodium: add as submodule. 2017-01-11 09:29:40 +10:30
libwally-core libwally: Re-adding missing gen_context file 2017-02-21 16:54:05 +01:00
lightningd lightningd: add opening to dependencies. 2017-03-02 22:51:49 +10:30
secp256k1 libsecp256k1: update. 2016-07-01 12:00:17 +09:30
test sphinx: Committing the onion packet to the payment-hash 2017-01-16 11:14:30 +10:30
tests pytest: Gossip subdaemon had a flaky test 2017-02-08 16:59:57 +01:00
tools generate-wire: don't hand unknown structures specially. 2017-02-21 15:15:19 +10:30
wire Makefile: fix distclean, clean targets. 2017-03-02 22:51:39 +10:30
.gitignore cleanup: Ignoring libwally artifacts and distclean cleans them 2017-02-27 23:14:43 +01:00
.gitlab-ci.yml Add .gitlab-ci.yml 2016-12-11 13:24:27 +01:00
.gitmodules libsodium: add as submodule. 2017-01-11 09:29:40 +10:30
check-bolt.c check-bolt: use new BOLTs. 2017-01-04 14:09:20 +10:30
close_tx.c permute_tx: reintroduce permute map. 2017-02-07 12:14:22 +10:30
close_tx.h Use global secp256k1_ctx instead of passing it around. 2016-12-02 18:12:58 +10:30
find_p2sh_out.c struct bitcoin_tx: remove explicit lengths, use tal_len()/tal_count() 2017-01-25 11:03:55 +10:30
find_p2sh_out.h Remove unused script functions now we use witness. 2016-04-24 20:09:39 +09:30
HACKING.md controlled_time: remove 2016-11-09 18:54:15 +10:30
INSTALL.md libsodium: use our local submodule. 2017-01-11 10:04:26 +10:30
irc.c Merge remote-tracking branch 'origin/pr/44' 2016-10-17 12:31:19 +10:30
irc.h Merge remote-tracking branch 'origin/pr/44' 2016-10-17 12:31:19 +10:30
LICENSE licensing: Make license explicit. 2016-01-22 06:41:46 +10:30
lightning.pb-c.c bitcoin/preimage: struct preimage. 2017-02-02 14:48:00 +10:30
lightning.pb-c.h bitcoin/preimage: struct preimage. 2017-02-02 14:48:00 +10:30
lightning.proto bitcoin/preimage: struct preimage. 2017-02-02 14:48:00 +10:30
Makefile Makefile: fix distclean, clean targets. 2017-03-02 22:51:39 +10:30
opt_bits.c opt_bits: parsing routines for 'bits' == 100 satoshi. 2015-06-07 13:52:04 +09:30
opt_bits.h header cleanup: sort include lines into alpha order, after config.h 2016-01-22 06:38:08 +10:30
overflows.h daemon: routing infrastructure. 2016-07-01 12:00:17 +09:30
permute_tx.c permute_tx: generic pointer map. 2017-02-21 15:15:29 +10:30
permute_tx.h permute_tx: generic pointer map. 2017-02-21 15:15:29 +10:30
protobuf_convert.c bitcoin/preimage: struct preimage. 2017-02-02 14:48:00 +10:30
protobuf_convert.h bitcoin/preimage: struct preimage. 2017-02-02 14:48:00 +10:30
README.md README.md: add "upgrade" instructions and add port config for public nodes. 2016-11-21 10:21:41 +10:30
remove_dust.h channel: remove htlcs array. 2016-08-18 14:23:46 +09:30
status.c status: don't send overlarge messages. 2017-01-10 15:25:20 +10:30
status.h status: API for status reporting. 2017-01-10 15:24:20 +10:30
TODO.md TODO: remove to-dones. 2016-09-06 16:47:48 +09:30
type_to_string.c type_to_string: move formatting to appropriate files. 2017-01-04 14:07:15 +10:30
type_to_string.h channel: object to track channel state. 2017-02-21 15:15:28 +10:30
utils.c utils: add tal_hex() helper. 2017-01-10 15:19:25 +10:30
utils.h utils: add tal_hex() helper. 2017-01-10 15:19:25 +10:30
version.c getinfo: add version information 2016-09-14 05:28:51 +09:30
version.h options: --help and --version are early args. 2017-01-04 14:04:15 +10:30

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:

Steps:

  1. If you're running a previous version, you'll need to shut it down (maybe close channels first) and delete the $HOME/.lightning directory.
  2. Install and compile the requirements.
  3. Make sure bitcoind is running in testnet mode, and has the latest blocks.
  4. Get some test bitcoins, such as from TPs' testnet faucet.
  5. If you want others to connect to your lightningd, create $HOME/.lightning/config and put port=8334 in it (or any other port).
  6. Run daemon/lightningd.
  7. Run daemon/lightning-cli getinfo to check it's working.
  8. Find a node using daemon/lightning-cli getnodes (this will populate over time).
  9. Create a new connection to the node using contrib/lightning-open-channel ADDRESS PORT AMOUNT where AMOUNT is in BTC (.04294967 is the maximum possible). If successful, this will return only once a block has been mined with the funding transaction in it.
  10. You can create more channels if you wish.
  11. You can accept payment using daemon/lightning-cli invoice MILLISATOSHI LABEL; it will give you a payment hash to give to the payer.
  12. You can send payments using contrib/lightning-pay DEST-ID MILLISATOSHI PAYMENT-HASH.

Final note: This is very much a testbed and work in progress; expect All The Things to change, all the time.

Welcome aboard!

Rusty.