* [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks [not found] ` <CALxbBHU-_sC7Qr=U5TMtB_Gs6fe1QnskAaYrLhp1_7Zqc-m8cg@mail.gmail.com> @ 2017-08-17 11:31 ` Bryan Bishop 2017-08-17 12:48 ` Conrad Burchert 0 siblings, 1 reply; 3+ messages in thread From: Bryan Bishop @ 2017-08-17 11:31 UTC (permalink / raw) To: Bitcoin Dev, Bryan Bishop, Martin Schwarz, Christian Decker [-- Attachment #1: Type: text/plain, Size: 2498 bytes --] ---------- Forwarded message ---------- From: Christian Decker <decker.christian@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 <martin.schwarz@gmail•com>, lightning-dev@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 On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz@gmail•com> wrote: > 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 > Lightning-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > _______________________________________________ Lightning-dev mailing list Lightning-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- - Bryan http://heybryan.org/ 1 512 203 0507 [-- Attachment #2: Type: text/html, Size: 4030 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks 2017-08-17 11:31 ` [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks Bryan Bishop @ 2017-08-17 12:48 ` Conrad Burchert 2017-08-17 13:38 ` Natanael 0 siblings, 1 reply; 3+ messages in thread From: Conrad Burchert @ 2017-08-17 12:48 UTC (permalink / raw) To: Bryan Bishop, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4321 bytes --] 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 < bitcoin-dev@lists•linuxfoundation.org>: > > ---------- Forwarded message ---------- > From: Christian Decker <decker.christian@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 <martin.schwarz@gmail•com>, lightning-dev@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 > > On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz@gmail•com> > wrote: > >> 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 >> Lightning-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > -- > - Bryan > http://heybryan.org/ > 1 512 203 0507 <(512)%20203-0507> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6599 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks 2017-08-17 12:48 ` Conrad Burchert @ 2017-08-17 13:38 ` Natanael 0 siblings, 0 replies; 3+ messages in thread From: Natanael @ 2017-08-17 13:38 UTC (permalink / raw) To: Bitcoin Dev, Conrad Burchert [-- Attachment #1: Type: text/plain, Size: 5131 bytes --] 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" < bitcoin-dev@lists•linuxfoundation.org>: > 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 < > bitcoin-dev@lists•linuxfoundation.org>: > >> >> ---------- Forwarded message ---------- >> From: Christian Decker <decker.christian@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 <martin.schwarz@gmail•com>, >> lightning-dev@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 >> >> On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz@gmail•com> >> wrote: >> >>> 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 >>> Lightning-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> >> >> >> -- >> - Bryan >> http://heybryan.org/ >> 1 512 203 0507 <(512)%20203-0507> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 7946 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-08-17 13:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAKhySQxKvR+1g8Y-OeDjAZj2jDgHub2iJceu_y44t0b+prKYXQ@mail.gmail.com>
[not found] ` <CALxbBHU-_sC7Qr=U5TMtB_Gs6fe1QnskAaYrLhp1_7Zqc-m8cg@mail.gmail.com>
2017-08-17 11:31 ` [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks Bryan Bishop
2017-08-17 12:48 ` Conrad Burchert
2017-08-17 13:38 ` Natanael
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox