Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E6B2F88A for ; Tue, 10 Oct 2017 11:20:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA44BCD for ; Tue, 10 Oct 2017 11:20:39 +0000 (UTC) Received: by mail-lf0-f42.google.com with SMTP id b190so5294144lfg.9 for ; Tue, 10 Oct 2017 04:20:39 -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 :cc; bh=+T5G/IcNSEFAvPBVtsYbw8bCwdf+ra23MklxgRI4sng=; b=Ir3vbMTbe43vwdWMPBqxKiY815VKJsLPh2po9dMKEmAccRSJkf4iDHZPRyy+bc6/HM Jd1ZqIL/2FMz2vnRCBGy0Ik8n+VTTagaV3Wyts9go5ONz3vim7IRIdL59nbMx+xFo2FK YIBwstretkRXak323DLAHoDTOOUGBHKuLAUCfksZS7GvBpEnC6eU8PlARubkt24TZB92 XZskrM5Cev3ik9imlMTF5L5oJ4Z++Bcgy9w9qO1Nmg9BEQ/5sRu+qE/kKqoHr6kesFAk db80fuKMiqwKAkmXzt4Wk4jtnE+jcXiVMyZmKcdStKQpqsvE1hmiNi2V3QdggLM0srSF GmHQ== 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:cc; bh=+T5G/IcNSEFAvPBVtsYbw8bCwdf+ra23MklxgRI4sng=; b=BxeDz7mB4bK8Co9XsgL6bfUjJz8DIyTTDuzRSpjDDJxCmfOc4dPmBivo/m1iXwuo2H iARNSuU0IHYGXI/Tlc84tDDoQkCjdJVmMPdM0RrXVZ5I0jyWfjnq+jhPaTI4md7awk5S 8R9YxKKf3LhjB2B5oyPnPMnGdWwUvLPLhuVt49nQaY/BJNDxYWXsh1JLJRzQ3Bc0GAb2 javfOwxv/ZQFpxYPab+oN6QRLCT13UaTomyd0CX+cU58b6Wh1SwVFUouGFm5I9H7I43g K78kYU+fs8MsDDJ7df0RMacSr7LogoVTGxGDQF7WrpdFSw5jmEKG4CAFXFw1hdLPZtau uksQ== X-Gm-Message-State: AMCzsaVB3KUkDze0oVO3XK1822+t1dYv8Q5gZyjFG6ljprzCTBzSj1al HD8aLl3R50gqWdpqsImUe5vhZ9I0OKtskGbaLrU= X-Google-Smtp-Source: AOwi7QBAUIRuc14x8BssSRn5BqmUaMCsAbL+xoTH9YMkv5LjuXtEcoTNL+vPWm4sNW4rwzDncf7JDVFpNgEFxu0yHZM= X-Received: by 10.46.3.18 with SMTP id 18mr6556621ljd.17.1507634437937; Tue, 10 Oct 2017 04:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.15.160 with HTTP; Tue, 10 Oct 2017 04:20:36 -0700 (PDT) Received: by 10.25.15.160 with HTTP; Tue, 10 Oct 2017 04:20:36 -0700 (PDT) In-Reply-To: <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com> References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com> From: Paul Sztorc Date: Tue, 10 Oct 2017 07:20:36 -0400 Message-ID: To: Tao Effect Content-Type: multipart/alternative; boundary="089e082741781fdf25055b2f7f3a" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC 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: Tue, 10 Oct 2017 11:20:41 -0000 --089e082741781fdf25055b2f7f3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Haha, no. Because you "burned" the coins. On Oct 10, 2017 1:20 AM, "Tao Effect" wrote: > Paul, > > It's a two-way peg. > > There's nothing preventing transfers back to the main chain. > > They work in the exact same manner. > > Cheers, > Greg > > -- > Please do not email me anything that you are not comfortable also sharing= with > the NSA. > > On Oct 9, 2017, at 6:39 PM, Paul Sztorc wrote: > > That is only a one-way peg, not a two-way. > > In fact, that is exactly what drivechain does, if one chooses parameters > for the drivechain that make it impossible for any side-to-main transfer = to > succeed. > > One-way pegs have strong first-mover disadvantages. > > Paul > > On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" linuxfoundation.org> wrote: > > Dear list, > > In previous arguments over Drivechain (and Drivechain-like proposals) I > promised that better scaling proposals =E2=80=94 that do not sacrifice Bi= tcoin's > security =E2=80=94 would come along. > > I planned to do a detailed writeup, but have decided to just send off thi= s > email with what I have, because I'm unlikely to have time to write up a > detailed proposal. > > The idea is very simple (and by no means novel*), and I'm sure others hav= e > mentioned either exactly it, or similar ideas (e.g. burning coins) before= . > > This is a generic sharding protocol for all blockchains, including Bitcoi= n. > > Users simply say: "My coins on Chain A are going to be sent to Chain B". > > Then they burn the coins on Chain A, and create a minting transaction on > Chain B. The details of how to ensure that coins do not get lost needs to > be worked out, but I'm fairly certain the folks on this list can figure o= ut > those details. > > - Thin clients, nodes, and miners, can all very easily verify that said > action took place, and therefore accept the "newly minted" coins on B as > valid. > - Users client software now also knows where to look for the other coins > (if for some reason it needs to). > > This doesn't even need much modification to the Bitcoin protocol as most > of the verification is done client-side. > > It is fully decentralized, and there's no need to give our ownership of > our coins to miners to get scale. > > My sincere apologies if this has been brought up before (in which case, I > would be very grateful for a link to the proposal). > > Cheers, > Greg Slepak > > * This idea is similar in spirit to Interledger. > > -- > Please do not email me anything that you are not comfortable also sharing= with > the NSA. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > --089e082741781fdf25055b2f7f3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Haha, no. Because you "burned" the coins.
=

