MIME-Version: 1.0
From: Akiva Lichtner <akiva.lichtner@gmail.com>
Date: Tue, 21 Jun 2016 11:31:01 -0400
Message-ID: <CABCnA7XRxcABN2R2yQymGi3XYvG_CiiOZfa9+x=B0F51yr36uw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11415f502fa5160535cb82ee
Subject: [bitcoin-dev] Geographic Partitioning
Precedence: list

--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

<div dir=3D"ltr"><div><span><font color=3D"#555555">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&#39;t put a burden on the list.</font></span></div><di=
v><span><font color=3D"#555555"></font></span><br></div><div><span><font co=
lor=3D"#555555">As per Satoshi&#39;s paper, the blockchain implements a dis=
tributed timestamp service. It defeats double-spending by establishing a &q=
uot;total order&quot; on transactions. The &quot;domain&quot; on which the =
ordering takes place is the entire coin, the money supply. It&#39;s obvious=
 to me that total ordering does not scale well as a use case, it&#39;s not =
a matter of implementation details or design. It&#39;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.</font=
></span></div><div><span><font color=3D"#555555"></font></span><br></div><d=
iv><span><font color=3D"#555555">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&#39;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&#39;s geographical area.</font></span></div><di=
v><span><font color=3D"#555555"></font></span><br></div><div><span><font co=
lor=3D"#555555">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 &quot;up&quot; to a regional or country level.</font></sp=
an></div><div><span><font color=3D"#555555"></font></span><span><font color=
=3D"#555555"></font></span><br></div><div><span><font color=3D"#555555">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 =
&quot;arrived&quot; 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.</font></span></div><div><span><font color=3D"#555555"></fon=
t></span><br></div><div><span><font color=3D"#555555"><div><span><font colo=
r=3D"#555555"><div><span><font color=3D"#555555">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=
.</font></span></div></font></span></div></font></span></div><div><span><fo=
nt color=3D"#555555"></font></span><br></div><div><span><font color=3D"#555=
555">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.</fo=
nt></span></div><div><span><font color=3D"#555555"></font></span><br></div>=
<div><span><font color=3D"#555555">Regards,</font></span></div><div><span><=
font color=3D"#555555">Akiva</font></span></div><div><span><font color=3D"#=
555555"></font></span><br></div></div>

--001a11415f502fa5160535cb82ee--