From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3BB0B98C for ; Tue, 10 Oct 2017 19:25:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a7.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CA6E45A for ; Tue, 10 Oct 2017 19:25:05 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 40F2B25C06B; Tue, 10 Oct 2017 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; s=taoeffect.com; bh=2zFeX64Yo7aUlhbVdeRaDFVjQTA=; b=kjBn3aBrhprTrvVTRbLiOfQp1O27 XW3CWlpRB87QBw4si0HDemSe21ZyjR3WjXtULFkOFX9YtcyfS3F/i9I6nOhjg26M YUT3zxbfgAGHuwvgOZ4vvaWP/UFB/zgQSGgoso7GuPFbgUAUd64bGF9aLXQtA1zt R4URxmcLeYgCTn8= Received: from [10.14.129.172] (unknown [107.72.97.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: support@taoeffect.com) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id D672F25C06A; Tue, 10 Oct 2017 12:25:04 -0700 (PDT) From: Tao Effect Content-Type: multipart/alternative; boundary=Apple-Mail-6C616161-C528-43E2-8CC7-3C7242C24ED7 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 10 Oct 2017 12:25:03 -0700 Message-Id: References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com> In-Reply-To: To: Paul Sztorc , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (15A421) X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MIME_QP_LONG_LINE,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 19:46:39 +0000 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 19:25:07 -0000 --Apple-Mail-6C616161-C528-43E2-8CC7-3C7242C24ED7 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Is that what passes for a technical argument these days? Sheesh. Whereas in Drivechain users are forced to give up their coins to a single gr= oup for whatever sidechains they interact with, the generic sharding algo le= ts them (1) keep their coins, (2) trust whatever group they want to trust (t= he miners of the various sidechains). Drivechain offers objectively worse security. -- Sent from my mobile device. Please do not email me anything that you are not comfortable also sharing wi= th the NSA. > On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev wrote: >=20 > I think this response speaks for itself. >=20 >> On 10/10/2017 10:09 AM, Tao Effect wrote: >> Hi Paul, >>=20 >> I thought it was clear, but apparently you are getting stuck on the seman= tics of the word "burn". >>=20 >> The "burning" applies to the original coins you had. >>=20 >> When you transfer them back, you get newly minted coins, equivalent to th= e amount you "burned" on the chain you're transferring from =81\ as stated i= n the OP. >>=20 >> If you don't like the word "burn", pick another one. >>=20 >> -- >> Please do not email me anything that you are not comfortable also sharing= with the NSA. >>=20 >>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc wrote: >>>=20 >>> Haha, no. Because you "burned" the coins. >>>=20 >>>> On Oct 10, 2017 1:20 AM, "Tao Effect" wrote: >>>> Paul, >>>>=20 >>>> It's a two-way peg. >>>>=20 >>>> There's nothing preventing transfers back to the main chain. >>>>=20 >>>> They work in the exact same manner. >>>>=20 >>>> Cheers, >>>> Greg >>>>=20 >>>> -- >>>> Please do not email me anything that you are not comfortable also shari= ng with the NSA. >>>>=20 >>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc wrote: >>>>>=20 >>>>> That is only a one-way peg, not a two-way. >>>>>=20 >>>>> In fact, that is exactly what drivechain does, if one chooses paramete= rs for the drivechain that make it impossible for any side-to-main transfer t= o succeed. >>>>>=20 >>>>> One-way pegs have strong first-mover disadvantages. >>>>>=20 >>>>> Paul >>>>>=20 >>>>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" wrote: >>>>> Dear list, >>>>>=20 >>>>> In previous arguments over Drivechain (and Drivechain-like proposals) I= promised that better scaling proposals =81\ that do not sacrifice Bitcoin's= security =81\ would come along. >>>>>=20 >>>>> I planned to do a detailed writeup, but have decided to just send off t= his email with what I have, because I'm unlikely to have time to write up a d= etailed proposal. >>>>>=20 >>>>> The idea is very simple (and by no means novel*), and I'm sure others h= ave mentioned either exactly it, or similar ideas (e.g. burning coins) befor= e. >>>>>=20 >>>>> This is a generic sharding protocol for all blockchains, including Bit= coin. >>>>>=20 >>>>> Users simply say: "My coins on Chain A are going to be sent to Chain B= ". >>>>>=20 >>>>> Then they burn the coins on Chain A, and create a minting transaction o= n Chain B. The details of how to ensure that coins do not get lost needs to b= e worked out, but I'm fairly cer= tain the folks on this list can figure out those details. >>>>>=20 >>>>> - Thin clients, nodes, and miners, can all very easily verify that sai= d action took place, and therefore accept the "newly minted" coins on B as v= alid. >>>>> - Users client software now also knows where to look for the other coi= ns (if for some reason it needs t= o). >>>>>=20 >>>>> This doesn't even need much modification to the Bitcoin protocol as mo= st of the verification is done client-side. >>>>>=20 >>>>> It is fully decentralized, and there's no need to give our ownership o= f our coins to miners to get scale. >>>>>=20 >>>>> My sincere apologies if this has been brought up before (in which case= , I would be very grateful for a link to the proposal). >>>>>=20 >>>>> Cheers, >>>>> Greg Slepak >>>>>=20 >>>>> * This idea is similar in spirit to Interledger. >>>>>=20 >>>>> -- >>>>> Please do not email me anything that you are not comfortable also shar= ing with the NSA. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-6C616161-C528-43E2-8CC7-3C7242C24ED7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is that what passes for a technical argumen= t these days? Sheesh.

Whereas in Drivechain users ar= e forced to give up their coins to a single group for whatever sidechains th= ey interact with, the generic sharding algo lets them (1) keep their coins, (= 2) trust whatever group they want to trust (the miners of the various sidech= ains).

Drivechain offers objectively worse security= .

--
Sent from my mobile device.=
Please d= o not email me anything that you are not comfortable also sharing with the N= SA.

On Oct 10, 2017, at 8:09 AM, Paul Sztorc via b= itcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:

=20 =20 =20
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 =E2=80=94 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 <truthc= oin@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<= /a>> 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 =E2=80=94= that do not sacrifice Bitcoin's security =E2=80=94 wou= ld 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
bit= coin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev





=20
____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-6C616161-C528-43E2-8CC7-3C7242C24ED7--