On Oct 10, 2017 1= :20 AM, "Tao Effect" <contact@taoeffect.com> wrote:
Paul,

<= div>It's a two-way peg.

There's nothing pr= eventing transfers back to the main chain.

They wo= rk in the exact same manner.

Cheers,
Gre= g

--
Please do not email me anything that you are not comfortable = also sharing=C2=A0with the NSA.

On Oct 9, 2017, at 6:39 PM, Paul Sz= torc <truthcoin= @gmail.com> wrote:

That is only a one-way peg, no= t a two-way.

In fact, th= at is exactly what drivechain does, if one chooses parameters for the drive= chain that make it impossible for any side-to-main transfer to succeed.

One-way pegs have strong fi= rst-mover disadvantages.

Paul

On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bit= coin-dev@lists.linuxfoundation.org> wrote:
Dear list,

In previous arguments over Drivechain (and Drivechain-like proposals) I p= romised that better scaling proposals =E2=80=94 that do not sacrifice Bitco= in's security =E2=80=94 would come along.

I pl= anned to do a detailed writeup, but have decided to just send off this emai= l with what I have, because I'm unlikely to have time to write up a det= ailed proposal.

The idea is very simple (and by no= means novel*), and I'm sure others have mentioned either exactly it, o= r similar ideas (e.g. burning coins) before.

This = is a generic sharding protocol for all blockchains, including Bitcoin.

Users simply say: "My coins on Chain A are going = to be sent to Chain B".

Then they burn the co= ins on Chain A, and create a minting transaction on Chain B. The details of= how to ensure that coins do not get lost needs to be worked out, but I'= ;m fairly certain the folks on this list can figure out those details.

- Thin clients, nodes, and miners, can all very easily= verify that said action took place, and therefore accept the "newly m= inted" coins on B as valid.
- Users client software now also= knows where to look for the other coins (if for some reason it needs to).<= /div>

This doesn't even need much modification to th= e Bitcoin protocol as most of the verification is done client-side.

It is fully decentralized, and there's no need to giv= e our ownership of our coins to miners to get scale.

My sincere apologies if this has been brought up before (in which case, = I would be very grateful for a link to the proposal).

<= div>Cheers,
Greg Slepak

* This idea is s= imilar in spirit to Interledger.

--
Please do not email me anythin= g that you are not comfortable also sharing=C2=A0with the NSA.


______________________________________= _________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--089e082741781fdf25055b2f7f3a--