Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B6667AE7 for ; Tue, 10 Oct 2017 14:09:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a62.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01F6D3F2 for ; Tue, 10 Oct 2017 14:09:45 +0000 (UTC) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 52B4463407C; Tue, 10 Oct 2017 07:09:45 -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 :message-id:references:to; s=taoeffect.com; bh=BcAeH9mNZJfm8m3SS L9F7840DX4=; b=j7rZYf/FTJBLNRA5E84OHNS9aBY+OOudmQaEGgh7n1TEvYxRJ McLEBGztICj4jYzhQhs59cMj6/2dPatINjbEwefFzFDz8+TRjZtPj5zFayd0TSA7 QNbo4EX+ykMOcHe+5LTlGNrcKVVkPqwMQmKBMhR32PTgHHRiB5VlVtqnYY= Received: from [192.168.254.46] (unknown [47.156.153.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 35733634075; Tue, 10 Oct 2017 07:09:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1D04A23F-CDBC-4584-8CEF-0684ED415465"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: Date: Tue, 10 Oct 2017 07:09:44 -0700 X-Mao-Original-Outgoing-Id: 529337384.423405-3cb9727604ecfcd91a5927a8aa861d8d Message-Id: References: <16D7672F-AA36-47D7-AAEF-E767B9CE09FF@taoeffect.com> <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com> To: Paul Sztorc 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 14:31:48 +0000 Cc: Bitcoin Dev 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 14:09:46 -0000 --Apple-Mail=_1D04A23F-CDBC-4584-8CEF-0684ED415465 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC9BDBB2-46D8-4DA2-BB88-BEB37219CC31" --Apple-Mail=_EC9BDBB2-46D8-4DA2-BB88-BEB37219CC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 > 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 = sharing 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 = parameters for the drivechain that make it impossible for any = side-to-main transfer 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 =E2=80=94 that do not sacrifice = Bitcoin's security =E2=80=94 would come along. >>=20 >> 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. >>=20 >> 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. >>=20 >> This is a generic sharding protocol for all blockchains, including = Bitcoin. >>=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 = 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. >>=20 >> - 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). >>=20 >> This doesn't even need much modification to the Bitcoin protocol as = most 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 = 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 = sharing 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 --Apple-Mail=_EC9BDBB2-46D8-4DA2-BB88-BEB37219CC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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:

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 = =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 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




= --Apple-Mail=_EC9BDBB2-46D8-4DA2-BB88-BEB37219CC31-- --Apple-Mail=_1D04A23F-CDBC-4584-8CEF-0684ED415465 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+kJUkcFAlnc1KgACgkQ7GcgK+kJ UkckvA/+Pq3ZOrz6H39AxGQCAoJsGjVC5zvD1ZJgfMd1wrNgdSmFk63oZepRwByc nhA/+vuWS0AAK4BWrbTe15XbOPBCDN5BzBPixkm1GKUsYk+BALIt5H8qWcil+n1y RJYq/jThLwW88eXQUDaolnKEyDXs/An/9s6c1oAtoajaTkEtyY6YVBtnNUJPg0oQ C258Q+VvGxGJDpTs1yPNCsODYxL5uwsRqddl7BcAEd/+hemLbkWth6WBSzg6pdNX 2q0neTwO+YD2CWoP/ArwFm1xAew2erYTGBaJQTlaQgTkom6UJ9olbFcZAz4J6f4G +Evq0xOe8blekx4qgftwV1H7qmeMvkxLFgEKyb6s7RMUkNOw/lCbDsKFFi8WJ27h tSnA3iKTNDSZk5XJnY+FJR5/1ks6bk21S+wQ0vDvcEPVOyvLyHzWUESEVdFoO61m p+FshKbThnTMwEHkt87i1OVQHYSRgkgGTzzWF5mYi0nXkl4frUdjv3eO3krphFbZ XnMLzLPYEDPPFGV8GJgDLybzgyYbt4c2X1bALx38JdLzrIHhMXNn3wpi/4hEYenM H6wNf+U8BgkM3kluc9RrJsrs8+nkSStECbaQIThKKGSWDm1HIfAurSsGTleKMp4t CVJGNsLFQ8CXTD/QfibtT7v48OxTQaQ+QYZRiOmXLbGH9hsJy/8= =iR3S -----END PGP SIGNATURE----- --Apple-Mail=_1D04A23F-CDBC-4584-8CEF-0684ED415465--