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
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
|
Return-Path: <tshachaf@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B9BF1504
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 22:32:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com
[209.85.215.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5EFBDAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 22:32:19 +0000 (UTC)
Received: by mail-lf0-f54.google.com with SMTP id k186so10410381lfe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 15:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=xrH1zTKMzyQdq6fhHJNRMN7CjgvNVvFGzM4gN3T3jpE=;
b=Isi5gBjaE/86LMwCDJe2BNLKQ/bTTHm1SSZCDnYESsILxc2ytlrYbdi2QJbF7tKUkh
sOeTzrIR0dV4NX9HSqebRBI4UAxW5eSs99cRGfHERSr7M2LzyOnMMizDzq/utqZ3yG+A
AKC7ia7Sjh7qDHseGVF9b8up9w5ctb504bAlsTlwvvoiriKsTzxcL6LYa5igzsxSG/Q0
1IsBsEFFHeZFYOGWTIB3YkoiZOZD7ztlNFEX4KAmKqHXTo+3DMACvkm/Is1JOlTfrLno
18MojvG8vtMfXMV3LorISC4iGYX2/ajiS0rGQ3q0EO3PW0FgfMkZMB18FPU72ib9SGtC
Dpvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=xrH1zTKMzyQdq6fhHJNRMN7CjgvNVvFGzM4gN3T3jpE=;
b=nGtxp3aHTMfH2c1Esl/Q7HUlkxxCHpb+7muvJukKWV+Lh1xqV+JMJQQj9nP9UJRAgo
myqC0EC/ZMRqjIihc4eU1zO7xmDgiXLg+V9bNcXkhoKEU1OfhKMyjCkWzJ1zdw2bPBVZ
SySQfaLimh3b2k5g+ANHBpBc4odgYxeeEq280YrjZqGaPMQgzZTqb04Tf66yd5bgaMeJ
okwMM10cg2qFEg896gPF/13PkU3zTGbFy/f0FyACbNj1+K5R6wDbdEw88bJEGtXDAcsa
Y8s7K2aC/6rv23tLV/w8Jo7HJSlHz3oXoK7upfIJZGOewcv9SXzs3v4KlpPuUMqq7xqo
z4XQ==
X-Gm-Message-State: AHYfb5jRUzhBh7V5qmAiQn15IUg2ot07MRiEdIh6fb45QQcg+FaVTs1I
ES3Dr7JU9/GN73muJDYLImcYHyU2zd6l
X-Received: by 10.25.222.136 with SMTP id i8mr1092242lfl.64.1503786737748;
Sat, 26 Aug 2017 15:32:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.20.76 with HTTP; Sat, 26 Aug 2017 15:32:17 -0700 (PDT)
In-Reply-To: <a9015271-7f61-7bba-c550-afdd76319b21@aei.ca>
References: <CACQPdjphPmSC7bmicXGytuD3YAXYmsEGOECTTTuLfB_5iqDQGw@mail.gmail.com>
<a9015271-7f61-7bba-c550-afdd76319b21@aei.ca>
From: Adam Tamir Shem-Tov <tshachaf@gmail.com>
Date: Sun, 27 Aug 2017 01:32:17 +0300
Message-ID: <CACQPdjoqph7RJhk8Ec8B8SiXixdCQ0VQB5B3+U-1pPxyp=hj4g@mail.gmail.com>
To: Thomas Guyot-Sionnest <dermoth@aei.ca>
Content-Type: multipart/alternative; boundary="f403045fa58e524f610557afa2bf"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 26 Aug 2017 22:39:00 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
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: Sat, 26 Aug 2017 22:32:20 -0000
--f403045fa58e524f610557afa2bf
Content-Type: text/plain; charset="UTF-8"
Thank you Thomas for your response.
1) Implement solution is impossible... I have given a solution in part II.
By adding a Genesis Account which will be the new sender.
2)Keeping older blocks: Yes as I said 10 older blocks should be kept, that
should suffice. I am not locked on that number, if you think there is a
reason to keep more than that, it is open to debate.
3) Why 1000? To be honest, that number came off the top of my head. These
are minor details, the concept must first be accepted, then we can work on
the minor details.
4)Finally it's not just the addresses and balance you need to save... I
think the Idea of the Genesis Account, solves this issue.
5) The problem with node pruning is that it is not standardized, and for a
new node to enter the network and to verify the data, it needs to download
all data and prune it by itself. This will drastically lower the
information needed by the full nodes by getting rid of the junk. Currently
we are around 140GB, that number is getting bigger exponentially, by the
number of users and transactions created. It could reach a Terrabyte sooner
than expected, we need to act now.
On your second email:
When I say account: I mean private-public key.
The way bitcoin works, as I understand it, is that the funds are verified
by showing that they have an origin, this "origin" needs to provide a
signature, otherwise the transaction won't be accepted.
If I am proposing to remove all intermediate origins, then the funds become
untraceable and hence unverifiable. To fix that, a new transaction needs to
replace old ones. A simplified version: If there was a transaction chain
A->B->C->D, and I wish to show only A->D, only a transaction like that
never actually occurred, it would be impossible to say that it did without
having A's private key, in order to sign this transaction. In order to
create this transaction, I need A's private key. And if I wish this to be
publicly implemented I need this key to be public, so that any node
creating this Exodus Block can sign with it. Hence the Genesis Account. And
yes, it is not really an account.
On 27 August 2017 at 00:31, Thomas Guyot-Sionnest <dermoth@aei.ca> wrote:
> Pruning is already implemented in the nodes... Once enabled only unspent
> inputs and most recent blocks are kept. IIRC there was also a proposal to
> include UTXO in some blocks for SPV clients to use, but that would be
> additional to the blockchain data.
>
> Implementing your solution is impossible because there is no way to
> determine authenticity of the blockchain mid way. The proof that a block
> hash leads to the genesis block is also a proof of all the work that's been
> spent on it (the years of hashing). At the very least we'd have to keep all
> blocks until a hard-coded checkpoint in the code, which also means that as
> nodes upgrades and prune more blocks older nodes will have difficulty
> syncing the blockchain.
>
> Finally it's not just the addresses and balance you need to save, but also
> each unspent output block number, tx position and script that are required
> for validation on input. That's a lot of data that you're suggesting to
> save every 1000 blocks (and why 1000?), and as said earlier it doesn't even
> guarantee you can drop older blocks. I'm not even going into the details of
> making it work (hard fork, large block sync/verification issues, possible
> attack vectors opened by this...)
>
> What is wrong with the current implementation of node pruning that you are
> trying to solve?
>
> --
> Thomas
>
> On 26/08/17 03:21 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
> <B> Solving the Scalability issue for bitcoin </B> <BR>
>
> I have this idea to solve the scalability problem I wish to make public.
>
> If I am wrong I hope to be corrected, and if I am right we will all gain
> by it. <BR>
>
> Currently each block is being hashed, and in its contents are the hash of
> the block preceding it, this goes back to the genesis block.
>
> <BR>
>
> What if we decide, for example, we decide to combine and prune the
> blockchain in its entirety every 999 blocks to one block (Genesis block not
> included in count).
>
> <BR>
>
> How would this work?: Once block 1000 has been created, the network would
> be waiting for a special "pruned block", and until this block was created
> and verified, block 1001 would not be accepted by any nodes.
>
> This pruned block would prune everything from block 2 to block 1000,
> leaving only the genesis block. Blocks 2 through 1000, would be calculated,
> to create a summed up transaction of all transactions which occurred in
> these 999 blocks.
>
> <BR>
>
> And its hash pointer would be the Genesis block.
>
> This block would now be verified by the full nodes, which if accepted
> would then be willing to accept a new block (block 1001, not including the
> pruned block in the count).
>
> <BR>
>
> The new block 1001, would use as its hash pointer the pruned block as its
> reference. And the count would begin again to the next 1000. The next
> pruned block would be created, its hash pointer will be referenced to the
> Genesis Block. And so on..
>
> <BR>
>
> In this way the ledger will always be a maximum of 1000 blocks.
>
>
>
--f403045fa58e524f610557afa2bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>Thank you Thomas for your respons=
e.<br></div><br>1)
Implement solution is impossible... I have given a solution in part II.
By adding a Genesis Account which will be the new sender.<br><br></div>2)K=
eeping
older blocks: Yes as I said 10 older blocks should be kept, that should
suffice. I am not locked on that number, if you think there is a reason
to keep more than that, it is open to debate.<br><br></div>3) Why 1000?
To be honest, that number came off the top of my head. These are minor=20
details, the concept must first be accepted, then we can work on the=20
minor details.<br><br></div>4)Finally it's not just the addresses and=
=20
balance you need to save...=C2=A0 I think the Idea of the Genesis Account,=
=20
solves this issue.<br><br></div>5) The problem with node pruning is that
it is not standardized, and for a new node to enter the network and to=20
verify the data, it needs to download all data and prune it by itself.=20
This will drastically lower the information needed by the full nodes by=20
getting rid of the junk.=C2=A0 Currently we are around 140GB, that number i=
s=20
getting bigger exponentially, by the number of users and transactions=20
created. It could reach a Terrabyte sooner than expected, we need to act
now.<br><div><br></div><div>On your second email:<br></div><div>When I say=
account: I mean private-public key.<br></div><div>The
way bitcoin works, as I understand it, is that the funds are verified=20
by showing that they have an origin, this "origin" needs to provi=
de a=20
signature, otherwise the transaction won't be accepted.<br></div>If
I am proposing to remove all intermediate origins, then the funds=20
become untraceable and hence unverifiable. To fix that, a new=20
transaction needs to replace old ones. A simplified version: If there=20
was a transaction chain A->B->C->D, and I wish to show only=20
A->D, only a transaction like that never actually occurred, it would=20
be impossible to say that it did without having A's private key, in=20
order to sign this transaction. In order to create this transaction, I=20
need A's private key. And if I wish this to be publicly implemented I=
=20
need this key to be public, so that any node creating this Exodus Block=20
can sign with it. Hence the Genesis Account. And yes, it is not really=20
an account.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 27 August 2017 at 00:31, Thomas Guyot-Sionnest <span dir=3D"ltr"><<a =
href=3D"mailto:dermoth@aei.ca" target=3D"_blank">dermoth@aei.ca</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Pruning is already implemented in the nodes... Once enabled only
unspent inputs and most recent blocks are kept. IIRC there was also
a proposal to include UTXO in some blocks for SPV clients to use,
but that would be additional to the blockchain data.<br>
<br>
Implementing your solution is impossible because there is no way to
determine authenticity of the blockchain mid way. The proof that a
block hash leads to the genesis block is also a proof of all the
work that's been spent on it (the years of hashing). At the very
least we'd have to keep all blocks until a hard-coded checkpoint in
the code, which also means that as nodes upgrades and prune more
blocks older nodes will have difficulty syncing the blockchain.<br>
<br>
Finally it's not just the addresses and balance you need to save,
but also each unspent output block number, tx position and script
that are required for validation on input. That's a lot of data tha=
t
you're suggesting to save every 1000 blocks (and why 1000?), and as
said earlier it doesn't even guarantee you can drop older blocks.
I'm not even going into the details of making it work (hard fork,
large block sync/verification issues, possible attack vectors opened
by this...)<br>
<br>
What is wrong with the current implementation of node pruning that
you are trying to solve?<br>
<br>
--<br>
Thomas<span class=3D""><br>
<br>
<div class=3D"m_1233914848782501410moz-cite-prefix">On 26/08/17 03:21 P=
M, Adam Tamir
Shem-Tov via bitcoin-dev wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<p style=3D"margin-bottom:0in;line-height:100%"><B> Solving
the Scalability issue for bitcoin </B> <BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">I have this idea
to
solve the scalability problem I wish to make public.</p>
<p style=3D"margin-bottom:0in;line-height:100%">If I am wrong I
hope
to be corrected, and if I am right we will all gain by it.
<BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">Currently each
block
is being hashed, and in its contents are the hash of the block
preceding it, this goes back to the genesis block.</p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">What if we decide,
for example, we decide to combine and prune the blockchain in
its
entirety every 999 blocks to one block (Genesis block not
included in
count).</p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">How would this
work?: Once block 1000 has been created, the network would be
waiting
for a special "pruned block", and until this block was
created and verified, block 1001 would not be accepted by any
nodes.</p>
<p style=3D"margin-bottom:0in;line-height:100%">This pruned block
would prune everything from block 2 to block 1000, leaving
only the
genesis block. Blocks 2 through 1000, would be calculated, to
create
a summed up transaction of all transactions which occurred in
these
999 blocks.</p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">And its hash
pointer
would be the Genesis block.</p>
<p style=3D"margin-bottom:0in;line-height:100%">This block would
now
be verified by the full nodes, which if accepted would then be
willing to accept a new block (block 1001, not including the
pruned
block in the count).</p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">The new block
1001,
would use as its hash pointer the pruned block as its
reference. And
the count would begin again to the next 1000. The next pruned
block
would be created, its hash pointer will be referenced to the
Genesis
Block. And so on..</p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">In this way the
ledger will always be a maximum of 1000 blocks.</p>
<br>
</div>
</blockquote>
<br>
</span></div>
</blockquote></div><br></div>
--f403045fa58e524f610557afa2bf--
|