Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B1FE3EC3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 Apr 2019 10:45:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
	[185.70.40.136])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA3C0623
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 Apr 2019 10:45:36 +0000 (UTC)
Date: Mon, 08 Apr 2019 10:45:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1554720333;
	bh=XSp2u9bnz89+TKT8xp9DTLu0o6NLZ2W7Eg18SwqN3Iw=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=mKu5uuc1FFUXY8U7Glu4sQUbJTpOkqZivQqL3IJVHrWwS+fMES7rxDKwshq7RKM5B
	i76SUikuboHQsADsFHkxBPLzta9mE8JfaPOxENTo2Vqej7oCOeOMIMeaWdSyGvG15I
	ibkkE/+yd01fgj7jeBcMeF3gXGgScQSmurZA0mKs=
To: Aymeric Vitte <vitteaymeric@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <GkSgHQYXGen75-KP_N2VbK1EmY5DSDe0sncJBU77l6_2xdYhh9Yw5rQSgtPuwXJnMlnA0j195hkMfhnxhGkMERa3kXXW6KvR5qt88oSNGvY=@protonmail.com>
In-Reply-To: <392367fe-b1d7-7d47-01de-ebb4b7142ead@gmail.com>
References: <IAFPSZAn6TYt348fmmnPznQ_ApG7pa48eMjzTgrjuVAt6fS1tNieRxlcIXyTATy2vjZCUn4wVQcsyDlyb_3Ip46BstFRikB95-lKewAZBEE=@protonmail.com>
	<d1cfa2e9-69e4-ee02-4c10-23b2b1a30e00@gmail.com>
	<TF9WSGU6njZqgOyJF5-m1gYMwfgUCStjUV-IpRuX67w1Z6jL2Tdarr6PCOUO1vFb9hz_jWnbe_5Tg8E_a9iyPeXIY_iJUf9YN8u9xB4SC90=@protonmail.com>
	<392367fe-b1d7-7d47-01de-ebb4b7142ead@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW, URI_NOVOWEL autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 08 Apr 2019 11:13:04 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Smart Contracts Unchained
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: Mon, 08 Apr 2019 10:45:37 -0000

Good morning Aymeric,

> Hi,
>
> Apparently you are not a fan of ethereum, as far as I can tell ethereum
> sidechains look like a mess with stupid tokens/transactions flooding the
> network while they are completely centralized, but some bitcoin
> sidechains can easily compete with this too, like Tether, don't even
> understand how anyone can give some credit to that stuff the way it is
> implemented, and if bitcoin fails that would be the same as for ethereum

I prefer to be more precise in my terminology.
Colored coins are not the same as sidechains, and there are colored coins a=
nd then there are colored coins.
This mechanism does not propose some change in colored coins.
An important aspect of colored coins is that one can foist them on somebody=
 else to extract things of real value from them, but this mechanism is more=
 strongly for a fixed set of participants.

I strongly suspect that Bitcoin will outlast Ethereum, but that is rather n=
ot very related to this topic.

> Most likely everyone would agree if the escrow disappears, but not sure
> at all, let's imagine 1 to N put 10K on the table for a game, they
> update the states and at the end N wins everything, N is rich and don't
> care finally if the others cheaters have their coins locked (and to lose
> 10K), same with setting up a new escrow to resolve the conflict
>

Indeed.
Still, the option to do so exists, and sometimes all that is needed for hum=
ans to do the right thing, is to be given the option to do so.

> I think that you should highlight this (and what private key corresponds
> to E + h(E | s) * G, not sure it's trivial for everybody), probably a
> way to get this more decentralized is to reward the escrows (what is the
> interest here for people to run a smart contract platform?)

I assumed both were obvious, but I suppose a few more words about those wou=
ld not be amiss.

>
> For lightning, maybe it's a question of wording, I consider it as a
> sidechain AND methods that can be used by other sidechains, as well as
> the others you quoted, even if only two people in the world use
> lightning, it is still decentralized, because it sustains itself alone

Again, I prefer precision in my terminology.
For me, a sidechain is a blockchain of some sort.
In particular, a kind of Merklized singly-linked list containing representa=
tions of transformations of state, is how I define blockchain to be.

No such Merklized singly-linked list exists in Lightning Network, thus I do=
 not consider it, "blockchain".
And thus I do not consider it "sidechain", as a sidechain is a blockchain.
Current LN does use "shachains" by Rusty, but shachains are not Merklized s=
ingly-linked lists, but are instead a kind of inverse mountain range struct=
ure.

Still, one might consider both federated sidechains and Lightning Network t=
o have a "federated" offchain structure.
This is because the coins on the Bitcoin blockchain are locked to a multisi=
gnature and activity is not recorded on the Bitcoin blockchain.
However, in LN, each channel is a 2-member federation (you and a counterpar=
ty) and the mechanism in LN requires consensus (2-of-2) rather than a quoru=
m (m-of-n).
This greatly increases the security of LN: the owner of funding on an LN ch=
annel can always refuse to sign an update if the other member of the federa=
tion is taken over.
Compare this to the quorum that typical federations have, where takeover of=
 a sufficient quorum is enough to steal funds from the remaining federation=
.
https://zmnscpxj.github.io/offchain/safety.html

Regards,
ZmnSCPxj