public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2017-10-10 11:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-10  1:02 [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC Tao Effect
2017-10-10  1:39 ` Paul Sztorc
2017-10-10  5:19   ` Tao Effect
2017-10-10 11:20     ` Paul Sztorc [this message]
2017-10-10 14:09       ` Tao Effect
2017-10-10 15:09         ` Paul Sztorc
2017-10-10 19:25           ` Tao Effect
2017-10-10 19:50             ` CryptAxe
2017-10-10 20:13               ` Tao Effect
     [not found]                 ` <F437D8FA-892B-46C7-B0B8-8B5487DD8034@gmail.com>
2017-10-10 20:43                   ` Tao Effect
2017-10-10 20:49                     ` CryptAxe
2017-10-10 20:57                     ` James Hudon
2017-10-11  2:04                     ` Ben Kloester
2017-10-10 20:23         ` Lucas Clemente Vella
2017-10-10 20:18   ` Lucas Clemente Vella
     [not found]     ` <CA+XQW1hjjY3btufV36AS7JO=CQ7TMwK7ohJ4QETbNuGWyQ6=dA@mail.gmail.com>
2017-10-10 20:23       ` Paul Sztorc
  -- strict thread matches above, loose matches on Subject: below --
2017-10-10  0:04 Tao Effect

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+XQW1i-3dfRGr2vy=_P0BuXNbnoR_OmmOGGOmCcNEgkZeT_gg@mail.gmail.com' \
    --to=truthcoin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=contact@taoeffect.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox