Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

From: Paul Sztorc <truthcoin@gmail•com>
To: Tao Effect <contact@taoeffect•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC
Date: Tue, 10 Oct 2017 07:20:36 -0400	[thread overview]
Message-ID: <CA+XQW1i-3dfRGr2vy=_P0BuXNbnoR_OmmOGGOmCcNEgkZeT_gg@mail.gmail.com> (raw)
In-Reply-To: <55CAABF4-4FB8-4230-8E51-014C1D347D72@taoeffect.com>

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7577 bytes --]