summaryrefslogtreecommitdiff
path: root/65/bd9d502029ab5fafaeefc9a24be50f6b2ad10b
blob: 05086f182b3d2f47f07420c86a054a25339cbf64 (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
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
Return-Path: <dermoth@aei.ca>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3A8E8491
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 21:41:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail001.aei.ca (mail001.aei.ca [206.123.6.130])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7697FD4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 21:41:44 +0000 (UTC)
Received: (qmail 10768 invoked by uid 89); 26 Aug 2017 21:41:43 -0000
Received: by simscan 1.2.0 ppid: 10763, pid: 10766, t: 0.0095s
	scanners: regex: 1.2.0 attach: 1.2.0
Received: from mail002.aei.ca (HELO mail002.contact.net) (206.123.6.132)
	by mail001.aei.ca with (DHE-RSA-AES256-SHA encrypted) SMTP;
	26 Aug 2017 21:41:43 -0000
Received: (qmail 30724 invoked by uid 89); 26 Aug 2017 21:41:43 -0000
Received: by simscan 1.2.0 ppid: 30691, pid: 30694, t: 8.7736s
	scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
	TVD_PH_BODY_ACCOUNTS_PRE autolearn=disabled version=3.3.1
Received: from dsl-66-36-135-64.mtl.aei.ca (HELO ?192.168.67.200?)
	(dermoth@66.36.135.64)
	by mail.aei.ca with ESMTPA; 26 Aug 2017 21:41:34 -0000
To: Adam Tamir Shem-Tov <tshachaf@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CACQPdjpPTHKQaY5NOvhEvSX1X3Jc9X4fcO7=Qy6Epwbftg4NOQ@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <57de4421-0162-67c5-8905-10f6b477644c@aei.ca>
Date: Sat, 26 Aug 2017 17:41:34 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CACQPdjpPTHKQaY5NOvhEvSX1X3Jc9X4fcO7=Qy6Epwbftg4NOQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------94FDD80BCBC57A26EA9D0652"
X-Mailman-Approved-At: Sat, 26 Aug 2017 21:44:10 +0000
Subject: Re: [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:41:45 -0000

This is a multi-part message in MIME format.
--------------94FDD80BCBC57A26EA9D0652
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I don't think you fully understand the way bitcoin works. There are no
"accounts" and no need to know the private key to change transactions in
the chain. What you need is to keep track of all unspent outputs (block
number, index, value and script/witness) so that they can be verified
once a transaction refers to it.

Everything you suggest about moving those funds to a "genesis account"
is nonsense and cannot work.

--
Thomas

On 26/08/17 05:01 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
> <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 =93Genesis
> Account=94, this account=92s Private Key and Public Key will be availab=
le
> 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 =93mines=94 the coins, and receives the mining bonus. In the Exod=
us
> 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
>


--------------94FDD80BCBC57A26EA9D0652
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I don't think you fully understand the way bitcoin works. There are
    no "accounts" and no need to know the private key to change
    transactions in the chain. What you need is to keep track of all
    unspent outputs (block number, index, value and script/witness) so
    that they can be verified once a transaction refers to it.<br>
    <br>
    Everything you suggest about moving those funds to a "genesis
    account" is nonsense and cannot work.<br>
    <br>
    --<br>
    Thomas<br>
    <br>
    <div class="moz-cite-prefix">On 26/08/17 05:01 PM, Adam Tamir
      Shem-Tov via bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CACQPdjpPTHKQaY5NOvhEvSX1X3Jc9X4fcO7=Qy6Epwbftg4NOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <p style="margin-bottom:0in;line-height:100%">&lt;B&gt;Solving
          the
          Scalability Problem Part
          II&lt;/B&gt;<br>
--------------------------------------------------------------------<br>
          &lt;BR&gt;<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.&lt;BR&gt;<br>
          Here is how that would
          work:&lt;BR&gt;<br>
          &lt;B&gt;The Genesis
          Account:&lt;/B&gt;<br>
          -----------------------------------------&lt;BR&gt;<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
          “Genesis
          Account”, this account’s Private Key and Public Key will be
          available to everyone.&lt;BR&gt;<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.&lt;BR&gt;<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.&lt;BR&gt;<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).&lt;BR&gt;<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.&lt;BR&gt;</p>
        <p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;<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 “mines” 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="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
        <p style="margin-bottom:0in;line-height:100%">Adam Shem-Tov</p>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------94FDD80BCBC57A26EA9D0652--