In particular, decode error messages correctly and do the right thing with
messages about other channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Right now it allows ping but not pong.
If A sends a ping expecting a pong to B during CHANNELD_AWAITING_LOCKIN,
It would result in
`STATUS_FAIL_PEER_BAD: WIRE_PONG (19) before funding locked`
resulting in a unilateral channel close by A.
Disabling the channel and enqueing the update for broadcast so we
don't get forwarding requests from remote peers, and we don't try to
ourselves.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Sends a disable channel_update before issuing the shutdown message,
gossipd will also take care to update others and not use for future
routes.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Travis gave an error:
```
DEBUG:root:lightningd(16333): lightning_closingd(8004): STATUS_FAIL_PEER_BAD: Expected closing_signed:
0085b679bd79b836b05c649cad9af31156cb1d50de448a59c6359ab7c85f4b63913d2e3bc8ad4a80ab698558e5b4949b78dc36acc90dde4f5ac006fd6ca1d109feea03aef9c718e9ce09bbb52dc8308ba8f46b43808ea1a551d41aee72af7af77628d1
```
Which is caused by us not waiting for the revoke-and-ack from a feechange
when we're shutting down.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We could do this lazily, if HTLC errors out, but we do it as HTLCs
come in in the normal case, so this is slightly simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This, of course, should never be used. But it helps maintain connections
for the moment while we dig deeper into feerates.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. htlc->fail has been changed to a u8 *.
2. wallet_get_newindex saves to the db.
3. peer->next_htlc_id is saved to the db in peer_save_commitsig_sent() below.
4. We do store commit in peer_save_commitsig_received(peer, commitnum),
and the fixme below talks about HTLC sigs.
5. We do commit shachain and next_per_commit_point in wallet_shachain_add_hash
and update_per_commit_point respectively.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our handling of SIGPIPE was incoherent and inconsistent, and we had much
cut & paste between the daemons. They should *ALL* ignore SIGPIPE, and
much of the rest of the boilerplate can be shared, so should be.
Reported-by: @ZmnSCPxjFixes: #528
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's just a sha256_double, but importantly when we convert it to a
string (in type_to_string, which is used in logging) we use
bitcoin_blkid_to_hex() so it's reversed as people expect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's just a sha256_double, but importantly when we convert it to a
string (in type_to_string, which is used in logging) we use
bitcoin_txid_to_hex() so it's reversed as people expect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I noted a spurious failure on test_reconnect_sender_add1: we
actually sent an update_commit, which should have been suppressed.
This was because we call dev_disconnect() when we *dequeue* the packet,
which might be too late to suppress the timer. So instead, call it
when the packet in enqueued, and flush synchronously to make sure
we get the right packet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We create a temporary tx which is a child of the real tx, for simplicity of
marshalling. That's OK.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When gossipd sends a message, have a gossip_index. When it gets back a
peer, the current gossip_index is included, so it can know exactly where
it's up to.
Most of this is mechanical plumbing through openingd, channeld and closingd,
even though openingd and closingd don't (currently) read gossip, so their
gossip_index will be unchanged.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The #389 introduced some changes that conflicted with
9de3827199 so this ports those changes
into #389 and fixes the `master` branch again.
Lesson learned: always rebase a PR before merging.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The same as master request/response: we queue up incoming replies we
don't want for later processing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We revert to a simple select() loop. This makes things simpler, and fixes
the problem where we want to exit but we've partially read a peer packet.
We still queue up outgoing peer packets for non-blocking send: if we
went full sync there, we'd risk deadlock if both sides wrote a huge
number of packets and neither was reading.
This also greatly simplifies the next patches, where we want to make
our first get/response from gossipd.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The master now hands channeld either an error code, and channeld
generates the error message, or an error message relayed from another
node to pass through.
This doesn't fill in the channel_update yet: we need to wire up gossipd
to give us that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently lightningd does this, but channeld is perfectly capable of doing it.
channeld is also in a far better position to add channel_updates to it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The bulk of this patch is actually hoisting the get_shared_secret()
function (unchanged) so we can call it earlier.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can tell this more generically because the count of revocations
received != count of commitments sent. This is the correct condition
which allows us to restore the test we had to eliminate in
c3cb7f1c85.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only send them when we're not awaiting revoke_and_ack: our
simplified handling can't deal with multiple in flights.
Closes: #244
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can have it happen on reconnect due to fee changes; we should really
detect this case, but it's harmless to let it happen as a noop.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Handling feerates for the fundee (who only receives fee_update) is
simple: it's practically atomic since we accept commitment and send
revocation, thus they're applied to both sides at once.
Handling feerates for the funder is more complex: in theory we could
have multiple in flight. However, if we avoid this using the same
logic as we use to suppress multiple commitments in flight, it's
simple again.
We fix the test code to use real feerate manipulation, thus have to
remove an assert about feerate being non-zero. And now we have
feechanges, we need to rely on the changes_pending flags, as we can
have changes without an HTLCs changing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
rvandermeer
Ephraim Raj
practicalswift
Christian Decker