path: root/f2/014c8be5c1755e76831c5ac2d8bce59fff5788

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 F3AD44A3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 22:26:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com
	[209.85.215.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A387CF6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 22:26:17 +0000 (UTC)
Received: by mail-lf0-f53.google.com with SMTP id y15so10566538lfd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 15:26:17 -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=zDi+8kS2yhOtsdlY0JTJi97DpPQ7aiPb3c6h2BigMgE=;
	b=BzlchnQP/bvnAAK34Mna1Cz8rplzf5mBx59k3w64Jh3RcDWUgDWtw/fD3X8xG78cpP
	jGEq/nTEv399cwcfxv5VvaLdfN4gTbWAzRuxZqwknvhzEypZdW7+6dXLaph4ndr0A2e1
	PMQZI3kxfu5utuRkNxpyEcKga4C6iWJIt/1SeXtjHlOSnfqQDw3JdX/dYDVPLnIIxhKq
	OvCZxLry2N86JNdmAnLqkmDm46th2LnLTNXfjNGD9kmAtKuTLKEPK10T12mJPsQRkbbO
	klK4hZhZNWHRnZSG27GWvIam8mhKLYwW3/jG9aw1FIq++WYvZKadI2sJlxJchvFJTozp
	3Pnw==
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=zDi+8kS2yhOtsdlY0JTJi97DpPQ7aiPb3c6h2BigMgE=;
	b=nLFEOPD3RFmj4g5KJkRzaQsyZ+eiLZ0lzWbghFlHvPtZuFe6mcrKqYbV2ye6rwcDUI
	fBgdxmZDrvvuIOjborY/rypLkkR2N8gbYyXkDcf8kJ/PnQswO63YJBQhjmWVzrNq4tTF
	mCJ7xl4Cz7ZV7YD48v2eSLzwOEHeISsnZvP/Ef9iSId2QSI928LSGfen/i74Rw0/U6PJ
	oQ/u+foieXSmv7PNUtUa2WnTui/xIYBU3vSTuHMjgXklIFaeUJbfuA5xODNRz86cfWIu
	5mKQ1T2ZMzFCHaP259BVCMTMRv1WZILoeajcJ0JRmPmeoK1bA3W1PKdwX4dtGzEnJ0ws
	R43A==
X-Gm-Message-State: AHYfb5jmVrYr0PrSUXOVnEvQOZnMDuC2DO+UMmJFvNhiuYiZ4W4+zrg0
	9+DluITZ7/8mlYurxdZJcFSdRgkUUw==
X-Received: by 10.25.156.205 with SMTP id f196mr716776lfe.78.1503786375943;
	Sat, 26 Aug 2017 15:26:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.20.76 with HTTP; Sat, 26 Aug 2017 15:26:15 -0700 (PDT)
In-Reply-To: <DEC1CF18-5425-41C2-88DF-399BD32CD6F1@gmail.com>
References: <CACQPdjpPTHKQaY5NOvhEvSX1X3Jc9X4fcO7=Qy6Epwbftg4NOQ@mail.gmail.com>
	<DEC1CF18-5425-41C2-88DF-399BD32CD6F1@gmail.com>
From: Adam Tamir Shem-Tov <tshachaf@gmail.com>
Date: Sun, 27 Aug 2017 01:26:15 +0300
Message-ID: <CACQPdjqwG9F0+9hbcP_kMf5gZr+DeATQs1TE_YekG_EDLvavqg@mail.gmail.com>
To: Christian Riley <criley@gmail.com>
Content-Type: multipart/alternative; boundary="001a11411130c19c070557af8ca4"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, LOTS_OF_MONEY,
	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 22:27:06 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 22:26:19 -0000

--001a11411130c19c070557af8ca4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank You Christian for your response.

https://bitcointalk.org/index.php?topic=3D473.0 :  I dont see the relevance=
.
https://bitcointalk.org/index.php?topic=3D52859.0 : This idea does not seem
to talking about trimming the full node. Trimming the full node is the key,
the full node is what keeps us secure from hackers. If it can be trimmed
without losing security, that would be good, that is what I am proposing.
https://bitcointalk.org/index.php?topic=3D12376.0 : Same answer as 505.0.
https://bitcointalk.org/index.php?topic=3D74559.15 : I think his proposal i=
s
similar to mine, unfortunately for us his predictions were way off. He was
trying to fix this problem while believing that in the year 2020 the
blockchain would be 4GB!!! It is not his fault, his prediction was in 2011.
But you can see, by his prediction, which was rational at the time, was way
off. And it stresses my point, we need to fix this now. Too bad, no one
took him seriously back then, when the block chain i was 1GB.
*https://bitcointalk.org/index.php?topic=3D56226.0
<https://bitcointalk.org/index.php?topic=3D56226.0>*: Another guy with a
valid point, who was first acknowledged and then apparently ignored.
.
To summarize, this problem was brought up about 6 years ago, when the
blockchain was 1GB in size, Now it is about 140GB in size. I think it is
about time we stop ignoring this problem, and realize something needs to
change, or else the only full-nodes you will have will be with private
multi-million dollar companies, because no private citizen will have the
storage space to keep it. That would make bitcoin the worst decentralized
or uncentralized system in history.


On 27 August 2017 at 00:42, Christian Riley <criley@gmail.com> wrote:

> There have been a number of similar (identical?) proposals over the years=
,
> some were discussed in these threads:
> https://bitcointalk.org/index.php?topic=3D56226.0
> https://bitcointalk.org/index.php?topic=3D505.0
> https://bitcointalk.org/index.php?topic=3D473.0
> https://bitcointalk.org/index.php?topic=3D52859.0
> https://bitcointalk.org/index.php?topic=3D12376.0
> https://bitcointalk.org/index.php?topic=3D74559.15
>
>
> On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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 th=
e
> 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 everyon=
e.<BR>
> But this account will not be able to send or receive any funds in a norma=
l
> block, it will be blocked--blacklisted. So no one can intentionally use i=
t.
> 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 usi=
ng
> 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 previou=
s
> 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 s=
o
> 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 coin=
s,
> 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 sen=
t
> to the miners through a regular transaction.
>
> <BR>
>
> Adam Shem-Tov
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a11411130c19c070557af8ca4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thank You Christian for your response.<br><br><a href=
=3D"https://bitcointalk.org/index.php?topic=3D473.0" style=3D"background-co=
lor:rgba(255,255,255,0)" target=3D"_blank"><font color=3D"#000000">https://=
bitcointalk.org/index.<wbr>php?topic=3D473.0</font></a> :=C2=A0 I dont see =
the relevance.<br><a href=3D"https://bitcointalk.org/index.php?topic=3D5285=
9.0" style=3D"background-color:rgba(255,255,255,0)" target=3D"_blank"><font=
 color=3D"#000000">https://bitcointalk.org/index.<wbr>php?topic=3D52859.0</=
font></a> : This idea does not seem to talking about trimming the full node=
. Trimming the full node is the key, the full node is what keeps us secure =
from hackers. If it can be trimmed without losing security, that would be g=
ood, that is what I am proposing.<br><a href=3D"https://bitcointalk.org/ind=
ex.php?topic=3D12376.0" style=3D"background-color:rgba(255,255,255,0)" targ=
et=3D"_blank"><font color=3D"#000000">https://bitcointalk.org/index.<wbr>ph=
p?topic=3D12376.0</font></a> : Same answer as 505.0. <br><a href=3D"https:/=
/bitcointalk.org/index.php?topic=3D74559.15" style=3D"background-color:rgba=
(255,255,255,0)" target=3D"_blank"><font color=3D"#000000">https://bitcoint=
alk.org/index.<wbr>php?topic=3D74559.15</font></a> : I think his proposal i=
s similar to mine, unfortunately for us his predictions were way off. He wa=
s trying to fix this problem while believing that in the year 2020 the bloc=
kchain would be 4GB!!! It is not his fault, his prediction was in 2011. But=
 you can see, by his prediction, which was rational at the time, was way of=
f. And it stresses my point, we need to fix this now. Too bad, no one took =
him seriously back then, when the block chain i was 1GB.<br><u><a href=3D"h=
ttps://bitcointalk.org/index.php?topic=3D56226.0">https://bitcointalk.org/i=
ndex.php?topic=3D56226.0</a></u>: Another guy with a valid point, who was f=
irst acknowledged and then apparently ignored.<br>.<br></div>To summarize, =
this problem was brought up about 6 years ago, when the blockchain was 1GB =
in size, Now it is about 140GB in size. I think it is about time we stop ig=
noring this problem, and realize something needs to change, or else the onl=
y full-nodes you will have will be with private multi-million dollar compan=
ies, because no private citizen will have the storage space to keep it. Tha=
t would make bitcoin the worst decentralized or uncentralized system in his=
tory.<br><div><div><br></div></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On 27 August 2017 at 00:42, Christian Riley <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:criley@gmail.com" target=3D"_blank">criley=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"auto"><div><div><span style=3D"background-color:rgba(255,255,255,0)">Th=
ere have been a number of similar (identical?) proposals over the years, so=
me were discussed in these threads:</span></div><div><a href=3D"https://bit=
cointalk.org/index.php?topic=3D56226.0" style=3D"background-color:rgba(255,=
255,255,0)" target=3D"_blank"><font color=3D"#000000">https://bitcointalk.o=
rg/index.<wbr>php?topic=3D56226.0</font></a></div><div><a href=3D"https://b=
itcointalk.org/index.php?topic=3D505.0" style=3D"background-color:rgba(255,=
255,255,0)" target=3D"_blank"><font color=3D"#000000">https://bitcointalk.o=
rg/index.<wbr>php?topic=3D505.0</font></a></div><div><a href=3D"https://bit=
cointalk.org/index.php?topic=3D473.0" style=3D"background-color:rgba(255,25=
5,255,0)" target=3D"_blank"><font color=3D"#000000">https://bitcointalk.org=
/index.<wbr>php?topic=3D473.0</font></a></div><div><a href=3D"https://bitco=
intalk.org/index.php?topic=3D52859.0" style=3D"background-color:rgba(255,25=
5,255,0)" target=3D"_blank"><font color=3D"#000000">https://bitcointalk.org=
/index.<wbr>php?topic=3D52859.0</font></a></div><div><a href=3D"https://bit=
cointalk.org/index.php?topic=3D12376.0" style=3D"background-color:rgba(255,=
255,255,0)" target=3D"_blank"><font color=3D"#000000">https://bitcointalk.o=
rg/index.<wbr>php?topic=3D12376.0</font></a></div><div><div id=3D"m_4985029=
359135226761AppleMailSignature"><a href=3D"https://bitcointalk.org/index.ph=
p?topic=3D74559.15" style=3D"background-color:rgba(255,255,255,0)" target=
=3D"_blank"><font color=3D"#000000">https://bitcointalk.org/index.<wbr>php?=
topic=3D74559.15</font></a></div></div><br></div><div><div class=3D"h5"><di=
v><br>On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br><br></div><blo=
ckquote type=3D"cite"><div><div dir=3D"ltr">


=09
=09
=09
=09


<p style=3D"margin-bottom:0in;line-height:100%">&lt;B&gt;Solving the
Scalability Problem Part
II&lt;/B&gt;<br>
------------------------------<wbr>------------------------------<wbr>-----=
---<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>
------------------------------<wbr>-----------&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 =E2=80=9CGenes=
is
Account=E2=80=9D, this account=E2=80=99s 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=3D"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 =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%">&lt;BR&gt;</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>
</div></blockquote></div></div><blockquote type=3D"cite"><div><span>_______=
_______________________<wbr>_________________</span><br><span>bitcoin-dev m=
ailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><=
/span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/ma=
ilman/listinfo/bitcoin-<wbr>dev</a></span><br></div></blockquote></div></bl=
ockquote></div><br></div>

--001a11411130c19c070557af8ca4--