We now need to use bitcoin_witness_htlc with the r value, so that API
is updated to take 'struct rval' or 'struct sha256'.
We use the nc->delay amount (ie. dstate->config.min_htlc_expiry) to
wait for a timeout refund to be buried before "failing" upstream.
This should probably be made into a clearer parameter rather than
overloading this one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'dont-use-peer-nc-in-onchain-code.patch':
peer: Don't use peer->nc->delay for onchain case.
Use the config var directly. We should be freeing peer->nc when the
connection dies anyway.
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>
If a block triggers two peers to close, we ran io_break() on both of them; the
second overrode the first and we didn't end up freeing that one.
Rather than chase such bugs in future, simply iterate to see if any
peers need freeing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Note that the base fee is in millisatoshi, the proportional fee is
in microsatoshi per satoshi. ie. 1,000,000 means charge 1 satoshi for
every satoshi carried.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Most HTLCs we offer are triggered by an incoming HTLC from a different
peer. Save this "source" htlc, so we can fail/fulfill it when we
fail/fulfill this one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
No more copies!
I tried changing the cstate->side[].htlcs to htlc_map rather than a
simple pointer array, but we rely on those array indices heavily for
permutation mapping, and it turned into a major rewrite (especially
for the steal case).
Eventually, we're going to want to reconstruct the commit info for
older commit txs rather than keeping all the permutation and
per-commit-info HTLC information in memory, so we can do the work
then.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's a more logical name, and a more logical place. We change
"funding" to "channel" in the remaining exposed symbols, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the logical place for it to belong: with the HTLC. For the manually-created
HTLCs, we create a simple one-hop route.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the more normal case; find by ID. The low-level json commands are
really just for testing.
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>
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>
We've been stuffing these into sha256s, but they're actually nonces.
Create a new structure for that for clarity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And make the add/fail/fulfill arg a pointer to a union htlc_staging
directly, removing struct htlc_progress.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We no longer get bitcoind to manage our transactions for us, so we don't
need to -zapwallettxs when an anchor fails.
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're about to allow changes while we're waiting for a commit ack.
This means we can't have a single "unacked changes" queue; when we
receive the revocation reply, we need to apply the unacked changes
known at the time we sent the commit, not any we've created since
then.
Note that we still only have a single staged_commit; we never have two
outstanding commits, since for simplicity we will still block
following update_commit pending the reply to the current one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As per lightning-rfc commit b8469aa758a1a7ebbd73c987be3e5207b778241b
("re-protocol: don't hand signature to non-funding side initially.")
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We still need to watch the anchor output in this case: that's what
makes us handle the commit transcction we broadcast.
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>
Previous to this, we kept the remote side's 'struct channel_state'
backwards: peer->remote.commit->cstate.side[OURS] was their HTLCs,
and [THEIRS] was our HTLCs. This made some things easier, but was
horrible for readability.
This inverts things so we keep track of the remote side's state from
our point of view: [OURS] is ours, [THEIRS] is theirs. Which makes
much more sense.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As per lightning-rfc commit 8ee09e749990a11fa53bea03d5961cfde4be4616,
we remove the acks from the protocol now they're no longer needed (and
all the infrastructure).
We also place the commit number in the commit_info where it logically
belongs, removing it from the peer struct.
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>
