From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 91470A81 for ; Thu, 17 Aug 2017 11:31:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 789E6E2 for ; Thu, 17 Aug 2017 11:31:32 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id e124so63400297oig.2 for ; Thu, 17 Aug 2017 04:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2QkgrjWLsUcTvXoMyLhcfzPWfiPRu5wh7KdVamwbXjM=; b=nDJIT0g2Q0XWEDE8jLtQCqQs1kc3B+EdPFcfK4vXvlVjMo7fM8W8nJoqLUtrsxjqT+ NGsW111niVDlXa/fCoRfl5hzCu33NpmRn3SKR0OIEC4Qbe3DV0WfnzJ8dMvvzYwFkXBF +ttakkKAqIg0Rl42XMfURtHaYi75rODZTwJOjn2Dt8Q9MIU3UgFHO5O/VUGjdseAFxF7 i7YXvKKd+qKYCqCb9hnl82yGY2Xa3LNStWRDMw+YakIqx5CuiovZ5xT+PToNAddxoZZq zVZvRTkbDOprC4Bo8USBY5jygSgaptCMOywah4c2VvkArkRhRb3ZW12OkBNXydx9xMrg y3Aw== 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=2QkgrjWLsUcTvXoMyLhcfzPWfiPRu5wh7KdVamwbXjM=; b=levPLPp6ATELJd71BEqo3GFTDwtk+UHeje8AMIkKShLg/hRNDIYu43wOs0Nz4g8gUj MCZGuiiUx9YGjKYgaVKYV37izY+6BNGUUYK6g0pqPlUhbpLkdfz0eAf+1pq/IvkDEBrC l+vmh/OFyKba5/r59IfoHbKDHizEiyQALHrJZgwGPDxh3voiRbLEeADMPgZJ6JkYjDxh EuJcZ9ef8y4qDl1z3lewDUgdYP/7xC++8CLvlO7iyK7xfPkwtyl28B/6v1MUD2UGKE5u cVetzDIdNCvHxB3wEcVRMy4w7mQ+xrvzPnFV597KKQ62ZqMw6yq/mFqWVNp7WymT3T6G SADw== X-Gm-Message-State: AHYfb5g9xKrvdb9wLL635zllrrbiTjjSFP/Vl8iXxAhkyZ13upHzQ+hr 34+mJS3lGbj7q9uavAmd5yfrdsY32qkL X-Received: by 10.202.44.19 with SMTP id s19mr5825331ois.243.1502969491533; Thu, 17 Aug 2017 04:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.152 with HTTP; Thu, 17 Aug 2017 04:31:30 -0700 (PDT) In-Reply-To: References: From: Bryan Bishop Date: Thu, 17 Aug 2017 06:31:30 -0500 Message-ID: To: Bitcoin Dev , Bryan Bishop , Martin Schwarz , Christian Decker Content-Type: multipart/alternative; boundary="001a1137baaea6bef90556f15afa" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 11:31:32 -0000 --001a1137baaea6bef90556f15afa Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message ---------- From: Christian Decker Date: Thu, Aug 17, 2017 at 5:39 AM Subject: Re: [Lightning-dev] Lightning in the setting of blockchain hardforks To: Martin Schwarz , 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 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

---------- Forwarded messag= e ----------
From: Christian Decker <decker.ch= ristian@gmail.com>
Date: Thu, Aug 17, 2017 at 5:39 AM
S= ubject: Re: [Lightning-dev] Lightning in the setting of blockchain hardfork= s
To: Martin Schwarz <mar= tin.schwarz@gmail.com>, lightning-dev@lists.linuxfoundation.org


Hi Martin,

this is the perfect venue to disc= uss this, welcome to the mailing list :-)
Like you I think that u= sing 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&= #39;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 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.

Fun= times ahead :-)

Cheers,
Christian
=

On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz@gmail.com> w= rote:
Dear all,

currently = the chain_id allows to distinguish blockchains by the hash of their genesis= block.

With hardforks branching off of the Bitcoi= n blockchain, how can Lightning work on (or across)
distinct, per= manent forks of a parent blockchain that share the same genesis block?

I suppose changing the definition of chain_id to the h= ash of the first block of the new
branch and requiring replay and= wipe-out protection should be sufficient. But can we=C2=A0
relax= these requirements? Are slow block times an issue? Can we use Lightning to= transact
on "almost frozen" block chains suffering fro= m a sudden loss of hashpower?

Has there been any p= revious discussion or study of Lightning in the setting of hardforks?
=
(Is this the right place to discuss this? If not, where would be the r= ight place?)

thanks,
Martin
<= /div>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.o= rg/mailman/listinfo/lightning-dev

_______________________________________________
Lightning-dev mailing list
Lightning-dev@li= sts.linuxfoundation.org
https://lists.linuxfoundation.o= rg/mailman/listinfo/lightning-dev




--
- Bryan
http://heybryan.org/
1 512 203 0507<= /div>
--001a1137baaea6bef90556f15afa--