Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 16FFFAAC for ; Tue, 10 Oct 2017 01:39:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AEFF14D9 for ; Tue, 10 Oct 2017 01:39:35 +0000 (UTC) Received: by mail-lf0-f46.google.com with SMTP id k40so9751628lfi.4 for ; Mon, 09 Oct 2017 18:39:35 -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=0YYM3smPw36lSu6NIECtE2XpGjhc2NJXtwwkwAWPiSU=; b=TMqT7MMlI+OgF5f1XYqDeLBQQCT1mzAUnPSZocYux4RGDBC+QiE7PHS6Gih8x3IN7Y o5wEzwIXUOUAGLH8JIdAzFM7HLSkaTbwxKXx/pKvtOYxSLd4OwI99riRcxFQuusjiKl9 jqivlAAHUxkUeeTJCeHvrOHFobM3hXkoOLdM1icDhH37EGidFHfmWVVzphF72AHDr5Hb b5xl3ZxzXkEzXp72SbAoSPv9/quQsXtdmfdfuMzVtQ+ZpUOKKBA7SW5Qw3zPTNb2xn1m 8ONNovv+skxW6GaIjK/dwVYD4nX0i3wqkFw3lBI/WqZjgISQDRlRIW5Fo9OZcx0aowsw 1nLA== 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=0YYM3smPw36lSu6NIECtE2XpGjhc2NJXtwwkwAWPiSU=; b=LVCUN7hNxLeJY40cw9b5h0dAZvHPdkisuM/OWGIBmnkc5Cp1EA7N8M6GdoZNhjNK7a b7hUNg0dOl/ZV6hsoguDlNClKU8k2xiThNrRIUKJoDVmfkN/AOS+OEEFekd4dsKYSIaV fIBc9Xwo+AY4U7RHv3MZRglOYzRqxAE4MBYi/OsxBp6jzdlhEjA4etoTqYHgkjvgJnw2 4sHLO/0QIx/ZmlYH6amrlt3F57t4F25asB2VL6mvvGwI67dywNlKl9gpYBNkBmMnv5kL lqJZ0IKuoQgjUNY+fXkP1pygRWEJujtnxOklj/aZispLGHnfDPfN6SLtc2Uucs7XJ6IZ KVpw== X-Gm-Message-State: AMCzsaUfNxd1f0haqbua1idpzSw4lyIbHLgKanE4IgAA1YbLYne5YkHR Rv+Ytr60EyFfzmHRrMOiWVYwqqFIR2aqxbWHqUorRg== X-Google-Smtp-Source: AOwi7QDAeRfELdSolslFjyUJsdr+EMns0EVdF0SFmz9F7HK/cgp4f1mefp6HDCDjSlTZ3JukZRWj/qVdUTV8HyuTkTk= X-Received: by 10.46.91.25 with SMTP id p25mr5108891ljb.46.1507599573825; Mon, 09 Oct 2017 18:39:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.15.160 with HTTP; Mon, 9 Oct 2017 18:39:33 -0700 (PDT) Received: by 10.25.15.160 with HTTP; Mon, 9 Oct 2017 18:39:33 -0700 (PDT) In-Reply-To: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> From: Paul Sztorc Date: Mon, 9 Oct 2017 21:39:33 -0400 Message-ID: To: Bitcoin Dev , Tao Effect Content-Type: multipart/alternative; boundary="001a114c17c60fbb26055b27612f" 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 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 01:39:37 -0000 --001a114c17c60fbb26055b27612f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" < bitcoin-dev@lists.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 Bitc= oin's security =E2=80=94 would come along. I planned to do a detailed writeup, but have decided to just send off this 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 have mentioned either exactly it, or 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 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 out 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 w= ith the NSA. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --001a114c17c60fbb26055b27612f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is only a one-way peg, not a two-way.

In fact, that is exactly what dri= vechain does, if one chooses parameters for the drivechain that make it imp= ossible for any side-to-main transfer to succeed.
One-way pegs have strong first-mover disadvantage= s.

Paul

On Oct 9, 2017 9:= 24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:
Dear list,

=
In previous arguments over Drivechain (and Drivechain-like propo= sals) I promised that better scaling proposals =E2=80=94 that do not sacrif= ice Bitcoin's security =E2=80=94 would come along.

=
I planned to do a detailed writeup, but have decided to just send off = this 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 have mentioned either exac= tly it, or similar ideas (e.g. burning coins) before.

<= div>This is a generic sharding protocol for all blockchains, including Bitc= oin.

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

Then they bu= rn the coins on Chain A, and create a minting transaction on Chain B. The d= etails 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 deta= ils.

- Thin clients, nodes, and miners, can all ve= ry easily verify that said action took place, and therefore accept the &quo= t;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 ne= eds to).

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

It is fully decentralized, and there's no ne= ed to give our ownership of our coins to miners to get scale.
My sincere apologies if this has been brought up before (in whi= ch 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=C2=A0with the NSA.


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


--001a114c17c60fbb26055b27612f--