elementsproject / lightning Goto Github PK
View Code? Open in Web Editor NEWCore Lightning — Lightning Network implementation focusing on spec compliance and performance
License: Other
Core Lightning — Lightning Network implementation focusing on spec compliance and performance
License: Other
I think the refactor (cd64932) that is currently the tip of the debug-log branch caused this. I'm not trying to fix it because it's 2AM here, and also I'm frankly a little scared of the config-parsing logic.
Hello,
Currently the only available ones are insufficient_funds
and cannot_route
.
But since the commitment tx must be publishable at any time, we might need to decline a new htlc because that would make the tx too big.
Should we introduce a new reason too_many_pending_htlc
?
Thanks
Pierre
cc -Werror -Wall -Wundef -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wold-style-definition -g -fstack-protector -I ccan -I secp256k1/include/ -I . -c -o daemon/peer.o daemon/peer.c
daemon/peer.c: In function ‘their_htlc_added’:
daemon/peer.c:943:10: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘u64 {aka long long unsigned int}’ [-Werror=format=]
printf("FORWARDING %lu\n", step->hoppayload->amount);
^
cc1: all warnings being treated as errors
: recipe for target 'daemon/peer.o' failed
make: *** [daemon/peer.o] Error 1
Should I be able to use install on debian similar to ubuntu? I'm having issues getting the libbase58-dev package, apparently it isn't for debian wheezy (latest version). Do I need to re-configure sources or something to get that package? thanks
Payments to the 0218 peer appear to be stuck.
12MB logs from dev-crash:
https://people.xiph.org/~tdaede/crash_035f.log
https://people.xiph.org/~tdaede/crash_0218.log
View from 035f:
$ daemon/lightning-cli getpeers
{ "peers" :
[
{ "name" : "0218e799f5085d90716493c0f9b5b7373ae47a0fb0c8cfba7411786f216e0ed15a:", "state" : "STATE_NORMAL", "peerid" : "0218e799f5085d90716493c0f9b5b7373ae47a0fb0c8cfba7411786f216e0ed15a", "connected" : false, "our_amount" : 1924280000, "our_fee" : 67599999, "their_amount" : 0, "their_fee" : 1, "our_htlcs" :
[
{ "msatoshi" : 1, "expiry" :
{ "block" : 1011980 }, "rhash" : "a957ac4630cf76cdc03957789b36a145665e64ef1a18d2e6a5a23f56e899e17d", "state" : "SENT_ADD_HTLC" },
{ "msatoshi" : 1, "expiry" :
{ "block" : 1011980 }, "rhash" : "9e8a2bcb36e754eb287db677655fe783c914ac90eff276e3ba9fb8a56f0b2b4b", "state" : "SENT_ADD_HTLC" } ], "their_htlcs" :
[ ] },
{ "name" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "state" : "STATE_NORMAL", "peerid" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706", "connected" : true, "our_amount" : 3954660000, "our_fee" : 40378000, "their_amount" : 0, "their_fee" : 100000, "our_htlcs" :
[ ], "their_htlcs" :
[ ] } ] }
View from 0218:
{ "peers" :
[
{ "name" : "035f4dafaf485d5b3245a784cc02587e745d450d15eaaf187cf68a4f149569c522:", "state" : "STATE_NORMAL", "peerid" : "035f4dafaf485d5b3245a784cc02587e745d450d15eaaf187cf68a4f149569c522", "connected" : false, "our_amount" : 0, "our_fee" : 1, "their_amount" : 1924280000, "their_fee" : 67599999, "our_htlcs" :
[ ], "their_htlcs" :
[ ] } ] }
On my freshly-installed Debian unstable system, I have to apt-get install asciidoc (not listed in the instructions) in order to get the 'a2x' binary which is required by some part of the lightning build.
$ daemon/test/test-routing --verbose
...
lightningd: Computed MAC does not match expected MAC, the message was modified.
lightningd: Computed MAC does not match expected MAC, the message was modified.
lightningd: Computed MAC does not match expected MAC, the message was modified.
These seem to be created sequentially and so are harmless, other than slowing down startup and being annoying in gdb.
lightningd(27832): ID: xxx
Detaching after fork from child process 27836.
Detaching after fork from child process 27837.
Detaching after fork from child process 27838.
Detaching after fork from child process 27839.
...
Detaching after fork from child process 31926.
Detaching after fork from child process 31927.
Detaching after fork from child process 31928.
lightningd(27832): No fee estimate: using default fee rate
lightningd(27832): No fee estimate: using default fee rate
Detaching after fork from child process 31929.
lightningd(27832): Creating IPv6 listener on port 38377
lightningd(27832): Failed to bind on 2 socket: Address already in use
Detaching after fork from child process 31930.
lightningd(27832): Hello world!
This time I tried 'connect'ing the cat picture server using an input tx that only had one confirm. I don't know whether that was the cause, but I ended up with a connection but no channel, and lightningd never said anything about broadcasting an anchor tx.
(First thing-that-seems-like-a-bug: If lightningd is not opening a channel because the tx I supplied isn't deep enough yet, it would be helpful if it would tell me -- this protocol is very fiddly so good error reporting is key. There wasn't anything in the log, either.)
At this point 'getpeers' reported:
{ "peers" :
[
{ "name" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "state" : "STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR", "peerid" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706", "connected" : true } ] }
After a couple more confirms on the input tx, and nothing further from lightningd, I killed and restarted it. Still no anchor tx, but now 'getpeers' yielded:
{ "peers" :
[
{ "name" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "state" : "STATE_INIT", "peerid" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706", "connected" : true } ] }
So I decided to run 'connect' again just to see what I would get, yielding finally:
lightningd(4399): Connected json input
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Disconnected
lightningd: daemon/db.c:1686: db_forget_peer: Assertion `peer->state == STATE_CLOSED' failed.
lightningd(4399): FATAL SIGNAL 6 RECEIVED
Fatal signal 6. Log dumped in crash.log
So I guess I ended up in an inconsistent state and then went bang. That part definitely seems like a bug!
I try to do multi-hop micropayment.
Lightningd already implemented multi-hop?
$ ./lightning/daemon/lightningd --version
v0.5.2-2016-11-21-146-g1c49af7
aka. Bitcoin Savings & Trust Daily Interest II
Built with:
There seems to be a regression on the debug-log
branch that causes sendpay
to fail with Bad Signature
. This is a 1-hop test payment on testnet. The receiving node apparently provides an invalid signature when returning the commit transaction, or the sender validates the signature incorrectly.
The problem was not there in the master
branch. Currently bisecting to find where the bug was introduced.
I have two nodes, with a channel opened from node A to node B.
When I try to create another channel from node B to node A, the node B crashes on memory corruption.
Version is current head, v0.5.2-2016-11-21-412-g018c1d9
*** Error in `daemon/lightningd': malloc(): memory corruption: 0x00000000038c4940 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f2d2ee6a7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8181e)[0x7f2d2ee7481e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f2d2ee765d4]
daemon/lightningd[0x4599f1]
daemon/lightningd[0x459fa7]
daemon/lightningd[0x435b75]
daemon/lightningd[0x435c95]
daemon/lightningd[0x415e52]
daemon/lightningd[0x44e1ab]
daemon/lightningd[0x44ece6]
daemon/lightningd[0x4501b7]
daemon/lightningd[0x450242]
daemon/lightningd[0x4034ec]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f2d2ee13830]
daemon/lightningd[0x403039]
Stacktrace is not particularly helpful, so I have attached a valgrind log that shows read and write to already free'd memory.
lightningd gives the following error:
lightningd(12839): Broadcasting tx 020000000001015cdd29ac75ead0492ad22a4820f62abeef184f5fcefd50dff5aee9921ea6897d0000000017160014730569fc932bc0c9bd44e7a834d46bc938df4e61ffffffff0148e93c000000000022002009d9aa2eb572be5e33eea84f1e2241c88d9d9a8fb0665f79e78290eb880d271b0247304402205f7cc0f82bc6195ffefce0cfbd4daab62532074b6a09ca4513d91ba9603c3ffb02202afba691351b368f16b1a8e1d7f9597af33f9ab4f4768fb36cf2ef8988a12d3f01210318f97a9bce8e4a2c4cca0508219bf5e8839db02448572c729a22bb7c9198497000000000: error code: -26
error message:
18: bad-txns-inputs-spent
The connect json-rpc call should probably return right away and report this error to the user.
From @cedcker comment in #67
https://gist.github.com/anonymous/251ce28774d9f0c094a5dbe06388b6bb
Turns out it was a bit different. calling close on a channel that is neither in STATE_NORMAL nor STATE_NORMAL_COMMITTING will trigger an assertion and fault our client. But it seems that we are conflating connection state and channel state in a few places.
db:wrong bytes 0 not 64
lightningd/pay.c:1:17: fatal error: pay.h: No such file or directory
compilation terminated.
Since we have almost reached feature parity it's time to remove the legacy daemon from the source tree. I think the following features are missing before we can do that:
This being a rather large change, I would also propose a reorganization of the source tree:
protobuf-c
as a dependencylightningd
directory to src
, and move all other source directories into that directory. This results in a clean top level directory with README.md with associated documentation, and the contrib
directory.Did I miss something @rustyrussell?
The 'getroute' documentation and error message only mention two parameters, but it actually takes three (they were not updated when the third one was added, or else the third one is supposed to be optional and is not.)
Also the cat picture instructions need to be updated.
Seems bcli->args[3] should be bcli->args[2] on lines 194 and 206 of bitcoind.c.
My setup: 2 ubuntu VMs networked to eachother, one has bitcoind running, both have lightningd. lighning-cli connect [ip] [port] [tx] causes segfault on the machine that's connecting.
$ daemon/lightning-cli listinvoice asdf
{
[
{ "label" : "asdf", "rhash" : "4b9979d3836b9aa7e742f0d91de6648b6528502fad665a39505c7140d3a9605b", "msatoshi" : 1000, "complete" : false } ] }
The outer {} is both unnecessary and invalid, as JSON only allows key:value pairs inside {}.
This is a tracking issue for the replacement of the IRC based node and channel announcement with a peer-to-peer based gossiping protocol.
channel_announcement
s and channel_update
s to newly connected peersI'm currently developing this locally, and will file a PR as soon as it is ready to review.
It seems that the 8-bytes short channel id format used in announcements is 4 bytes (block height) + 3 bytes (tx index) + 1 byte (tx output index), shouldn't it be 3+3+2 instead ?
On both sides:
lightningd: daemon/peer.c:165: bitcoin_commit: Assertion `!peer->local.commit->tx->input[0].witness' failed.
lightningd(29329): FATAL SIGNAL 6 RECEIVED
Fatal signal 6. Log dumped in crash.log
Aborted (core dumped)
035f opened the channel.
crash_segwit_035f.txt
crash_segwit_0218.txt
There's a small typo in the main Makefile: -DHAS_CLTV=1 is now mispelled -DHAS_CTLV=1
What kind of status is STATE_ERR_INFORMATION_LEAK?
I think this is occurred in case that closing a channel fails or peer breaks a channel forcedly according to https://github.com/ElementsProject/lightning/blob/e5b44ff23245267c0e54633acc9982ebe48c2a0c/daemon/state_types.h .
So I try to recreate a channel.
The connecting peer is booted successfully but connect
command returns "peer breakdown".
How could I reconnect to the peer?
The peer side logs are like below.
IN-::ffff:1.55.46.187:21667: Connected in from ::ffff:1.55.46.187:21667 id 02d837e5fd98da358f8af239eedb7ea46d85400c088d10f018d3783c22800b1848, changing prefix
02c5bcc81e7953d90997be23f44f23f6b6086ddc239c26afc468ad2c1123085d07: Reconnected in from ::ffff:1.55.46.187:21579
02c5bcc81e7953d90997be23f44f23f6b6086ddc239c26afc468ad2c1123085d07: Sending PKT_ERROR: In error state STATE_ERR_INFORMATION_LEAK
02c5bcc81e7953d90997be23f44f23f6b6086ddc239c26afc468ad2c1123085d07: Disconnected
02c5bcc81e7953d90997be23f44f23f6b6086ddc239c26afc468ad2c1123085d07: Reconnected in from ::ffff:1.55.46.187:32081
02c5bcc81e7953d90997be23f44f23f6b6086ddc239c26afc468ad2c1123085d07: Sending PKT_ERROR: In error state STATE_ERR_INFORMATION_LEAK
02c5bcc81e7953d90997be23f44f23f6b6086ddc239c26afc468ad2c1123085d07: Disconnected
When I try to connect a second time with the same parameters, I get this crash:
lightningd(22265): Connected json input
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Disconnected
OUT-128.199.80.48:8334: Connected out to 128.199.80.48:8334 id 02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706, changing prefix
lightningd(22265): db_create_peer:constraint failed:INSERT INTO peers VALUES (x'02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706', 'STATE_INIT', 1, 221510);:UNIQUE constraint failed: peers.peer
Database error in peer_crypto_on
lightningd(22265): Database error in peer_crypto_on
Log dumped in crash.log
For my own reference if anybody wants to see it, this is crash.log.1474579521.
Hi,
I think there is something wrong with how unacked htlcs are handled by lightning-c during mutual closing. The spec is a little vague on this so I can't tell if lightning-c implementation does or doesn't comply. I guess it depends on how one side indicating that it wants to clear the channel (and thus will accept no new HTLCs)
(bolt02, §4) is interpreted.
In file peer.c (lines 402 and 434), we go to STATE_MUTUAL_CLOSING when there are no htlcs in signed tx (actual check is done in function committed_to_htlcs
).
But I don't see why we shouldn't keep the unacked htlcs. As soon as both parties have sent and received a close_clearing
packet, and because they agree not to send any new htlcs after having sent their own close_clearing
packet (bolt02, §4.1), the state is perfectly well-defined and all pending htlcs (sent & received) could be included.
What bothers me is that in the rest of the protocol we assume that a valid htlc will always be accepted (there is no way for a peer to say 'no'), so the fact that in this specific case some htlcs could be discarded doesn't seem very consistent.
What do you think?
Cheers,
Pierre
When trying to fund the new channel with a new tx, I get this error:
$ daemon/lightning-cli connect 159.203.218.14 6331 0100000001ae6aeaf3d1d5816434c2d68dc0fdd3f18abb8e59f4aa395e5129fc839704fceb0000000069463043021f3e7ef0460bea192e1364e65d40f4a94c807c8da1f5cc2335ec37bda953fdc10220678c5ca1e88e040bfe96c0b3b275d6b3cb55d6b4dd54bd67ed274f324a84fd32012103e4aea51a6b3bf1398135755e40c189016e10d7ae8d86093065fcb4376ae00374feffffff0240420f000000000017a914c195cfe511e78c115e5e8691b9f2d8520dedad2987dee23d05000000001976a9143f084e3f34e852b928abf7629ee9252b722e8d0888ac75740f00
"Already connected to peer 032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b"
This is the state of the peer:
{ "name" : "032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b:", "state" : "STATE_CLOSE_ONCHAIN_OUR_UNILATERAL", "peerid" : "032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b", "connected" : false, "our_amount" : 3924280000, "our_fee" : 67599999, "their_amount" : 0, "their_fee" : 1, "our_htlcs" :
[ ], "their_htlcs" :
[ ] },
@sipa points out:
sipa: you need a slightly stronger check
sipa: the low-s requirement is that s is below n/2
sipa: and n is around 2^256 - 2^128
You could screw the current code up by making me think you had given me a valid sig, but actually hadn't, and I'd lose.
Hello,
I think there might be something missing in the htlc outputs of the Figure 4.
The payee should wait for a delay before being able to use the R, therefore the output would be:
R-VALUE & OP_CSV & SIG-PAYEE
OR
HTLC-TIMEOUT & SIG-PAYER
OR
REVOCATION-B & SIG A
Sorry I don't know how to make a PR for this, the file htlc.eps looks chinese to me !
Cheers,
Pierre
$ cd lightning
$ make
...
fstack-protector -I ccan -I libwally-core/src/secp256k1/include/ -I libwally-core/include/ -I libsodium/src/libsodium/include/ -I . -DSHACHAIN_BITS=48 -c -o lightningd/pay.o lightningd/pay.c
lightningd/pay.c:1:17: fatal error: pay.h: No such file or directory
compilation terminated.
lightningd/pay.c:1: #include "pay.h"
$ git ls-files | grep pay.h
daemon/pay.h
This also reproduces over other json-rpc clients if you fail to cast label to a string.
$ daemon/lightning-cli listinvoice
{
[
{ "label" : "1", "rhash" : "91c45480a2047159de6bc01c1cf8dfd4d4a54f2cdd41cf9528baa229b940cc10", "msatoshi" : 1, "complete" : false },
{ "label" : "asdf", "rhash" : "4b9979d3836b9aa7e742f0d91de6648b6528502fad665a39505c7140d3a9605b", "msatoshi" : 1000, "complete" : false } ] }
$ daemon/lightning-cli listinvoice asdf
{
[
{ "label" : "asdf", "rhash" : "4b9979d3836b9aa7e742f0d91de6648b6528502fad665a39505c7140d3a9605b", "msatoshi" : 1000, "complete" : false } ] }
$ daemon/lightning-cli listinvoice 1
{
[ ] }
Hello,
This is just a matter of reversing the array, but the comment is a bit misleading
message open_anchor {
// Transaction ID of anchor.
required sha256_hash txid = 1;
See https://github.com/ElementsProject/lightning/blob/master/bitcoin/tx.c#L232
Cheers,
Pierre
Hi Rusty,
I decided to finally lock myself away with your Reaching the Ground with Lightning paper and your earlier blog post series last night and spent some time digging into the details of Lightning. I love the work you're doing on this, and I'm happy that I'm finally beginning to get my head around lightning.
I have a few minor comments about the paper:
Commitment Close Tx 1A (CC1b) -- should be CC1a
Commitment Close Tx 1b (CC1a) -- should be CC1b
(both of these are carried over from the Lightning Paper 0.5 and fixed in 0.5.9)
"Commitment Refund Tx1a (CR2a)" should be "Commitment Refund Tx2a (CR2a)"
The settlement/timeout transactions are named S1a/SD1a/T1a/TR1a. I believe these should be called S2a/SD2a/T2a/TR2a (since they're descendants of Commitment transaction 2a)
(carried over from the Lightning Paper 0.5 and still in 0.5.9)
I'll open a pull request for 3 and 7. The others are either:
I've also been following along on the Lightning-dev mailing list, and see that there's been a lot of movement on state machines and routing since v0.2 of the documentation. Are there plans to update the paper to include information on those aspects? I'm happy to lend a hand if you think that'd be useful.
Thanks,
John
Thanks for the work you're putting into this, it's very much needed. And although you're using C, you seem to have managed to avoid C++. I guess thank you as well for that. :)
Not sure what the error is but whenever I try to start lightnind the following error is thrown:
DATABASE NEEDS UPDATE. Can't access VERSION: SQL logic error or missing database:no such table: version
lightningd(18306): DATABASE NEEDS UPDATE. Can't access VERSION: SQL logic error or missing database:no such table: version
Log dumped in crash.log
Tried troubleshooting by reinstalling the libsqlite library but didnt worked.
bitcoind is configured for testnet and works normally.
OS: Ubuntu 16.04 LTS
For reference tried looking up for crash.log but unable to find its location.
daemon/json.c: In function ‘json_tok_u64’:
daemon/json.c:54:2: error: size of unnamed array is negative
BUILD_ASSERT(sizeof(l) >= sizeof(*num));
^
: recipe for target 'daemon/json.o' failed
make: *** [daemon/json.o] Error 1
lightning-cli close 0297377f0d4c18c61a451b8d57525a305f92d3d74638891e6eadf4f3c82c66dc8e
"Peer is already closing: state STATE_ERR_INFORMATION_LEAK"
This causes that peer to never be able to connect to me again:
OUT-159.203.218.14:6331: Connected out to 159.203.218.14:6331 id 032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b, changing prefix
032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b: reconnect ack 4 > 0
032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b: Sending PKT_ERROR: invalid ack
032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b: Peer breakdown: nothing to do
032282512a55842274728d58d371e1186a558071d6de509e32e5d6e765b0d3da7b: Disconnected
Hence as a next step forward from the issue #167 maybe the following should be addressed:
Not exactly issues but feel it needs to be addressed for make it easier for people to play with the implementation.
P.S. Was unable of find the correct title :P
When I run this:
gwillen@lightning-test:~/src/lightning$ ./daemon/lightning-cli connect 128.199.80.48 8334 01000000015bd0cf9bd023ad00f682ce8999c6f0dc750b1f3655824889aad1f235d8787570010000006b48304502210095448f70e829fd2d0268d1230eb44edfab8f657cfb2a9a4efd21cfb4313a3faa022021f099a54676482e7bdcbb6a132f331a74302289c47d0b014b96f565317d2ded012102116f21a0310ea54d54a7960985dfccc09f069caa273f4d55beb3459366092865feffffff02409ef629010000001976a9147d48e46fcc3e186118ee57f28ea3edc263e503ce88ac40420f000000000017a91470ecbf2dca0c46424fa8f613d435e54ed5688e8287ea2c0e00
I get only this output:
{ }
But in the log I get this:
OUT-128.199.80.48:8334: Connected out to 128.199.80.48:8334 id 02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706, changing prefix
lightningd(9867): No fee estimate: using default fee rate
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Sending PKT_ERROR: Commitment fee rate too low
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: peer open failed: Commitment fee rate too low
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Peer breakdown: nothing to do
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Disconnected
lightningd(9867): Unable to estimate fee
Per @rustyrussell, the output should contain a more useful error message.
crash.log
+514.907417361 lightningd(20657):jcon fd 7:DEBUG: Failing: Amount 1000 below fee 8972
+514.907478519 lightningd(20657):jcon fd 7:DEBUG: Failing: Amount 18446744073709543644 is too large
+514.907638050 lightningd(20657):BROKEN: FATAL SIGNAL 6 RECEIVED```
We use it for both relative timeouts, where it's actually used in nSequence and OP_CSV, and absolute timeouts in locktime. Over the wire it's represented explicitly, but converting to locktime then BIP68 nSequence is just weird.
$ daemon/lightning-cli getroute 035f4dafaf485d5b3245a784cc02587e745d450d15eaaf187cf68a4f149569c522 1000 1
lightning-cli: Non-object response ''
Backtrace:
#0 0x0000000000429c51 in find_route (dstate=0x697030, to=0x7fffffffdae0, msatoshi=1000,
riskfactor=1, fee=0x7fffffffdaa0, route=0x7fffffffdab0) at daemon/routing.c:345
n = 0x0
src = 0x698510
dst = 0x698510
it = {i = {off = 4}}
first = 0xa321d10
runs = 20
i = 21
best = 0
__PRETTY_FUNCTION__ = "find_route"
#1 0x0000000000419eda in json_getroute (cmd=0x722120,
buffer=0xa321c80 "{ \"method\" : \"getroute\", \"id\" : \"lightning-cli-4156\", \"params\" : [ \"035f4dafaf485d5b3245a784cc02587e745d450d15eaaf187cf68a4f149569c522\", 1000, 1] }",
params=0x9deebb0) at daemon/pay.c:244
id = {pubkey = {
data = "\"\305i\225\024O\212\366|\030\257\352\025\rE]t~X\002̄\247E2[]H\257\257M_C\025w\245\071\025\327R\231eyӇ3\234KX\276\214\223\316R\324Q\314\344lD\233\337\017\245"}}
idtok = 0x9deebc0
msatoshitok = 0x9deebd0
riskfactortok = 0x9deebe0
response = 0x42fe7a <json_tok_streq+137>
i = 21
msatoshi = 1000
fee = 140737488345840
riskfactor = 1
route = 0x44daa5 <list_add_+44>
peer = 0x14
amounts = 0x1
total_amount = 1
total_delay = 0
delays = 0xa321ca0
#2 0x0000000000415c3c in parse_request (jcon=0xa769710, tok=0x9deeb50) at daemon/jsonrpc.c:492
method = 0x9deeb70
id = 0x9deeb90
params = 0x9deebb0
cmd = 0x466680 <getroute_command>
__PRETTY_FUNCTION__ = "parse_request"
#3 0x0000000000415ee1 in read_json (conn=0x5513fd0, jcon=0xa769710) at daemon/jsonrpc.c:554
toks = 0x9deeb50
valid = true
#4 0x0000000000443255 in next_plan (conn=0x5513fd0, plan=0x5514018) at ccan/ccan/io/io.c:58
next = 0x415d83 <read_json>
__PRETTY_FUNCTION__ = "next_plan"
#5 0x0000000000443cda in do_plan (conn=0x5513fd0, plan=0x5514018) at ccan/ccan/io/io.c:375
__PRETTY_FUNCTION__ = "do_plan"
#6 0x0000000000443d18 in io_ready (conn=0x5513fd0, pollflags=1) at ccan/ccan/io/io.c:386
No locals.
#7 0x0000000000444fd4 in io_loop (timers=0x6970d8, expired=0x7fffffffdcf0)
---Type <return> to continue, or q <return> to quit---
at ccan/ccan/io/poll.c:303
c = 0x5513fd0
events = 1
i = 4
r = 0
ms_timeout = 6561
ret = 0x697030
__PRETTY_FUNCTION__ = "io_loop"
#8 0x000000000040477c in main (argc=1, argv=0x7fffffffde08) at daemon/lightningd.c:529
expired = 0x0
v = 0x0
dstate = 0x697030
portnum = 0
In the ccan timer module, there's an assertion that can crash if time moves backwards. I know there are different perspectives on this, but it seems like lightningd can probably recover from slight non-monotonicity of time, so it's worth thinking about whether crashing is the best outcome in this case.
lightningd: ccan/ccan/timer/timer.c:307: timers_expire: Assertion `now >= timers->base' failed.
lightningd(24325): FATAL SIGNAL 6 RECEIVED
Fatal signal 6. Log dumped in crash.log
Aborted
I'm not much help on the why of this one, but every attempt I make to open a channel is failing, here's an example.
The testnet bitcoind I'm talking to has been running for a long time, ignored by me, but appears to be up to date with the chain (it's on block 1012853, which matches some random explorer I looked at.)
(Note: This is not the first failed attempt I've made with this particular transaction, so it's possible that this is not the real failure, and this failure is actually "you already used this transaction" or "you already broke something with a previous failure", in which case the bug is that it doesn't say so.)
./daemon/lightning-cli connect 128.199.80.48 8334 010000000108de68e965b8b89d3faacbb8be39f98bbe8beec84645ee834fbd5b85df79005a010000006b48304502210090db29ed1b2b7555b94bf863ece893fc588fe6632ed789c2042a42f68071bcfd022069cc5884d20409d8abf339fb1438a423c483ea059a5aa5b5f67f1789200bcb72012103417a853d089af430f8ec6593d94daa7d98842f467ff1439bf8ef6ecae59f1aebfeffffff0240420f000000000017a914e13ebe92e2e2290c88497a7d8e635485217733a68738700105000000001976a9147ad3816abe25f6932738a9a7d65d681c10db3c9b88ac0d740f00
[hangs]
lightningd says:
OUT-128.199.80.48:8334: Connected out to 128.199.80.48:8334 id 02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706, changing prefix
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Entered error state STATE_ERR_INTERNAL
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Peer breakdown: nothing to do
02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706: Disconnected
getlog debug says:
{ "type" : "INFO", "time" : "99.399146956", "source" : "OUT-128.199.80.48:8334:", "log" : "Connected out to 128.199.80.48:8334 id 02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706, changing prefix" },
{ "type" : "DEBUG", "time" : "99.399173959", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Using fee rate 252000" },
{ "type" : "DEBUG", "time" : "99.399516067", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "db_create_peer(02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706)" },
{ "type" : "DEBUG", "time" : "99.399524245", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "db_start_transaction(02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706)" },
{ "type" : "DEBUG", "time" : "99.399757572", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "db_commit_transaction(02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706)" },
{ "type" : "DEBUG", "time" : "99.408130983", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Queued pkt PKT__PKT_OPEN (order=0)" },
{ "type" : "DEBUG", "time" : "99.408137194", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "CMD_OPEN_WITH_ANCHOR: STATE_INIT => STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR (out PKT__PKT_OPEN)" },
{ "type" : "DEBUG", "time" : "99.408148105", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "pkt_out: writing PKT__PKT_OPEN" },
{ "type" : "DEBUG", "time" : "99.615157245", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Decrypted header len 5" },
{ "type" : "DEBUG", "time" : "99.615197380", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Received packet LEN=5, type=PKT__PKT_RECONNECT" },
{ "type" : "DEBUG", "time" : "99.615203960", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "CMD_SEND_COMMIT: STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR => STATE_ERR_INTERNAL" },
{ "type" : "BROKEN", "time" : "99.615214327", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Entered error state STATE_ERR_INTERNAL" },
{ "type" : "INFO", "time" : "99.615229732", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Peer breakdown: nothing to do" },
{ "type" : "DEBUG", "time" : "99.615235671", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "peer_breakdown: STATE_ERR_INTERNAL => STATE_CLOSED" },
{ "type" : "DEBUG", "time" : "99.615247719", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "db_forget_peer(02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706)" },
{ "type" : "DEBUG", "time" : "99.615261653", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "db_start_transaction(02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706)" },
{ "type" : "DEBUG", "time" : "99.615714001", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "db_commit_transaction(02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706)" },
{ "type" : "DEBUG", "time" : "99.620063221", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "pkt_out: no IO possible, closing" },
{ "type" : "INFO", "time" : "99.620095618", "source" : "02915506c736ffec49ad58fc021779600dcd2b7a52ac97690571aea5b4d9be2706:", "log" : "Disconnected" },
This is a tracking issue for the gossip overhaul for the new architecture.
gossipd
gossipd
is not the ownergetnodes
JSON-RPC callgetroute
JSON-RPC callgetchannels
JSON-RPC callannouncement_signatures
Depending on the decision on #126, we also need to
u16
to u32
(might need some additional refactoring since currently we simply reuse the external wire format).Currently nodes only announce on a very long timer or when node joins the channel. If a new channel is established the endpoints will not announce it right away, instead they'll wait for one of the above triggers.
Eg. for onion pubkeys, we can use the hash of privkey etc. This would avoid entropy issues, but needs to be done carefully to avoid possible reuse.
I was contacted by a Freenode staff member, informing me that the channel will get kicked off the network at the end of the week.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.