Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2867EB88 for ; Tue, 8 Dec 2015 18:30:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43D5E191 for ; Tue, 8 Dec 2015 18:30:03 +0000 (UTC) Received: by qgeb1 with SMTP id b1so29632418qge.1 for ; Tue, 08 Dec 2015 10:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nnUQkzTk0XAJCrgPKPkCJRlissXihdmF2UpYgOZw9ZY=; b=KvZQGABNnzLJRIkCXmtBTMBAIbAMxGOTDZZsgJByyl6aaWDsEXNPzO9gx9/3QH5jcv 3tEg3LAYFAjZJLTkAq0ZrVMbVpYic5L1g1tHVTTclrc5G93DGMS2I2untqhzAuHY0lVP WVH5S1cRrMdsvRleB5crexVR5VE4iLG9phVxQxQLE51rUppW+BBX2jyDm6hI29255DTH udih6F3Pr7oYgCasOsybKE1XOHebVPwMZT/QsS1/og1kgOfcaFDVuXTTvClOG8BI3B8A rBZF0pnIZd7ELL6+N7AwX1LA3xEnMWTSG5kd5Qvfkmrgn2/XHLZvdhecOX/LBFBQEVJx Fn2w== MIME-Version: 1.0 X-Received: by 10.55.75.216 with SMTP id y207mr1421552qka.19.1449599401996; Tue, 08 Dec 2015 10:30:01 -0800 (PST) Received: by 10.140.101.112 with HTTP; Tue, 8 Dec 2015 10:30:01 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Dec 2015 13:30:01 -0500 Message-ID: From: Akiva Lichtner To: Bryan Bishop Content-Type: multipart/alternative; boundary=001a114a7e706c388d0526672924 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 08 Dec 2015 18:31:56 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Scaling by Partitioning X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 18:30:04 -0000 --001a114a7e706c388d0526672924 Content-Type: text/plain; charset=UTF-8 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 wrote: > On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev > 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 > --001a114a7e706c388d0526672924 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your response and links.

=
I think the=20 difference is that those proposals all shard the mining work, whereas=20 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=20 same block. It's a big difference conceptually because I could spend=20 money and a fraction of it makes it into a block in ten minutes and the=20 rest two hours later.

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

All the bes= t,
Akiva

P.S. Thanks for pointing out that I hit &quo= t;reply" instead of "reply all" earlier ...

On Tue, Dec 8, 2015 at 1= 1:45 AM, Bryan Bishop <kanzure@gmail.com> wrote:
On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via = bitcoin-dev
<bitcoin-dev@li= sts.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/trans= cripts/scalingbitcoin/sharding-the-blockchain/
https://github.com/vbuterin= /scalability_paper/blob/master/scalability.pdf
ht= tps://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<= /a>

--001a114a7e706c388d0526672924--