MIME-Version: 1.0
In-Reply-To: <CALxbBHU-_sC7Qr=U5TMtB_Gs6fe1QnskAaYrLhp1_7Zqc-m8cg@mail.gmail.com>
References: <CAKhySQxKvR+1g8Y-OeDjAZj2jDgHub2iJceu_y44t0b+prKYXQ@mail.gmail.com>
	<CALxbBHU-_sC7Qr=U5TMtB_Gs6fe1QnskAaYrLhp1_7Zqc-m8cg@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
Date: Thu, 17 Aug 2017 06:31:30 -0500
Message-ID: <CABaSBaxNc2rSPBhqicBakpCkVtg8YOhLs7ecC2XwKfV4fM34iw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bryan Bishop <kanzure@gmail.com>, 
	Martin Schwarz <martin.schwarz@gmail.com>,
	Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary="001a1137baaea6bef90556f15afa"
Subject: [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of
	blockchain hardforks
Precedence: list

--001a1137baaea6bef90556f15afa
Content-Type: text/plain; charset="UTF-8"

---------- 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

--001a1137baaea6bef90556f15afa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_quote">---------- Forwarded messag=
e ----------<br>From: <b class=3D"gmail_sendername">Christian Decker</b> <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:decker.christian@gmail.com">decker.ch=
ristian@gmail.com</a>&gt;</span><br>Date: Thu, Aug 17, 2017 at 5:39 AM<br>S=
ubject: Re: [Lightning-dev] Lightning in the setting of blockchain hardfork=
s<br>To: Martin Schwarz &lt;<a href=3D"mailto:martin.schwarz@gmail.com">mar=
tin.schwarz@gmail.com</a>&gt;, <a href=3D"mailto:lightning-dev@lists.linuxf=
oundation.org">lightning-dev@lists.linuxfoundation.org</a><br><br><br><div =
dir=3D"ltr">Hi Martin,<div><br></div><div>this is the perfect venue to disc=
uss this, welcome to the mailing list :-)</div><div>Like you I think that u=
sing the first forked block as the forkchain&#39;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&=
#39;t declare itself to be the forked chain.</div><div><br></div><div>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 protec=
tion was implemented on the fork, then we can use the last commitment to cl=
ose the channel (updates should be avoided since they now double any intend=
ed effect), if replay protection was implemented then commitments become in=
valid on the fork, and people will lose money.</div><div><br></div><div>Fun=
 times ahead :-)</div><div><br></div><div>Cheers,</div><div>Christian</div>=
</div><br><div class=3D"gmail_quote"><div><div class=3D"h5"><div dir=3D"ltr=
">On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz &lt;<a href=3D"mailto:mar=
tin.schwarz@gmail.com" target=3D"_blank">martin.schwarz@gmail.com</a>&gt; w=
rote:<br></div></div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=
=3D"h5"><div dir=3D"ltr"><div>Dear all,</div><div><br></div><div>currently =
the chain_id allows to distinguish blockchains by the hash of their genesis=
 block.</div><div><br></div><div>With hardforks branching off of the Bitcoi=
n blockchain, how can Lightning work on (or across)</div><div>distinct, per=
manent forks of a parent blockchain that share the same genesis block?</div=
><div><br></div><div>I suppose changing the definition of chain_id to the h=
ash of the first block of the new</div><div>branch and requiring replay and=
 wipe-out protection should be sufficient. But can we=C2=A0</div><div>relax=
 these requirements? Are slow block times an issue? Can we use Lightning to=
 transact</div><div>on &quot;almost frozen&quot; block chains suffering fro=
m a sudden loss of hashpower?</div><div><br></div><div>Has there been any p=
revious discussion or study of Lightning in the setting of hardforks?</div>=
<div>(Is this the right place to discuss this? If not, where would be the r=
ight place?)</div><div><br></div><div>thanks,</div><div>Martin</div></div><=
/div></div>
______________________________<wbr>_________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>o=
rg/mailman/listinfo/<wbr>lightning-dev</a><br>
</blockquote></div>
<br>______________________________<wbr>_________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>o=
rg/mailman/listinfo/<wbr>lightning-dev</a><br>
<br></div><br><br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_s=
ignature" data-smartmail=3D"gmail_signature">- Bryan<br><a href=3D"http://h=
eybryan.org/" target=3D"_blank">http://heybryan.org/</a><br>1 512 203 0507<=
/div>
</div>

--001a1137baaea6bef90556f15afa--