Discussion:
Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks
(too old to reply)
Bryan Bishop via bitcoin-dev
2017-08-17 11:31:30 UTC
Permalink
Raw Message
---------- Forwarded message ----------
From: Christian Decker <***@gmail.com>
Date: Thu, Aug 17, 2017 at 5:39 AM
Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
hardforks
To: Martin Schwarz <***@gmail.com>,
lightning-***@lists.linuxfoundation.org


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.

Fun times ahead :-)

Cheers,
Christian
Dear all,
currently the chain_id allows to distinguish blockchains by the hash of
their genesis block.
With hardforks branching off of the Bitcoin blockchain, how can Lightning
work on (or across)
distinct, permanent forks of a parent blockchain that share the same
genesis block?
I suppose changing the definition of chain_id to the hash of the first
block of the new
branch and requiring replay and wipe-out protection should be sufficient.
But can we
relax these requirements? Are slow block times an issue? Can we use
Lightning to transact
on "almost frozen" block chains suffering from a sudden loss of hashpower?
Has there been any previous discussion or study of Lightning in the
setting of hardforks?
(Is this the right place to discuss this? If not, where would be the right
place?)
thanks,
Martin
_______________________________________________
Lightning-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-***@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
- Bryan
http://heybryan.org/
1 512 203 0507
Conrad Burchert via bitcoin-dev
2017-08-17 12:48:15 UTC
Permalink
Raw Message
Some notes:

Hardforks like Bitcoin ABC without a malleability fix are very unlikely to
have payment channels, so the problem does not exist for those.

The designers of a hardfork which does have a malleability fix will
probably know about payment channels, so they can just build a replay
protection that allows the execution of old commitments. That needs some
kind of timestamping of commitments, which would have to be integrated in
the channel design. The easiest way would be to just write the time of
signing the commitment in the transaction and the replay protection accepts
old commitments, but rejects one's which were signed after the hardfork.
These timestamps can essentially be one bit (before or after a hardfork)
and if the replay protection in the hardfork only accepts old commitments
for something like a year, then it can be reused for more hardforks later
on. Maybe someone comes up with an interesting way of doing this without
using space.

Nevertheless hardforking while having channels open will always be a mess
as an open channel requires you to watch the blockchain. Anybody who is
just not aware of the hardfork or is updating his client a few days too
late, can get his money stolen by an old commitment transaction where he
forgets to retaliate on the new chain. As other's can likely figure out
your client version the risk of retaliation is not too big for an attacker.



2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
---------- Forwarded message ----------
Date: Thu, Aug 17, 2017 at 5:39 AM
Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
hardforks
linuxfoundation.org
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.
Fun times ahead :-)
Cheers,
Christian
Dear all,
currently the chain_id allows to distinguish blockchains by the hash of
their genesis block.
With hardforks branching off of the Bitcoin blockchain, how can Lightning
work on (or across)
distinct, permanent forks of a parent blockchain that share the same
genesis block?
I suppose changing the definition of chain_id to the hash of the first
block of the new
branch and requiring replay and wipe-out protection should be sufficient.
But can we
relax these requirements? Are slow block times an issue? Can we use
Lightning to transact
on "almost frozen" block chains suffering from a sudden loss of hashpower?
Has there been any previous discussion or study of Lightning in the
setting of hardforks?
(Is this the right place to discuss this? If not, where would be the
right place?)
thanks,
Martin
_______________________________________________
Lightning-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
- Bryan
http://heybryan.org/
1 512 203 0507 <(512)%20203-0507>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Natanael via bitcoin-dev
2017-08-17 13:38:26 UTC
Permalink
Raw Message
Couldn't scripts like this have a standardized "hardfork unroll" mechanism,
where if a hardfork is activated and signaled to its clients, then those
commitments that are only meant for their original chain can be reversed
and undone just on the hardfork? Then the users involved would just send an
unroll transaction which is only valid on the hardfork.

- Sent from my phone

Den 17 aug. 2017 14:52 skrev "Conrad Burchert via bitcoin-dev" <
Post by Conrad Burchert via bitcoin-dev
Hardforks like Bitcoin ABC without a malleability fix are very unlikely to
have payment channels, so the problem does not exist for those.
The designers of a hardfork which does have a malleability fix will
probably know about payment channels, so they can just build a replay
protection that allows the execution of old commitments. That needs some
kind of timestamping of commitments, which would have to be integrated in
the channel design. The easiest way would be to just write the time of
signing the commitment in the transaction and the replay protection accepts
old commitments, but rejects one's which were signed after the hardfork.
These timestamps can essentially be one bit (before or after a hardfork)
and if the replay protection in the hardfork only accepts old commitments
for something like a year, then it can be reused for more hardforks later
on. Maybe someone comes up with an interesting way of doing this without
using space.
Nevertheless hardforking while having channels open will always be a mess
as an open channel requires you to watch the blockchain. Anybody who is
just not aware of the hardfork or is updating his client a few days too
late, can get his money stolen by an old commitment transaction where he
forgets to retaliate on the new chain. As other's can likely figure out
your client version the risk of retaliation is not too big for an attacker.
2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
---------- Forwarded message ----------
Date: Thu, Aug 17, 2017 at 5:39 AM
Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
hardforks
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.
Fun times ahead :-)
Cheers,
Christian
Dear all,
currently the chain_id allows to distinguish blockchains by the hash of
their genesis block.
With hardforks branching off of the Bitcoin blockchain, how can
Lightning work on (or across)
distinct, permanent forks of a parent blockchain that share the same
genesis block?
I suppose changing the definition of chain_id to the hash of the first
block of the new
branch and requiring replay and wipe-out protection should be
sufficient. But can we
relax these requirements? Are slow block times an issue? Can we use
Lightning to transact
on "almost frozen" block chains suffering from a sudden loss of hashpower?
Has there been any previous discussion or study of Lightning in the
setting of hardforks?
(Is this the right place to discuss this? If not, where would be the
right place?)
thanks,
Martin
_______________________________________________
Lightning-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
- Bryan
http://heybryan.org/
1 512 203 0507 <(512)%20203-0507>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...