public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Akiva Lichtner <akiva.lichtner@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling by Partitioning
Date: Tue, 8 Dec 2015 13:30:01 -0500	[thread overview]
Message-ID: <CABCnA7UdOg_3nq2SSuzdAwQMSdmPtr1=f0aRj3=MS7OiqdYVDw@mail.gmail.com> (raw)
In-Reply-To: <CABaSBazMd4VYhSgM0-=DWU7_AAGxvXiW2yjsft4bKw8gAtpuNg@mail.gmail.com>

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

Thanks for your response and links.

I think the difference is that those proposals all shard the mining work,
whereas what I wrote in my post shards the coin itself. In other words
different parts of the coin space are forever segregated, never ending up
in the same block. It's a big difference conceptually because I could spend
money and a fraction of it makes it into a block in ten minutes and the
rest two hours later.

And I think that's where the potential for the scalability comes in. I am
not really scaling Bitcoin's present requirements, I am relaxing the
requirements in a way that leaves the users and the miners happy, but that
could provoke resistance by the part of of all of us that doesn't want
digital cash as much as it wants to make history.

All the best,
Akiva

P.S. Thanks for pointing out that I hit "reply" instead of "reply all"
earlier ...

On Tue, Dec 8, 2015 at 11:45 AM, Bryan Bishop <kanzure@gmail.com> wrote:

> On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > and miners would have to round-robin through partitions
>
> At first glance this proposal seems most similar to the sharding proposals:
>
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
> https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
>
> https://www.reddit.com/r/Bitcoin/comments/3u1m36/why_arent_we_as_a_community_talking_about/cxbamhn
> http://eprint.iacr.org/2015/1168.pdf (committee approach)
>
> > but clients would have to send more than one message in order to spend
> money
>
> Offloading work to the client for spends has in the past been a
> well-received concept, such as the linearized coin history idea.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>

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

  reply	other threads:[~2015-12-08 18:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 16:27 [bitcoin-dev] Scaling by Partitioning Akiva Lichtner
2015-12-08 16:45 ` Bryan Bishop
2015-12-08 18:30   ` Akiva Lichtner [this message]
2015-12-08 20:50 ` Patrick Strateman
2015-12-08 21:23   ` Akiva Lichtner
2015-12-08 21:29     ` Patrick Strateman
2015-12-08 21:41       ` Akiva Lichtner
2015-12-09  6:30 ` Loi Luu
2015-12-09 18:26   ` Akiva Lichtner
2015-12-09 21:16     ` Loi Luu
2015-12-10  4:04       ` Akiva Lichtner
2015-12-09 22:35   ` Andrew
2015-12-10  3:58     ` Akiva Lichtner
2015-12-10  4:31       ` Bryan Bishop
2015-12-10  4:08     ` Dave Scotese
2015-12-10  4:14       ` Dave Scotese

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='CABCnA7UdOg_3nq2SSuzdAwQMSdmPtr1=f0aRj3=MS7OiqdYVDw@mail.gmail.com' \
    --to=akiva.lichtner@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=kanzure@gmail.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