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
|
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 BD3AF258
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 21:01:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com
[209.85.215.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 163F9D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 21:01:59 +0000 (UTC)
Received: by mail-lf0-f52.google.com with SMTP id y15so10277890lfd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Aug 2017 14:01:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=kklac6MtJvug0Rz7pxiqfSvKvaCF9faaYyZlgWkKukg=;
b=A6ibIXpl9v8R1+piJjWXtl6QIdsWfNvDM4w+rTTxTCyNmHtsxu7P8kHnUJuqr/BKHI
oyItbxdEqRIM833W666n5q17VXWhRB7k0r8SABjDr+yVjM8JoFELbkapw1tq9Id6DLlv
lj+XDkoqDoZe5CSC+df1OOaQRVI4NZ3hKtsb2UtMHw71Jnga+L5DRpNhrfUEy6fs2suh
3aB0cKGtOBL/VvLSRYXpm72t7MmRq9ChLKkCE6gPG2e+bdo3/DfmKBLE3iu5WTZNH/Rg
xi0HxgXVD1gojQ72leMoIXd7bAhSsCimlYdmZe7xFzXgXI8v6Anldwk3o+WXGJ/yNBCx
r3Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=kklac6MtJvug0Rz7pxiqfSvKvaCF9faaYyZlgWkKukg=;
b=b9fiziZ3G4qBA4PtszfVMSeMZOLwGo+/9xOYwNdQiNOR9Ue054E17tUaQWe3Ya1XLy
ozr9lHM1yAB/gBfMSqywx4PQzaARVO6FvtxypK65fZ1hzxQMqX1tuwGdOQVtYySaYxPo
N5rgMOqG/eZRnI7WxDNSGaFkfTOXuck4nOY977A596ck0Z3B1FbDawjk/gZ352sAzWMB
gq7MmgDXnn/R/hM1bhLcxdHdJM12KV5FhM/FbKSqyVywr0et/C8vLe21Q4EQgCjAefm8
oKYObpXAjXsqsqKiByaLlRMqmcRnpUEVkJbnMkFo+Z4Pmk96LNR6UyAKUoc9t8r3AtuL
YbUg==
X-Gm-Message-State: AHYfb5jIn6LSSJKeKv3Wm9vD4XbytP2YzGGeBrky0SOrKWVHlhrU9veh
QXu+Js6Ve0IkLMQC6BuPiZsX/R2Ay9lB
X-Received: by 10.46.5.80 with SMTP id 77mr898996ljf.91.1503781317021; Sat, 26
Aug 2017 14:01:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.20.76 with HTTP; Sat, 26 Aug 2017 14:01:56 -0700 (PDT)
From: Adam Tamir Shem-Tov <tshachaf@gmail.com>
Date: Sun, 27 Aug 2017 00:01:56 +0300
Message-ID: <CACQPdjpPTHKQaY5NOvhEvSX1X3Jc9X4fcO7=Qy6Epwbftg4NOQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a114a7264389a030557ae5f8b"
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,
TVD_PH_BODY_ACCOUNTS_PRE 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 21:12:44 +0000
Subject: [bitcoin-dev] Solving the Scalability Problem Part II - Adam
Shem-Tov
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 21:01:59 -0000
--001a114a7264389a030557ae5f8b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<B>Solving the Scalability Problem Part II</B>
--------------------------------------------------------------------
<BR>
In the previous post I showed a way to minimize the blocks on the block
chain, to lower the amount of space it takes on the hard drive, without
losing any relevant information.
I added a note, saying that the transaction chain needs to be rewritten,
but I did not give much detail to it.<BR>
Here is how that would work:<BR>
<B>The Genesis Account:</B>
-----------------------------------------<BR>
The problem with changing the transaction and block chain, is that it
cannot be done without knowing the private key of the sender of the of the
funds for each account. There is however a way to circumvent that problem.
That is to create a special account called the =E2=80=9CGenesis Account=E2=
=80=9D, this
account=E2=80=99s Private Key and Public Key will be available to everyone.=
<BR>
But this account will not be able to send or receive any funds in a normal
block, it will be blocked--blacklisted. So no one can intentionally use it.
The only time this account will be used is in the pruning block, a.k.a
Exodus Block.<BR>
When creating the new pruned block chain and transaction chain, all the
funds that are now in accounts must be legitimate, and it would be
difficult to legitimize them unless they were sent from a legitimate
account, with a public key, and a private key which can be verified. That
is where the Genesis account comes in. All funds in the Exodus Block will
show as though they originated and were sent from the Genesis Account using
its privatekey to generate each transaction.<BR>
The funds which are sent, must match exactly the funds existing in the most
updated ledger in block 1000 (the last block as stated in my previous
post).<BR>
In this way the Exodus Block can be verified, and the Genesis Account
cannot give free money to anyway, because if someone tried to, it would
fail verification.<BR>
<BR>
Now the next problem is that the number of Bitcoins keeps expanding and so
the funds in the Genesis Account need to expand as well. That can be done
by showing as though this account is the account which is mining the coins,
and it will be the only account in the Exodus Block which =E2=80=9Cmines=E2=
=80=9D the
coins, and receives the mining bonus. In the Exodus Block all coins mined
by the real miners will show as though they were mined by Genesis and sent
to the miners through a regular transaction.
<BR>
Adam Shem-Tov
--001a114a7264389a030557ae5f8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">
=09
=09
=09
=09
<p style=3D"margin-bottom:0in;line-height:100%"><B>Solving the
Scalability Problem Part
II</B><br>
--------------------------------------------------------------------<br>
<BR><br>
In
the previous post I showed a way to minimize the blocks on the block
chain, to lower the amount of space it takes on the hard drive,
without losing any relevant information.<br>
I added a note, saying
that the transaction chain needs to be rewritten, but I did not give
much detail to it.<BR><br>
Here is how that would
work:<BR><br>
<B>The Genesis
Account:</B><br>
-----------------------------------------<BR><br>
The
problem with changing the transaction and block chain, is that it
cannot be done without knowing the private key of the sender of the
of the funds for each account. There is however a way to circumvent
that problem. That is to create a special account called the =E2=80=9CGenes=
is
Account=E2=80=9D, this account=E2=80=99s Private Key and Public Key will be
available to everyone.<BR><br>
But this account will not be
able to send or receive any funds in a normal block, it will be
blocked--blacklisted. So no one can intentionally use it. The only
time this account will be used is in the pruning block, a.k.a Exodus
Block.<BR><br>
When creating the new pruned block chain and
transaction chain, all the funds that are now in accounts must be
legitimate, and it would be difficult to legitimize them unless they
were sent from a legitimate account, with a public key, and a private
key which can be verified. That is where the Genesis account comes
in. All funds in the Exodus Block will show as though they originated
and were sent from the Genesis Account using its privatekey to
generate each transaction.<BR><br>
The funds which are sent,
must match exactly the funds existing in the most updated ledger in
block 1000 (the last block as stated in my previous post).<BR><br>
In
this way the Exodus Block can be verified, and the Genesis Account
cannot give free money to anyway, because if someone tried to, it
would fail verification.<BR></p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR><br>
Now
the next problem is that the number of Bitcoins keeps expanding and
so the funds in the Genesis Account need to expand as well. That can
be done by showing as though this account is the account which is
mining the coins, and it will be the only account in the Exodus Block
which =E2=80=9Cmines=E2=80=9D the coins, and receives the mining bonus. In =
the
Exodus Block all coins mined by the real miners will show as though
they were mined by Genesis and sent to the miners through a regular
transaction.</p>
<p style=3D"margin-bottom:0in;line-height:100%"><BR></p>
<p style=3D"margin-bottom:0in;line-height:100%">Adam Shem-Tov</p>
<p style=3D"margin-bottom:0in;line-height:100%"><br>
</p>
</div>
--001a114a7264389a030557ae5f8b--
|
