This means we can now do all database changes, including db_set_visible_state,
within a single transaction (ie. atomically).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we no longer feed it into state.c, we can just us a bool.
And that's the last of the CMD_* in the enum state_input, so remove them
all.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can get weird errors when we try to load a database of a different
from. Just slap a git version in there for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pierre points out that we don't handle this, and it can happen due
to race; the spec says we are not supposed to send PKT_CLOSE with
uncommitted changes.
Closes: #29
Reported-by: Pierre-Marie Padiou
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means running 3 bitcoinds, which is slow enough to start on my laptop
that I need to increase the startup wait for 30 to 60 seconds, and similarly
the test.sh check loop.
Before: real 13m42.868s
After: real 8m19.563s (make -j3)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Waiting until lightningd is up is too long: do a --version test in setup,
and then check that all reported versions match later on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise if they reconnect, we hit the assert in recv_body:
assert(!peer->inpkt);
Found by testing on my build box *without* valgrind (so it was fast
enough to do this).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Running on my build machine, without valgrind, it managed to exchange
closing sigs before restart, and spotted this bug.
Fixes: #76
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
broadcast_remainder() does two things: get the error message for the
previous transaction, and send the next one (shrinking the array).
But it has two bugs:
1) It logs results on the tx at the end of the array, which is the one
it is *about* to send, and
2) The initial caller (rebroadcast_txs) hands it the complete array,
so the first tx gets broadcast twice.
The correct thing to do is to strip the array, then send the tail for
the next callback. And use nicely-named vars to help document what
we're doing.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now broadcast_tx() doesn't take ownership of the tx, make sure callers
free; a bit of refactoring to make it clear when we're making a new tx
vs. accessing an existing one, to make this clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is in preparation for the next step.
Note that we now don't add it to the linked list of txs we've send
until after it's sent by the immediate callback; this means it won't
get broadcast by the timer until after it's been done by broadcast_tx.
Also, this means we no longer steal the tx in broadcast_tx(); but we'll fix
up the leaks 4 patches later.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't simply parent them on the object, we use a dummy object which tells
us not to call the callback if freed.
This would be better fixed by rewriting ccan/io to handle tal_free() of
a conn; then we could simply parent the entire thing and forget about it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Testnet fees are all over the place: don't close a connection due to
that.
Closes: #59
Reported-by: Thomas Daede <daede003@umn.edu>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This fixes half of #59 (the part which crashes). It doesn't fix the
fact that we should never be doing this for testnet.
Reported-by: Thomas Daede <daede003@umn.edu>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Allocate the route off the current command, not dstate. And in the
case where the route is somehow not via a peer, don't leak memory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Generally, the pattern is: everything returned is allocated off the return
value, which is the only thing allocated off the context. And it's always
freed.
Also, tal_free() returns NULL, so it's useful for one-line error
cleanups.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This shouldn't happen, but if our RNG is busted and get a duplicate,
r would be NULL.
(scan-build found this)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`listinvoice` was not handling numeric labels correctly if they are not
passed in as JSON strings (which was the behavior of
`lightning-cli`). So now we accept both string labels as well as numeric
labels.
The JSON-RPC was non-standard compliant in that it omitted the required
`jsonrpc` entry and it was returning both `error` as well as
`result`. This fixes both of these issues.
Fixes#50. Was causing a segfault because it was creating an empty route
and was trying to extract the first hop as next hop. Routes through self
can still be created manually, but `sendpay` would still refuse to act
on them due to the missing self-link.
We're going to wean off IRC, but as a quick fix, only announce 0-60 seconds
after we see a join, or every 6 hours.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We've seen intermittant failures on testnet, so disable sending feechanges
for now: we're completely changing it for 0.6 anyway, due to Milan Spec.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Make this always the first packet after auth. That means there's no
reliance on whether a node remembers an aborted connection.
It also gives us a place to put version bits.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This gives much better errors, and allows us to return the peer id.
Closes: #37
Reported-by: Glenn Willen
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
My lightning node was *way* behind, and I couldn't figure out why it
wasn't seeing channel establishment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, remove fee ranges on testnet (too unreliable) and accept
a single confirm.
(Note that an earlier version of this had a bug when there was no
config file, this version includes the fix).
Closes: #40
Reported-by: Glenn Willen
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Firstly, we need to update the staging fee amount when we queue a change.
Secondly we need to remove completed fee updates, otherwise we hit a
database constraint that peer & state are unique.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We were out by 1000, and also derived it from the previous, not current
state.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We store peers in the database for STATE_INIT, but they don't reconnect
properly. We should not forget STATE_INIT dropped peers, but use some
timeout mechanism if we can't reconnect to clean up.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Three days of on and off debugging, before I realized my server was talking
to a non-testnet bitcoind. There was a bitcoind on that machine running
on testnet, but it uses the same dir and config, so the --bitcoin-datadir
option couldn't help.
This is more certain: specify whether we're testnet on every single query.
Now we can skip the attempt to parse bitcoin.conf, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
getnodes returns an object containing a single array of 'nodes'. Each
element contains the node's ID, its hostname and its port. If
unknown (because we haven't seen a node announcement yet) then the port
is 0 and the hostname is null.
lightningd now uses a WHOIS query on itself to learn its external IP
address and announces that on the channel with the NODE message. It also
tracks other nodes in the routing table.
Refactored the signature verification to reuse it for both CHAN and NODE
messages.
'getchannels' returns a 'channels' array containing an object for each
known channel. Each channel object represents one direction of a
bidirectional channel, with a from and a to node ID along with the fees
for that direction. This matched the internal storage of channels and
allows unbalanced fees for each direction.
We *should* be in a state which accepts it (could happen with reorg),
and there's no reason to test for greater than depth since we must process
blocks in order.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently we get the odd message "Own anchor has insufficient funds".
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
NO_VALGRIND= daemon/test/test.sh --normal --restart
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
This is expected: it happens when node3 is restarting. Redirect
errors to /dev/null.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added channel announcement serialization and parsing, as well as the
entrypoints for the IRC peer discovery. Announcements are signed by the
sending endpoint and signatures are verified before adding the channels
to the local view of the topology. We do not yet verify the existence of
the anchor transaction.
It's not in a transaction in one caller, so wrap that.
This removes some more error handling code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rename the structs to match (and remove dev-echo).
This makes it clear that they're not the normal API.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need some ordering to deliver them to the JSON "waitinvoice" command;
we use a counter where 0 means "unpaid".
We keep two lists now, one for unpaid and one for paid invoices.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
I had some nonsensical columns, eg "bool ours", but sqlite3 pretty much
ignores them. Use macros so mistakes are harder to make.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is important when we put payments in the database: they need to be
updated atomically as the HTLC is.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is important when we put payments in the database: they need to be
updated atomically as the HTLC is.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had enum channel_side (OURS, THEIRS) for which end of a channel we
had, and htlc_side (LOCAL, REMOTE) for who proposed the HTLC.
Combine these both into simply "enum side".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, make sure B can just afford it, then have the A add a
HTLC which means B can no longer afford the fees, and A should cover
it.
We do this by modifying the previous overlapping-fail test, but we
need to have B offer it the htlc before A does: racy in the normal
autocommit case. So we do a manual commit here, always.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When they propose an HTLC to us, they need to be able to cover both it,
and the associated fees. When it gets acked and applied to them, however,
they may no longer be able to afford the fees; this is OK and expected.
So add a flag to say whether they can dig into fees or not: without
this patch the code calls fatal() on the next patch which tests it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
