public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: CryptAxe <cryptaxe@gmail.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	 Tao Effect <contact@taoeffect.com>
Subject: Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC
Date: Tue, 10 Oct 2017 13:49:20 -0700	[thread overview]
Message-ID: <CAF5CFkjz5WvkR_4HL2NSevDzHsG_LUTsYS_A9BHcOQctSynQoQ@mail.gmail.com> (raw)
In-Reply-To: <C216A90B-D08D-4B89-98EE-761ED303F180@taoeffect.com>

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

You could technically call myself and Chris 'core developers'. You don't
get to have a fixed rate of Bitcoin and a second way to mint coins at the
same time.

On Oct 10, 2017 1:46 PM, "Tao Effect via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What?
>
> That is not correct.
>
> There is a fixed amount of Bitcoin, as I said.
>
> The only difference is what chain it is on.
>
> It is precisely because there is a fixed amount that when you
> burn-to-withdraw you mint on another chain.
>
> I will not respond to any more emails unless they’re from core developers.
> Gotta run.
>
> --
> Sent from my mobile device.
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> > On Oct 10, 2017, at 1:23 PM, James Hudon <jameshudon@gmail.com> wrote:
> >
> > You're asking for newly minted bitcoin to go to you but you burned the
> bitcoin used in the peg. You're effectively losing your money and then
> stealing from the miners to gain it back. The miners had to issue your
> amount of bitcoin 2 times (once for your original bitcoin, again to make
> you whole). Why would they agree to this?
> > --
> > hudon
> >
> >> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> 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 with the NSA.
> >>
> >>> On Oct 10, 2017, at 12:50 PM, CryptAxe <cryptaxe@gmail.com> wrote:
> >>>
> >>> 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 passes for a technical argument these days? Sheesh.
> >>>
> >>> 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).
> >>>
> >>> Drivechain offers objectively worse security.
> >>>
> >>> --
> >>> Sent from my mobile device.
> >>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>
> >>>> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>>
> >>>> 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>
> 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 ― 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev@lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  reply	other threads:[~2017-10-10 20:49 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
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 [this message]
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=CAF5CFkjz5WvkR_4HL2NSevDzHsG_LUTsYS_A9BHcOQctSynQoQ@mail.gmail.com \
    --to=cryptaxe@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