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 no longer need it anywhere. This simplifies things to the point where
we might as well just not include dust outputs as we go, rather than
explicitly removing them, which gets rid of remove_dust.c as well.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Similar to the way we derive which outputs are which for old transactions
we steal, we derive them even for their current transaction.
We keep track of this information in peer->closing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
At the moment, for our or their unilateral close, we create a resolved[]
entry for our output, their output, and each HTLC, in cstate order. Some
of these outputs might not exist (too small), so it's actually better
to simply keep a resolved[] entry for each of the tx's actual outputs.
(We already changed the steal resolved[] array to work like this, but
these are trickier, since we rely on that order if we need to fulfill an
on-chain HTLC).
It also helps as we are weaning off knowing the cstate and permutation
mapping for each commitment transaction.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want to stop keeping old commitment information (except the minimal
txid to commitment-number mapping). One place we currently use it is
after sending a commitment signature, and before we've received the
revocation for the old commitment. For this duration, there are two
valid commitment transactions.
So we store "their_prev_revocation_hash" explicitly for this duration.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's a data-leak to send ack before we have verified identity of peer.
Plus, we can't send it until we know which peer it is, anyway!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And use this to resolve old transactions by comparing outputs with
HTLCs.
Rather than remembering the output ordering for every one of their
previous commitment transactions, we just remember the commitment
number for each commitment txid, and when we see it, derive all the
HTLC scriptpubkeys and the to-us and to-them scriptpubkeys, and figure
out which is which.
This avoids us having to save information on disk, except for the
txid->commitment-number mapping (and the shachain).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes it explicit, which is better for storing in a database (before
it was just what watch callback, plus peer->local.mindepth).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Move other logic into caller, but it's not complete (it still needs to
check some things, and still records some results).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Move other logic into caller: it grew this way because we used to have
a centralized "state" machine which knew nothing of these internal
details. But now we want to re-queue packets on reconnect, we really
want these routines to be idempotent.
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>
Not separate "locally-offered" and "remotely-offered" ones; we can
distinguish them by htlc->state now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we only care about the latest commits, we can simply associate a
state with each HTLC, rather than using queues of HTLCs associated
with each commitment transaction.
This works far better in the context of a database.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need SO_REUSEADDR, and we need to memset sockaddr to zero; valgrind
complains for both IPv4 and IPv6, but the invalid sin6_flowinfo causes
the IPv6 bind to fail altogether.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From doing a code walkthrough with Christian Decker; unnecessary const in
bitcoin/tx.c, an erroneous FIXME, a missing comment, and an unused struct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is generally redundant, since HTLC pointer is in that side's
commit_info, but makes HTLC completely self-contained.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Update libsecp256k1 has a normalize function, which allows us to test
if the signature was in low-S form.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use libsecp256k1 to convert signatures to DER; we were creating a
temporary one, but we really should be handing the one we have in dstate
through. This does that, everywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
BOLT has been updated, so update code and comments. The receiving
side check is sufficient, as the limit is per-offerer, and that's the
only way the HTLCs get back to the offerer's side.
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>
There's a corner case where they had it in their commit tx, in which
case we can't fail the HTLC until our commit tx has won. Again, we
use dstate->config.min_htlc_expiry.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
This is just generally good practice. All our other txs are single-input,
so we've not needed to permute inputs before.
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>
It's not quite true: if we offer the anchor, we have a commitinfo
without their signature yet. So make it a pointer again. Since we
always allocate struct commit_info with talz, it starts as a NULL
pointer.
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>
We don't report conflicts, just depths. So we report 0 if it's in a
main chain which loses to another, otherwise it's always positive.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since bitcoind doesn't propagate non-main chains, there's little point
trying to be smart when we see them. This simplifies things immensely.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's primitive, but we re-broadcast any txs not included in the main
chain every time the tip moves. We only track transactions we are
watching, but that turns out to cover every transaction we generate
anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We watch the anchor output, and separate it into different cases.
This is simpler with segwit (txids are known before sigs), but we also
had missed the case of our own commit transaction spend.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There's no reason to, it's a simple p2wpkh to our key.
We still spend the "to-us" from our commit tx, since it could be
theoretically be stolen by the revocation value, and it's a complex
p2wsh which a normal wallet won't have the information to spend.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Turns out that we want to pass information about the commit info, the
HTLC number and (sometimes) the R value, so create a struct for that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can't re-enter the state machine from a callback, so this allows you
to queue an input for when it returns.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since 43729c6856 (protocol: add output script to close_clearing message.)
the close scripts are not p2sh, but arbitrary. Fix the close tx matching.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We just use a p2sh to a single address for the moment, but that's simply for
non-segwit wallets; we'll pay to whatever the other side specifies.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since any transaction with all segregated-witness inputs is non-malleable,
and all our transactions are that, we can remove normalized txids.
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>
There isn't a single blockhash; we may be on multiple forks. But the one
caller which cares is commit_tx_depth(), which wants to know if the tx is
spendable yet. So that uses get_last_mediantime().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We really want to do this for HTLCs; we don't do anything useful yet, but
this code replaces the direct call to bitcoind_watch_addr().
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>
Otherwise, they're malleable. We only care about our own anchor:
their anchor is their problem (and they'll probably get away with it).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is an address that bitcoind will happily pay to, but we know it's
a witness output so our inputs to the anchor are immalleable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We currently linearize and then measure the string; this is better since
we're about to do it in a second place.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need this for signing segwitness txs. Unfortunately, we don't have it
for transactions we received as hex, only ones we created; to make this safe
we use a pointer which is NULL if we don't know, and those will crash if
we try to sign or check their sigs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I had already disabled it, and this clears the decks for Segregated Witness
which gives us everything we want.
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>
Rather than creating packets then queueing them, call out to functions
which do both. This moves us towards doing more work in those functions
where we send out a request, which is sometimes clearer.
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>
We don't actually implement closing when we have HTLCs (we should
allow it, as that's what the clearing phase is for), since soon we'll
rewrite HTLC to match the async HTLC protocol of BOLT #2.
Note that this folds the close paths, using a simple check if we have
a close transaction. That's a slight state layer violation, but
reduces code duplication.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For the change to asynchronous updates as specified by BOLT #2, we
need to know when the other side acknowledged a packet. This creates
a simple callback mechanism for it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we send the first two revocation hashes; this is important
once we move to a commit model as we need to send (unsolicited) the
signature for the *next* commit tx so we need its commit hash.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This encapsulates proposals more cleanly, and is important when we change
the protocol to have more than one outstanding at a time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The channel funding code needs to know who offered the anchor, as they
are responsible for paying fees until the other side is able to. This
is actually a hack, but at least now it's internal to funding and not
passed in at every funding_delta() call.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If something goes wrong after we've broadcast the anchor tx, we need to use
the commit tx to spend it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It currently points into freed memory once we've make_commit_txs; we
don't currently dereference it after that, but I did in some test code
and got a surprise. Make a copy in all cases where we set it, so
there can't be lifetime problems.
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>
This is required for transactions which use OP_CSV to lock outputs for
a given amount of time: we need to know the mediantime of the block
they were included into.
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>
When a peer is finally to be freed (ie. STATE_CLOSED), doing this
inside the state logic is a bit fraught. We're better off exiting the
io loop and freeing it there.
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>
Otherwise we won't finish the conversation. In fact, only the writer
side should ever close: we wake it if we want to close and it tests
peer->cond.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When the only commands are via JSON, you might argue that we should
simply insist the user not operate on the same peer in parallel. That
would suck, and also we need to handle the case of a command from
a timer (eg. HTLC expiry!) or a bitcoin event.
So, we need a queue for commands, but also we need to do some of the
command checking just before the command runs: the HTLC we're dealing
with might have vanished for example.
The current command is wrapped in an anonymous "curr_cmd" struct
for extra clarity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us implement accept_pkt_anchor().
Also had to predeclare sha256 in commit_tx.h, revealed by the new
includes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
sstone