Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 380509C0 for ; Tue, 10 Oct 2017 15:09:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com [209.85.216.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A735F8 for ; Tue, 10 Oct 2017 15:09:25 +0000 (UTC) Received: by mail-qt0-f170.google.com with SMTP id 8so6445488qtv.1 for ; Tue, 10 Oct 2017 08:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=HjsRyrvqsWll3R4IAjyVTyyOV6mDrB4c/1YbuHcR5Ps=; b=tId7phSeR0rWno2qs0kUefVa70B7wmhFm4aenBNJHYe4uOm3lZAnH1mrBY1L1R6ccb AuesZLAzKTnvukvU9cpDmcUtf6nNJb05RO/fWo5zK9WZFdSxkVR4vtErOjabx5nos+Q7 Zk03//yTuWhZ7EOzRiTsYwQmpKhkKo3V0mwd+Lb2wizTlqVGQyVh7RBWXuwCZF975bFm 74B3Ohjb8alYNsPRfMG3xCB1fPkXXeZgACUvx+XppGWRhTy9zYZt6MMkK24qcHfya80p UPFcYFk2qr3Im2ituz1IglH9tfWJ0xavNMnpu5hZwavf2AnglvpB9qvII+A7wVX4Iub5 2G8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=HjsRyrvqsWll3R4IAjyVTyyOV6mDrB4c/1YbuHcR5Ps=; b=C67Br6Ss1bs+Q+BPyugfUCP5OM/ZYYKM35qEA3SAGDD8Yt7suP69Cfb4TYlnpqAd1h 5ZdKvTUD7mHCcGyYajFiCUbzrjneA9UZCxFdzZ7qkDS4xXVWUItB7sEvmF0UnNj/hb+G 1iKJFvv+R+V9AlrnUHXk1ohcTTT7ssxJrhjHYljObR++IVvXzMg4Z4GCJCKeDYhHbUNE 9U+N5AoH+HnLnPSbldAXS5ijmpOuxod9EzTaMC+mX7DFHSilvWRByAs1WnyllSRHRV2O 61S8Niz1CfwAcUrFxDu3DAl8e8RbhlobGYpCgObX9/gXEbKmpKGEs7+EuzCHG753Eo69 Xrhg== X-Gm-Message-State: AMCzsaUhDDPGJbYBJA+1CnvtmRIjBiZCsQuj4GDyjGY1PUVSLMsNglab buljJaWyeQHauJXb74bPd7TJW8rU X-Google-Smtp-Source: AOwi7QDQ2hhrCm78tu2ip72a5xMH5YAXqqijxPZzFPIWQ4P9MTSlmOnhegXhpyMhvcA5eH8mKn+8Kw== X-Received: by 10.55.170.74 with SMTP id t71mr14956277qke.84.1507648164120; Tue, 10 Oct 2017 08:09:24 -0700 (PDT) Received: from [192.168.1.107] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id p39sm6779707qta.18.2017.10.10.08.09.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Oct 2017 08:09:22 -0700 (PDT) Cc: Bitcoin Dev References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com> From: Paul Sztorc Message-ID: Date: Tue, 10 Oct 2017 11:09:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BABB4DC6839699751B6F6AC2" Content-Language: en-US X-Spam-Status: No, score=1.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MISSING_HEADERS, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Level: * 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 15:09:26 -0000 This is a multi-part message in MIME format. --------------BABB4DC6839699751B6F6AC2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I think this response speaks for itself. On 10/10/2017 10:09 AM, Tao Effect wrote: > Hi Paul, > > I thought it was clear, but apparently you are getting stuck on the > semantics of the word "burn". > > The "burning" applies to the original coins you had. > > When you transfer them back, you get newly minted coins, equivalent to > the amount you "burned" on the chain you're transferring from — as > stated in the OP. > > If you don't like the word "burn", pick another one. > > -- > Please do not email me anything that you are not comfortable also > sharing with the NSA. > >> On Oct 10, 2017, at 4:20 AM, Paul Sztorc > > wrote: >> >> 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" >>> >> > wrote: >>> >>> Dear list, >>> >>> In previous arguments over Drivechain (and Drivechain-like >>> proposals) I promised that better scaling proposals — that >>> do not sacrifice Bitcoin's security — 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 with the NSA. >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >> > --------------BABB4DC6839699751B6F6AC2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I think this response speaks for itself.

On 10/10/2017 10:09 AM, Tao Effect wrote:
Hi Paul,

I thought it was clear, but apparently you are getting stuck on the semantics of the word "burn".

The "burning" applies to the original coins you had.

When you transfer them back, you get newly minted coins, equivalent to the amount you "burned" on the chain you're transferring from — as stated in the OP.

If you don't like the word "burn", pick another one.

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

On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin@gmail.com> wrote:

Haha, no. Because you "burned" the coins.

On Oct 10, 2017 1:20 AM, "Tao Effect" <contact@taoeffect.com> 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 <truthcoin@gmail.com> 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" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Dear list,

In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — 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 with the NSA.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev





--------------BABB4DC6839699751B6F6AC2--