lukechilds
/
lightning
mirror of https://github.com/lukechilds/lightning.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4566 Commits
55 Branches
107 Tags
38 MiB
Branch: json-streaming
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'json-streaming'
${ noResults }
lightning/lightningd/closing_control.h

16 lines
426 B
Raw Permalink Normal View History

lightningd/closing_control: routines to control closingd (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
#ifndef LIGHTNING_LIGHTNINGD_CLOSING_CONTROL_H
#define LIGHTNING_LIGHTNINGD_CLOSING_CONTROL_H
#include "config.h"
#include <ccan/short_types/short_types.h>
struct channel_id;
struct crypto_state;
void peer_start_closingd(struct channel *channel,
lightningd: re-allow closing negotiation when CLOSINGD_COMPLETE d822ba1ee accidentally removed this case, which is important: if the other side didn&#39;t get our final matching closing_signed, it will reconnect and try again. We consider the channel no longer &#34;active&#34; and thus ignore it, and get upset when it send the `channel_reestablish` message. We could just consider CLOSINGD_COMPLETE to be active, but then we&#39;d have to wait for the closing transaction to be mined before we&#39;d allow another connection. We can&#39;t special case it when the peer reconnects, because there could be (in theory) multiple channels for that peer in CLOSINGD_COMPLETE, and we don&#39;t know which one to reestablish. So, we need to catch this when they send the reestablish, and hand that msg to closingd to do negotiation again. We already have code to note that we&#39;re in CLOSINGD_COMPLETE and thus ignore any result it gives us. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
const struct crypto_state *cs,
lightningd/closing_control: routines to control closingd (move from peer_control.c) Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
int peer_fd, int gossip_fd,
lightningd: re-allow closing negotiation when CLOSINGD_COMPLETE d822ba1ee accidentally removed this case, which is important: if the other side didn&#39;t get our final matching closing_signed, it will reconnect and try again. We consider the channel no longer &#34;active&#34; and thus ignore it, and get upset when it send the `channel_reestablish` message. We could just consider CLOSINGD_COMPLETE to be active, but then we&#39;d have to wait for the closing transaction to be mined before we&#39;d allow another connection. We can&#39;t special case it when the peer reconnects, because there could be (in theory) multiple channels for that peer in CLOSINGD_COMPLETE, and we don&#39;t know which one to reestablish. So, we need to catch this when they send the reestablish, and hand that msg to closingd to do negotiation again. We already have code to note that we&#39;re in CLOSINGD_COMPLETE and thus ignore any result it gives us. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
bool reconnected,
const u8 *channel_reestablish);
lightningd/closing_control: routines to control closingd (move from peer_control.c) Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
#endif /* LIGHTNING_LIGHTNINGD_CLOSING_CONTROL_H */