path: root/bc/6481b0323ced13c4a64258c56ae90965d9b4cf

Return-Path: <conrad.burchert@googlemail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A4439504
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Aug 2017 12:48:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com
	[209.85.128.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F2EB142
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Aug 2017 12:48:17 +0000 (UTC)
Received: by mail-wr0-f170.google.com with SMTP id b65so42757861wrd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Aug 2017 05:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=JdOV04xid+RIwc7R97EDaWeQaRHHDI4KZTRzdulWi5Y=;
	b=IsFBQktKy1p/bu60oSfdd4rcMNNdOGUvHZpijBy87IuWtiTb1JhrXIPmpqlNiLfQ2F
	7sWcQHizU3ZBSQFBxtF84yKvKG7BkKZz9lMjnrl7hh5+7+mXvncLwSaRX0oAJd9FhH5A
	v68kH6qFr5zyZr76/M8i8St/sk2IXMIKcDv5SnSDoyMMqbz444v1Hvn0W9D3/nY7PfmL
	r3Wf7blvuYAaCz9eY+lW6Atz89czHQRUtIqfe9sYZiZBwtvYl/rix4FJZeMVwrICdZH8
	SXGiysrRa9e8xNhWad00v1Ra6BOPgRqQXy/GJf33jplo2qOpU33L2wepLohyMFFn1X4G
	1lcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=JdOV04xid+RIwc7R97EDaWeQaRHHDI4KZTRzdulWi5Y=;
	b=gUyVrM/iDKI5B/G0bZcg7ZhsfxcMuvg9dszCt8o6MGK9SZjnQYWCa9+6vg4bu1COeb
	B2yilZuHsYop295UZgzG4+TXMmXoN1ghGZlvAkzwuajlqhwZ4YFdtM6BCsCkZl5bvV5g
	7XS5yEkbXKBrcuaikyWGWZkpmSyXHJPKvKYwqN9iX2AEsf5Ft4Re8CbMesqB90fQZuSb
	MeHYfNF9DgAIVeaojPPpbtmkqH52WfMSbdd4BRHDKnL9Cbv1L4lewQnFml9RkmuhsOj4
	OBEc8zQ479A75Q0dp9/L0dCGpodWg6sisosAXdagOr0DXwAZH7YJjZQHRe9eOeKORwCW
	4dgQ==
X-Gm-Message-State: AHYfb5jxNN7NnH4LUtykozIwhTD3ZGG7buGR+1a+LrjWHl4hOzc3em2P
	xLHNxvOj0n8KJVecodceJRByWoCC2g==
X-Received: by 10.80.164.215 with SMTP id x23mr1748954edb.114.1502974095831;
	Thu, 17 Aug 2017 05:48:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.226 with HTTP; Thu, 17 Aug 2017 05:48:15 -0700 (PDT)
In-Reply-To: <CABaSBaxNc2rSPBhqicBakpCkVtg8YOhLs7ecC2XwKfV4fM34iw@mail.gmail.com>
References: <CAKhySQxKvR+1g8Y-OeDjAZj2jDgHub2iJceu_y44t0b+prKYXQ@mail.gmail.com>
	<CALxbBHU-_sC7Qr=U5TMtB_Gs6fe1QnskAaYrLhp1_7Zqc-m8cg@mail.gmail.com>
	<CABaSBaxNc2rSPBhqicBakpCkVtg8YOhLs7ecC2XwKfV4fM34iw@mail.gmail.com>
From: Conrad Burchert <conrad.burchert@googlemail.com>
Date: Thu, 17 Aug 2017 14:48:15 +0200
Message-ID: <CADc9zGCr127JPn_hHO+==PZUEVUFvF2a66M+BY9i78xciqX8+w@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0c3d4c16b60d0556f26dfb"
X-Mailman-Approved-At: Thu, 17 Aug 2017 12:51:47 +0000
Subject: Re: [bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of
 blockchain hardforks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Aug 2017 12:48:17 -0000

--94eb2c0c3d4c16b60d0556f26dfb
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div>Some notes:<br></div><div><br></div><div>Hardforks li=
ke Bitcoin ABC without a malleability fix are very unlikely to have payment=
 channels, so the problem does not exist for those.</div><div><br></div><di=
v>The designers of a hardfork which does have a malleability fix will proba=
bly know about payment channels, so they can just build a replay protection=
 that allows the execution of old commitments. That needs some kind of time=
stamping of commitments, which would have to be integrated in the channel d=
esign. The easiest way would be to just write the time of signing the commi=
tment in the transaction and the replay protection accepts old commitments,=
 but rejects one&#39;s which were signed after the hardfork. These timestam=
ps can essentially be one bit (before or after a hardfork) and if the repla=
y protection in the hardfork only accepts old commitments for something lik=
e 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.</div><d=
iv><br></div><div>Nevertheless hardforking while having channels open will =
always be a mess as an open channel requires you to watch the blockchain. A=
nybody who is just not aware of the hardfork or is updating his client a fe=
w days too late, can get his money stolen by an old commitment transaction =
where he forgets to retaliate on the new chain. As other&#39;s can likely f=
igure out your client version the risk of retaliation is not too big for an=
 attacker.</div><div><br></div><div><br></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">2017-08-17 13:31 GMT+02:00 Bryan Bishop =
via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><d=
iv class=3D"h5"><br><div class=3D"gmail_quote">---------- Forwarded message=
 ----------<br>From: <b class=3D"gmail_sendername">Christian Decker</b> <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:decker.christian@gmail.com" target=3D"=
_blank">decker.christian@gmail.com</a>&gt;</span><br>Date: Thu, Aug 17, 201=
7 at 5:39 AM<br>Subject: Re: [Lightning-dev] Lightning in the setting of bl=
ockchain hardforks<br>To: Martin Schwarz &lt;<a href=3D"mailto:martin.schwa=
rz@gmail.com" target=3D"_blank">martin.schwarz@gmail.com</a>&gt;, <a href=
=3D"mailto:lightning-dev@lists.linuxfoundation.org" target=3D"_blank">light=
ning-dev@lists.<wbr>linuxfoundation.org</a><br><br><br><div dir=3D"ltr">Hi =
Martin,<div><br></div><div>this is the perfect venue to discuss this, welco=
me to the mailing list :-)</div><div>Like you I think that using 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 disruptio=
n. It may become more difficult in the case one chain doesn&#39;t declare i=
tself to be the forked chain.</div><div><br></div><div>Even more interestin=
g are channels that are open during the fork. In these cases we open a sing=
le channel, and will have to settle two. If no replay protection was implem=
ented 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 fo=
rk, 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"m_8531517743362604424h5"><div dir=
=3D"ltr">On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz &lt;<a href=3D"mai=
lto:martin.schwarz@gmail.com" target=3D"_blank">martin.schwarz@gmail.com</a=
>&gt; wrote:<br></div></div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v class=3D"m_8531517743362604424h5"><div dir=3D"ltr"><div>Dear all,</div><d=
iv><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 Bitcoin blockchain, how can Lightning work on (or acr=
oss)</div><div>distinct, permanent forks of a parent blockchain that share =
the same genesis block?</div><div><br></div><div>I suppose changing the def=
inition of chain_id to the hash of the first block of the new</div><div>bra=
nch 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 is=
sue? Can we use Lightning to transact</div><div>on &quot;almost frozen&quot=
; block chains suffering from a sudden loss of hashpower?</div><div><br></d=
iv><div>Has there been any previous 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 right 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.linuxfound<wbr>ation.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/lightning<wbr>-dev</a><br>
</blockquote></div>
<br>______________________________<wbr>_________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfound<wbr>ation.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/lightning<wbr>-dev</a><br>
<br></div><br><br clear=3D"all"><div><br></div></div></div>-- <br><div clas=
s=3D"m_8531517743362604424gmail_signature" data-smartmail=3D"gmail_signatur=
e">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"_blank">http://hey=
bryan.org/</a><br><a href=3D"tel:(512)%20203-0507" value=3D"+15122030507" t=
arget=3D"_blank">1 512 203 0507</a></div>
</div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c0c3d4c16b60d0556f26dfb--