summaryrefslogtreecommitdiff
path: root/6a/ff9c296f6ca61ee6355faa984b5c22d5aa4e06
blob: 9e44e905ec1991b33dbc53742d87f684e868ef0c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
Return-Path: <akiva.lichtner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 12AB988A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Jun 2016 15:31:03 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id c73so25818170qkg.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

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