Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9858F941 for ; Tue, 10 Oct 2017 12:05:39 +0000 (UTC) X-Greylist: delayed 12:00:41 by SQLgrey-1.7.6 Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94102467 for ; Tue, 10 Oct 2017 12:05:27 +0000 (UTC) Received: from homiemail-a1.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id 8F9078E74D for ; Mon, 9 Oct 2017 17:04:53 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 7738C34806C for ; Mon, 9 Oct 2017 17:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:mime-version:subject:message-id:date:to; s= taoeffect.com; bh=NjrCYAyRSLMJZuQ/JQ2yedjLOzM=; b=hb38Q+30eJJ+2k esnTgC7lb4yLGp7DpiJwD8AqiYA0yJsNoMEfkWX2IsOXWSH65zxLZqA95nvOEHJQ o73SQMD29HMtc8y0PT1R+1KeJURcVU1h5ddO8zewTB9S5zwBTkkQHyZfe5pQ6cXF fl2ium5XMrLlCVTbzXQVRTc28Qv9M= Received: from [10.8.0.6] (unknown [192.184.93.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 392D634806A for ; Mon, 9 Oct 2017 17:04:52 -0700 (PDT) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_88A3A419-1547-48BB-B187-2AAF91B4B499"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 529286695.047397-176b316569bd11bd8d64ac472dd6e895 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 9 Oct 2017 17:04:55 -0700 To: Paul Sztorc via bitcoin-dev X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 10 Oct 2017 12:28:59 +0000 Subject: [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 12:05:39 -0000 --Apple-Mail=_88A3A419-1547-48BB-B187-2AAF91B4B499 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A873216-5635-4AE9-81DB-FCFA7297FCAE" --Apple-Mail=_2A873216-5635-4AE9-81DB-FCFA7297FCAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear list, In previous arguments over Drivechain (and Drivechain-like proposals) I = promised that better scaling proposals =E2=80=94 that do not sacrifice = 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 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 -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_2A873216-5635-4AE9-81DB-FCFA7297FCAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear list,

In previous arguments over Drivechain (and Drivechain-like = proposals) I promised that better scaling proposals =E2=80=94 that do = not sacrifice 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 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

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

= --Apple-Mail=_2A873216-5635-4AE9-81DB-FCFA7297FCAE-- --Apple-Mail=_88A3A419-1547-48BB-B187-2AAF91B4B499 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgYtgnomHliYDCUth7GcgK+kJUkcFAlncDqcACgkQ7GcgK+kJ Ukf1+A/+Jcfy23cfewwyE8lJUjBdZz4bWeUKC79JOnr/0VbGhDR2nGeW3EkZmiRW aZz2dOhu8gMN5pWpumNLLkRcqpW/5BR2Redh5BZABfNugQEm0n69xA81Zauo5vtL 3z/rp0R2xCKc1uCScTcOudrEeuVwqlA0F+1Y5Vz7R2Qpm2F5zqmLN7WXlmc6zJha /C2yW2LPfq6jQaFqqPN1b9OfM1xGDbk9tKRh+WdmXdGvX3fATsSxdIV1fnDOAleg JNZ7HycDvK5HpfvnCJ7hTrnlkNE53cLwy4YyW+jGix11EucE0CPBCf+QOH5Rh3qm o9/K1PilX7J+ggZgtDNPmAwgEu5tir2g0l4pwloFOns2icmi1tMORExZcJ0BJ4r4 rzQqCwtj7lQR9r0dmg3tIqzUWC1rwiPxPYPAKTi3NLGXyJBahvd0XO2ahr6SNWk4 EMJc/6H8OJyHtT7Dt+5w3uNd2J1ShMwrNZp3EszZq3X8vXyWBP0EU3pmOeqzdu7b F0xq+CoshBcmZ/s/yCEiIX1/aAQ5UKQn06wJmS2EVpounJphJqbre7g50PRUAhfS LjQKvfNYwdco3GHjK5eO85uxE7pWWA+nkJHw4VrgH5F8cj2EJLD/Lse3q2p4a6rP jVIejodU5Ob+1p2+KBhmjoNTlYsxe/ERF3tGBsJmtS9+cYPUcCA= =xtsY -----END PGP SIGNATURE----- --Apple-Mail=_88A3A419-1547-48BB-B187-2AAF91B4B499--