[Lightning-dev] Lightning in the setting of blockchain hardforks

[Rusty Russell]

Christian Decker <decker.christian at gmail.com> writes:
> Hi Martin,
>
> this is the perfect venue to discuss this, welcome to the mailing list :-)
> Like you I think that using the first forked block as the forkchain's
> genesis block is the way to go, keeping the non-forked blockchain on the
> original genesis hash, to avoid disruption. It may become more difficult in
> the case one chain doesn't declare itself to be the forked chain.
>
> Even more interesting are channels that are open during the fork. In these
> cases we open a single channel, and will have to settle two. If no replay
> protection was implemented on the fork, then we can use the last commitment
> to close the channel (updates should be avoided since they now double any
> intended effect), if replay protection was implemented then commitments
> become invalid on the fork, and people will lose money.

I don't think 2x will have 2-way replay protection; if it gets anything
it will be opt-in.

But yes, closing the channel on the fork is the Right Thing.  There's
been discussion of a standalone "salvage" utility, which you'd supply
all the keys and information you have and a connection to a full node,
and it would try to get your money back.  Ideally, it would work with
any of the implementations.

Perhaps this is something to work on?  Christian, are you bored? :)

Cheers,
Rusty.