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 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>
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>
This is less convenient to use, but makes far more sense for a real
user (like a wallet). It can ask about the route, then decide whether
to use it or not.
This will make even more sense once we add a parameter to control how
long we let the HTLC be delayed for, so a client can query for high,
medium and low tolerances and compare results.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We stopped automatically retransmitting locally-generated add/removes
after a reconnect, but this breaks the "pay" interface as it stands.
The correct solution to this is to make the pay interface idempotent:
you can trigger it as many times as you want and it will only succeed
once.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's not currently encrypted, but at least you get some idea now why
an HTLC failed. We (ab)use HTTP error codes for the moment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These low level commands we restarted on reconnect for ease of
testing. Don't do that, and check that we're connected when those
commands occur.
This introduces subtle issues with --manual-commit --reconnect: restarting
node1 also forgets uncommitted things from node2, requiring reordering for
some tests.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We capture the output in case we need to resubmit the command after restarting,
but we weren't printing it out on failure (set -e means we'd stop immediately).
As a side-effect of this change, we don't restart after failed
commands, which caused another bug: we were writing the 2->3 route to
the config file, but not restarting again, so we lost the route.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows hardcoded routes in the config file, which is required until
we get route advertisements.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Testing this revealed that we can't just reconnect when we have something to
send, as we might be NATed; we should try to reconnect anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We add a "dev-restart" command which causes the daemon to close fds
and exec itself. Then we do it after every command, with the caveat
that we always send a commit before newhtlc, because if not committed,
that is forgotten. Fulfillhtlc and failhtlc get resent, since they're
idempotent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To do this we keep an order counter so we know how to retransmit. We
could simply keep old packets, but this is a little clearer for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids us having to query it when we create anchor transaction, and
lets us always use dynamic fee information.
The config options for max and min are now percentages, rather than absolute.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're weaning off the cstate arrays; use the htlc map. But for the
moment we keep the output basically the same.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had an occasional race where we hadn't gotten the remote revocation
before submitting fulfill (spotted by the HTLC state transition code).
Disallow this, but also add to the json output so we can wait for
an HTLC to be irrevocably committed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we always remove " from JSON, our parsing becomes simpler; turns
out that we did that in some places, and check()'s eval removed them
from the comparison.
We extract check_balance_single() to check the general balance, then
grep for HTLCs separately.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Thus a node MUST estimate the deadline for successful redemption for
each HTLC it offers. A node MUST NOT offer a HTLC after this
deadline, and MUST fail the connection if an HTLC which it offered is
in either node's current commitment transaction past this deadline.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the command an actual user would use: it figures out the fee
and route, and pays it if it can.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The protocol still supports both, but we now only support blocks.
It's hard to do risk management with timeouts in seconds, given block
variance. This is also signficantly simpler, as HTLC timeouts are
always fired in response to blocks, not wall-clock times.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A new 'accept-payment' command tells the node to fulfill HTLCs using
the R value if the amount is correct. It's not wired in yet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to know when changes are fully committed by both sides:
1) For their HTLC_ADDs, this is when we can fulfill/fail/route.
2) For their HTLC_FAILs, this is when we can fail incoming.
For HTLC_FULFULL we don't need to wait: as soon as we know the preimage
we can propogate it.
For the moment, we simply log and assert; acting on it comes later.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Segwit was merged, but the strings changed between there and segwit4
(also, my BIP9 patch changed the output).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This would have revealed the previous breakage (and I tested that!),
plus now we test negotiate on closing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There's no real reason to avoid commands for the next commit; this has
the benefit that we can remove the infrastructure to queue commands.
The only exceptions are the commit command and the opening phase.
We still only allow one commit at a time, but that's mainly run off a
timer which can try again later. For the JSONRPC API used for
testing, we can simply fail the commit if one is in progress.
For opening we add an explicit peer_open_complete() call in place of
using the command infrastructure.
Commands are now outside the state machine altogether: we simply have
it return the new state instead of the command status. The JSONRPC
functions can also now run commands directly.
This removes the idea of "peercond" as well: you can simply examine
the states to determine whether an input is valid. There are
fine-grained helpers for this now, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We already removed the on-chain states, now we remove the "clearing" state
(which wasn't fully implemented anyway).
This turns into two smaller state machines: one for clearing, which
still allows HTLCs to be failed and fulfilled, and one for mutual
close negotiation which only allows close_signature messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From BOLT#2 (rev 8ee09e749990a11fa53bea03d5961cfde4be4616):
Thus each node (conceptually) tracks:
...
3. Two *unacked changesets*: one for the local commitment (their proposals) and one for the remote (our proposals)
4. Two *acked changesets*: one for the local commitment (our proposals, acknowledged) and one for the remote (their proposals, acknowledged).
(Note that an implementation MAY optimize this internally, for
example, pre-applying the changesets in some cases).
In our case, we apply the unacked changes immediately into
staging_cstate, and save them in an unacked_changes array. That array
gets applied to staging_cstate as soon as it's acked (we only allow
one outstanding update_commit, so we only need one array).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
While useful for testing, it doesn't make sense to have an explicit commit
command; we should commit whenever there are outstanding changes.
We have a 10ms timer to allow limited batching, however.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently this mean --bitcoin-poll; we're going to change the other time
options to block heights anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They would sometimes fail under load, if using valgrind. Retry
properly rather than relying on random sleeps. Also, takes "make
check" running time here from 1m31.864s to 1m16.872s.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use dev-disconnect to convince one node the other has disconnected
(but not vice versa), to get deterministic behaviour. We do this with
one HTLC outstanding, to test the HTLC timeout path.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Once we see an on-chain tx, we ignore the state machine and handle it
as per the onchain.md draft. This specifies a *resolution* for each
output, and we're done when they're irrevocable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is called when an HTLC times out, and we need to send it back to
ourselves. We also adjust the locktime, since in practice we should
refuse an HTLC less than our locktime.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than p2sh of a 2of2, it's now a version 0 witness program.
This means that the commit transaction input and mutual close
transaction input are both different.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than polling for interesting bitcoin txs via importaddress, we use
the chain topology to register our interest directly.x
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
With segregated witness, we can (in advance!) specify the txid or tx
output we want to watch, so convert to that now. For the moment it's
done by pretending we have normalized txids; that goes away after the
conversion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us live in a segwit world, before segwit. It's a shim which we
can remove once we've changed all our outputs.
We need a few more sleeps in our test script, since we've slowed
things down by doing these calls for every tx in every block.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You need to be running a bitcoind modified with segregated witness:
https://github.com/sipa/bitcoin/tree/segwit4
It needs 432 blocks to activate it!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We got the -> second translation wrong by a factor of 512, and also we
need to move the median time in our tests otherwise bitcoind won't let
us spend the tx.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We now keep a list of commitment transaction states for "us" and
"them", as well as a "struct channel_state" for staged changes.
We manipulate these structures as we send out packets, receive
packets, or receive acknowledgement of packets. In particular, we
update the other nodes' staging_cstate as we send out our requests,
and update our own staging_cstate are we receive acks. When we
receive a request, we update both (as we immediately send out our
ack).
The RPC output is changed; rather than expose the complexity, we
expose our last committed state: what would happen if we have to drop
to the blockchain now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And divide fees as specified there.
We still use fixed values rather than floating, and we don't send or
handle update_fee messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to have a hacky close timeout which would immediately fire
when we'd closed because the connection was down. Far better to have
a specific "connection lost" input, and have it respond like CMD_CLOSE.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is only for the simple case where there are no HTLCs.
We group the current commit information together in the struct;
this involves a trivial transform from peer->cur_commit_theirsig to
peer->cur_commit.theirsig.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We abort when this happens, but still worth testing.
This involves a refactor so we can allocate watches off a specific context,
for easy freeing when they're no longer wanted.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We do the simplest thing: a timer goes off, and we check all HTLCs for
one which has expired more than 30 seconds ago.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell