Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 717C0A88 for ; Tue, 10 Oct 2017 20:13:24 +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 7ABEE367 for ; Tue, 10 Oct 2017 20:13:23 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 0673B25C06B; Tue, 10 Oct 2017 13:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= taoeffect.com; bh=I1qju0TSDeu2a48eSnIEFYag3j8=; b=D4YiHD+rwB9RBw QnQHCcWTxL89qqgI5lQlusdtCeF0axPmGtyoVFgQuQV+tp0RYQT0tTTeJrx2YnzF lKMKU/iYa2Td2XOupzYe5ojSFrD5QCS6VbODOTFoE/IElIFeOUS7R++jUP37vsEH zqDXHmj1ODUiUngE4jlnK+lLD2Oiw= 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 8DFCA25C06A; Tue, 10 Oct 2017 13:13:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B8DF4BE6-D1E5-4666-8706-89DCBE43D885 Mime-Version: 1.0 (1.0) From: Tao Effect X-Mailer: iPhone Mail (15A421) In-Reply-To: Date: Tue, 10 Oct 2017 13:13:20 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com> To: CryptAxe 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 20:16:48 +0000 Cc: Bitcoin Protocol Discussion 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 20:13:24 -0000 --Apple-Mail-B8DF4BE6-D1E5-4666-8706-89DCBE43D885 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable It would not change the number of Bitcoins in existence. -- 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 12:50 PM, CryptAxe wrote: >=20 > Your method would change the number of Bitcoins in existence. Why?=20 >=20 >> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" wrote: >> Is that what passes for a technical argument these days? Sheesh. >>=20 >> Whereas in Drivechain users are forced to give up their coins to a single= group for whatever sidechains they 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 sidechains). >>=20 >> Drivechain offers objectively worse security. >>=20 >> -- >> Sent from my mobile device. >> Please do not email me anything that you are not comfortable also sharing= with the NSA. >>=20 >>> 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 sem= antics 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 t= he 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 shari= ng 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 sha= ring 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 parame= ters for the drivechain that make it impossible for any side-to-main transfe= r to 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 alo= ng. >>>>>>>=20 >>>>>>> I planned to do a detailed writeup, but have decided to just send of= f this email with what I have, because I'm unlikely to have time to write up= a detailed proposal. >>>>>>>=20 >>>>>>> The idea is very simple (and by no means novel*), and I'm sure other= s have mentioned either exactly it, or similar ideas (e.g. burning coins) be= fore. >>>>>>>=20 >>>>>>> This is a generic sharding protocol for all blockchains, including B= itcoin. >>>>>>>=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 transactio= n on Chain B. The details of how to ensure that coins do not get lost needs t= o be worked out, but I'm fairly certain the folks on this list can figure ou= t those details. >>>>>>>=20 >>>>>>> - Thin clients, nodes, and miners, can all very easily verify that s= aid 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 c= oins (if for some reason it needs to). >>>>>>>=20 >>>>>>> This doesn't even need much modification to the Bitcoin protocol as m= ost of the verification is done client-side. >>>>>>>=20 >>>>>>> It is fully decentralized, and there's no need to give our ownership= of our coins to miners to get scale. >>>>>>>=20 >>>>>>> My sincere apologies if this has been brought up before (in which ca= se, 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 sh= aring 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 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 --Apple-Mail-B8DF4BE6-D1E5-4666-8706-89DCBE43D885 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable It would not change the number of Bitcoins i= n existence.

--
Sent from my mobil= e device.
cryptaxe@gmail.com> wrot= e:

Your method= would change the number of Bitcoins in existence. Why? 

On Oct 10, 2017 12:47 PM, "= Tao Effect via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Is that what p= asses for a technical argument these days? Sheesh.

W= hereas in Drivechain users are forced to give up their coins to a single gro= up for whatever sidechains they interact with, the generic sharding algo let= s them (1) keep their coins, (2) trust whatever group they want to trust (th= e miners of the various sidechains).

Drivechain off= ers objectively worse security.

--
Sent from my mobile device.
Please do not email me anything that y= ou are not comfortable also sharing with the NSA.
On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:

=20 =20 =20 =20
I think this respons= e speaks for itself.

On 10/10/2017 10:09 AM, Tao Effect wrote:
=20 =20
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 <truthcoin@gmail.com> wrote:<= /div>
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.linuxf= oundation.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
bitcoin-dev@lists.linuxfoundation.= org
ht= tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




=20
____________________= ___________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
= https://lists.linuxfoundation.org/mailman/listinfo/bit= coin-dev

_____________= __________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev

= --Apple-Mail-B8DF4BE6-D1E5-4666-8706-89DCBE43D885--