public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Paul Sztorc <truthcoin@gmail.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 11:09:21 -0400	[thread overview]
Message-ID: <daf438d1-7cca-aa0f-6bf7-3eef0d765d49@gmail.com> (raw)
In-Reply-To: <FBD96A02-243E-4E09-9204-EC90DE5EE576@taoeffect.com>

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

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 — 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
>> <mailto:truthcoin@gmail.com>> wrote:
>>
>> Haha, no. Because you "burned" the coins.
>>
>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact@taoeffect.com
>> <mailto: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
>>>     <mailto: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
>>>     <mailto: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
>>>         <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>>
>>>
>>
>


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

  reply	other threads:[~2017-10-10 15:09 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
2017-10-10 14:09       ` Tao Effect
2017-10-10 15:09         ` Paul Sztorc [this message]
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=daf438d1-7cca-aa0f-6bf7-3eef0d765d49@gmail.com \
    --to=truthcoin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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