From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 12AB988A for ; Tue, 21 Jun 2016 15:31:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 70E4D19B for ; Tue, 21 Jun 2016 15:31:03 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id c73so25818170qkg.2 for ; Tue, 21 Jun 2016 08:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=BzU6IKva8tf2XAYR+/56wzEknS9OE72wx6MsHjB+ZnU=; b=IiX5Gb1vaUYFXA5saVprHn28uUVasanh4k6nFkshyWxKG6ECXiFWPajnEtvL4RAfTq nhFCKDyNtmgV+OobD0nOBWy0rIAGyg8Vs0ZT2fnBXApgyCoxsRuNxqoxyECz0p26jEom Az5B8sawsGTK45bN2eMKzDJaFWVVUNn9QD9yyIFsmg6BOCFcMnF4dFSM01+GBExG9EMU wwQubLbH+tAS/fH7tOd55CpR1o1ACel6O4HW/a6PqoPoExAuUjyQv8PROvtIeEDReIUd vYlnfV6wT16Rq8GHWab6LchVu7TnzWk+nnYJT7ttVmI26RreHw8LSE9x0TnHnI49rsG9 dUsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BzU6IKva8tf2XAYR+/56wzEknS9OE72wx6MsHjB+ZnU=; b=MCsV4V/XmsEoAk8vk4HgHsJwbnlF7ajNYZpThGF3IlCEhYB/Gvhnq2JilHIu5/+7Rz YGjCz9M3IhKEWF3VV9oeSVRy7PEPSQlX4l98BkZVTOhtcTzYc6DgmCa5K5vlJmDARiqG 4YBpTqh54xavFOWIFHZ5V0dkOFC3MdDjTMdaMU8yqRg90x9R+5+Z8uzkfDTY7M0RKmLV k7Uw3w60IddhWrMC/8wwY4raBtH7yTuWQKBUs5v8Dm1FtNhrzlxggyPpuZiNYO8ITiB2 YXaRgE0SYG7gwHALfWBWn/BX/Gc74beLVkFRxXrWnJEstH8jsYPX3mZ5W0pSqVCWncWh mp/w== X-Gm-Message-State: ALyK8tI97etIUAo+i1QcAY3Uz0H75L3qxgdiWGnL4aoAR1tB+Z1WgwRm3BUA8Y8zkNb5d0Il+rsMhJ/kEBBVwg== X-Received: by 10.200.44.78 with SMTP id e14mr29795639qta.77.1466523062345; Tue, 21 Jun 2016 08:31:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.93.56 with HTTP; Tue, 21 Jun 2016 08:31:01 -0700 (PDT) From: Akiva Lichtner Date: Tue, 21 Jun 2016 11:31:01 -0400 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11415f502fa5160535cb82ee 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, T_FILL_THIS_FORM_SHORT 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, 21 Jun 2016 20:30:35 +0000 Subject: [bitcoin-dev] Geographic Partitioning X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:31:04 -0000 --001a11415f502fa5160535cb82ee Content-Type: text/plain; charset=UTF-8 I am a long-time developer and I have some experience in process groups. I am going to try to keep this short. If you are interested in pursuing this idea please reply to me privately so we don't put a burden on the list. As per Satoshi's paper, the blockchain implements a distributed timestamp service. It defeats double-spending by establishing a "total order" on transactions. The "domain" on which the ordering takes place is the entire coin, the money supply. It's obvious to me that total ordering does not scale well as a use case, it's not a matter of implementation details or design. It's the requirement which is a problem. Therefore when I see mention of the many clever schemes proposed to make Bitcoin scalable I already know that by using that proposal we are going to give up something. And in some cases I see lengthy and complex proposals, and just what the user is giving up is not easy to see. I think that the user has to give up something in order for electronic cash to really scale, and that something has to be non-locality. At the moment Bitcoin doesn't know whether I am buying a laptop from 3,000 miles away or 300. This is a wonderful property, but this property makes it impossible to partition the users geographically. I think that a simple and effective way to do this is to partition the address using a hash. A convention could be adopted whereby there is a well-known partition number for each geographic location. Most users would use third-party clients and the client could generate Bitcoin addresses until it hits one in the user's geographical area. The partitioning scheme could be hierarchical. For example there could be partitions at the city, state, and country level. A good way to see how this works in real life is shopping at Walmart, which is something like 4,000 stores. Walmart could have users pay local addresses, and then move the money "up" to a regional or country level. The problem is what to do when an address in partition A wants to pay an address in partition B. This should be done by processing the transaction in partition A first, and once the block is made a hash of that block should be included in some block in partition B. After A has made the block the coin has left A, it cannot be spent. Once B has made its block the coin has "arrived" in B and can be spent. It can be seen that some transactions span a longer distance than others, in that they require two or more blocks. These transactions take longer to execute, and I think that that is entirely okay. Transaction verification benefits because a small merchant can accept payments from local addresses only. Larger merchants can verify transactions across two or more partitions. Some will be concerned about 51% attacks on partitions. I would point out that nodes could process transactions at random, so that the majority of the computing power is well-balanced across all partitions. Regards, Akiva --001a11415f502fa5160535cb82ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am a long-time develo= per and I have some experience in process groups. I am going to try to keep= this short. If you are interested in pursuing this idea please reply to me= privately so we don't put a burden on the list.

As per Satoshi's paper, the blockchain implements a dis= tributed timestamp service. It defeats double-spending by establishing a &q= uot;total order" on transactions. The "domain" on which the = ordering takes place is the entire coin, the money supply. It's obvious= to me that total ordering does not scale well as a use case, it's not = a matter of implementation details or design. It's the requirement whic= h is a problem. Therefore when I see mention of the many clever schemes pro= posed to make Bitcoin scalable I already know that by using that proposal w= e are going to give up something. And in some cases I see lengthy and compl= ex proposals, and just what the user is giving up is not easy to see.

I think that the user has to give up somet= hing in order for electronic cash to really scale, and that something has t= o be non-locality. At the moment Bitcoin doesn't know whether I am buyi= ng a laptop from 3,000 miles away or 300. This is a wonderful property, but= this property makes it impossible to partition the users geographically. I= think that a simple and effective way to do this is to partition the addre= ss using a hash. A convention could be adopted whereby there is a well-know= n partition number=C2=A0for each=C2=A0geographic location. Most users would= use third-party clients and the client could generate Bitcoin addresses un= til it hits one in the user's geographical area.
The partitioning scheme could be hierarchical. For example = there could be partitions at the city, state, and country level. A good way= to see how this works in real life is shopping at Walmart, which is someth= ing like 4,000 stores. Walmart could have users pay local addresses, and th= en move the money "up" to a regional or country level.

The= problem is what to do when an address in partition A wants to pay an addre= ss in partition B. This should be done by processing the transaction in par= tition A first, and once the block is made a=C2=A0hash of that block should= be included in some block in partition B. After A has made the block the c= oin has left A, it cannot be spent. Once B has made its block the coin has = "arrived" in B and can be spent. It can be seen that some transac= tions span a longer distance than others, in that they require two or more = blocks. These transactions take longer to execute, and I think that that is= entirely okay.

Transaction verification b= enefits because a small merchant can accept payments from local addresses o= nly. Larger merchants can verify transactions across two or more partitions= .

Some will be concerned about 51% attacks on partitions. I would=C2=A0p= oint out=C2=A0that nodes could process transactions at random, so that the = majority of the computing power is well-balanced across all partitions.

=
Regards,
<= font color=3D"#555555">Akiva

--001a11415f502fa5160535cb82ee--