path: root/73/e352000b97bf26e3e8c3606d3382413ac77b98

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 CD7517A9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 27 Aug 2017 04:09:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
	[209.85.215.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCA78A1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 27 Aug 2017 04:09:11 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id y15so11578670lfd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 21:09:11 -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=bErNTtSENsL20x2QBzw81qLdr46XplN/7BDlucnVGJ0=;
	b=tIhBZzsO2qMwO08GzN1bWrcRE2jeSwwLtX2s2RqFyLhqdd6bgfVo1H59RNC35m0E6T
	NAIVrGvupKEudwwcDgAnnEJNX1QzFt838ALlTjPG5GZ/g3g2Uj3EDproLefmGyy7j/LG
	Tv88CJ6ck6Oh2ju0P4k1O0fGGc4D//lwq84l5IINa3hvIAGeSlclGJNfjUc3afiyKAXL
	z0uEwx0PnoC7OuEJlupFbkWf50NZnDBq00Tm1oOBdF+HWj0hD6VaVOXYr3Y1g7g1kg8V
	qDpn52Dqoj5dD4J7NeqaLoqfeMHgpJXFThTIPLbBt/J6q3A9NtxypXLgfi0Weag4JHYZ
	7P+Q==
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=bErNTtSENsL20x2QBzw81qLdr46XplN/7BDlucnVGJ0=;
	b=eGY46GaaYLC4/aLieXLIOKvfCpx5O0q20vlsbXxQjffVnCY++iLNo3PnZfnCE6fdjR
	bfIOYN4cvNoT3NJqkZRgxmZkdhLm/vSBZV8CDhNVX0wmU2HqqJkLmmxH5ZTJqs3NWf7E
	mMbL4lVM6ZO8akO+luCj/jN0s3FVHPkgMuqkiZFWwXkOAjCdToh4IkJ1H8C2dobhEGWf
	OtCQkrtOlON4LhKd3Sr44qo6C2RB4gmVmaA/3dV94Hud8cDPJozGuKY04TbD19O8EO5A
	80na7rnE/kSzIKlQPMmWbvSIx6k9/5s/6tLJ1226+ZyZRiivRWDOx0HHwEqhRC5rnKkg
	7D9A==
X-Gm-Message-State: AHYfb5iSX7jFF/c7bN78+kz8kMPh4NvEIxl9OgtAgnkc0LWsQ80uZbl4
	LmhQAQX6vWXbaIk9HI4wCDTIKRDQmUMS
X-Received: by 10.25.222.136 with SMTP id i8mr1291311lfl.64.1503806949578;
	Sat, 26 Aug 2017 21:09:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.20.76 with HTTP; Sat, 26 Aug 2017 21:09:08 -0700 (PDT)
From: Adam Tamir Shem-Tov <tshachaf@gmail.com>
Date: Sun, 27 Aug 2017 07:09:08 +0300
Message-ID: <CACQPdjoW+t7JMgkggDb41dOU6HSzQ5Vxv2LfU3E3Kn5opM3MTw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045fa58e0a5e450557b4578b"
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: Sun, 27 Aug 2017 11:49:42 +0000
Subject: [bitcoin-dev] Revised - 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: Sun, 27 Aug 2017 04:09:13 -0000

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

This is a link to the most updated version of the problem and my proposed
solution, granted it still needs work, but this problem needs to be
resolved quickly. So I hope it will receive the attention it deserves, even
if the solution comes from somebody else.
https://bitcointalk.org/index.php?topic=3D2126152.new#new

The latest version of the day:

*Solving the Scalability issue for Bitcoin  *

*What am I trying to solve?* Currently Bitcoin=E2=80=99s blockchain is arou=
nd 140GB.
In 2011 it took 1GB, and it was predicted back then that in 2020 that size
would be 4GB.
As you can see it is not yet 2020, and we are way over that predicted size.
At our current time, prune nodes which make the block smaller, but they can
not be validated without the full node. And this full node is getting
exponentially bigger, we need to stop that. Because if we don=E2=80=99t no =
private
citizen will have the capability of storing the full node in his computer,
and all full nodes will be at private multi-million dollar companies. That
would literally be the end of decentralization (or non-centralization).
What I am proposing also makes sure the blockchain has a maximum finite
size, because today the blockchain can grow to any size without limit while
it approaches an infinite size!
Today our blockchain is growing at speed which is much faster than Moore=E2=
=80=99s
law! This proposal will help set storage growth at a reasonable number.


*A short list of what I am about to explain:   Steps that need to be taken:=
*
---------------------------------------------------------------------------=
------------------------------------------
(The details are not described in this order)
1) Create a pair of keys, called the Genesis Pair, or Genesis Account, a
private and public key which will be publicly known to all and yet it=E2=80=
=99s use
will be restricted and monitored by all. The key will be the source of all
funds (Point A).
2) Preserve the Genesis Block, its hash code is needed. And personally I
think its of historical value.
3) Combine all Blocks up to the most recent (not including the Genesis
Block), and cut out all intermediary transactions, by removing All
transactions, and replacing them with new transactions sent from A to every
public key which has funds in the most recent block, in the amount they
have. And sign these transactions with A=E2=80=99s private-key. And create =
a new
block with this information.
4) This Combined/Pruned Block should point to the Genesis Block hash, and
the next block created should point to the Pruned Blocks hash. The random
number used for this pruned block will be predefined, this random number
normally used to meet the hash difficulty requirement in this case is not
needed, since no difficulty setting is necessary for this block, and by
predefining it, this block can be easily identified.
5) Download the pruned block from another node or create it yourself, the
hash code will be identical for everyone, since the block will be created
exactly the same everywhere.
6) Preserve a certain amount of the most recent blocks, just in case a
longer blockchain is discovered, and then the Pruned Block should be
recalculated.

---------------------------------------------------------------------------=
------------------------------------------
*Now for a more detailed description: *
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.
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.

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

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.

And its hash pointer would be the Genesis block.
This block would now be verified by the full nodes (or created by them),
which if accepted would then be willing to accept a new block (block 1001,
not including the pruned block in the count).

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..
In this way the ledger will always be a maximum of 1000 blocks.

 A bit more detail:

All the relevant outputs needed to verify early transactions will all be
preserved in the pruning block. The only information you lose are of the
intermediate transactions, not the final ones the community has already
accepted. Although the origin of the funds could not be known, there
destination is preserved, as well a validation that the transactions are
legitimate.
For example:

A =3D 2.3 BTC, B=3D0 BTC, C=3D1.4 BTC. (Block 1)
If A sends 2.3 BTC to B.  (Block 2)
And then B sends 1.5 BTC to C. (Block 3)
The pruning block will report:
A->B =3D 0.8 BTC and A->C=3D2.9 BTC.
The rest of the information you lose, is irrelevant. No one needs to know,
what exactly happened, who sent who what, or when. All that is needed is
the funds currently owned by each key.

Note:  The Transaction Chain would also need to be rewritten, to delete all
intermediate transactions, it will show as though transactions occurred
from the Genesis block directly to the pruned block, as though nothing ever
existed in between. This will be described below in more detail.

You can keep the old blocks on your drive for 10 more blocks or so, just in
case a longer block chain is found, but other than that the information it
holds is useless, since it has all been agreed upon. And the pruning block
holds all up to date account balances, so cheating is impossible.

Granted this pruning block can get extremely large in the future, it will
not be the regular size of the other blocks. For example if every account
has only 1 satoshi in it, which is the minimum, then the amount of accounts
will be at its maximum. Considering a transaction is about 256bytes. That
would mean the pruning block would be approximately 500PB, which is 500,000
Terra-bytes. That is a theoretical scenario, which is not likely to occur.
(256bytes*21M BTC*100M (satoshis in 1 BTC))

A scenario which could be solved by creating a minimum transaction fee of
for example: 100 satoshis, which would insure that even in the most
unlikely scenario, at worst the pruning block would be 5PB in size.
Which is still extremely large for today. But without implementing this
idea the blockchain literally does not have a finite maximum size, and over
time approaches infinity!

*Also, this pruning block does not even need to be downloaded, it could be
created by already existing information, each full node by itself, by: *
1) combining and pruning all previous blocks
2) using the genesis block as its hash pointer
3) using a predefined random number "2", which will be used by all. A
random number which is normally added to a block to ensure the block's
hash-rate difficulty, is not needed in this case, since all information can
be verified by each node by itself through pruning.
This number can also be used to identify this block as the Pruned/Combined
Block since it is static.
4) Any other information which is needed for the SHA256 hash, for example a
time-stamp could be copied off the last block in the block chain.
These steps will ensure each full node, will get the exact hash code as the
others have gotten for this pruning block.

And as I previously stated the next block will use this hash code as its
hash reference.
By creating a system like this, the pruning block does not have to be
created last minute, but gradually over time, every time a new block comes
in, and only when the last block arrives (block 1000), will it be
finalized, and hashed.
And since this block will always be second, it should go by the name
"Exodus Block".

Above, 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.

Here is how that would work:

*The Genesis Account (Key Pair):*
---------------------------------------------------
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.
To illustrate the problem: If we have a series of block chains with a
string of transactions that are A=E2=86=92B=E2=86=92C=E2=86=92D, and to sim=
plify the problem, all
money was sent during each transaction, so that no money is left in A or B
or C. And I was to prune these transactions, by replacing them with A=E2=86=
=92D.
Only this transaction never occurred, nor can anyone create it without A=E2=
=80=99s
private key.
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.
(Of course, accounts do not really exist in Bitcoin, when I say account
what I really mean is a Private/Public Key pair)
This account will be the source of all funds
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.
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
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 with the Genesis private-key to generate each transaction.
The funds which are sent, must match exactly the funds existing in the most
updated ledger in block 1000.
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.

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.

I hope this proposal will be implemented as soon as possible so that we can
avoid a problem which is growing by the minute. It was brought up about 6
years ago when the blockchain was only 1GB in size, nobody imagined back
then that it would grow so quickly, and the problem was ignored.
Today all solutions implemented have been implemented by software, and not
on the blockchain itself, these solutions are not helpful in the long run.

The full node needs to be publicly available to everyone, and at this rate,
nobody will have the hard-drive capacity to store. This will make us more
dependent on private corporation=E2=80=99s to store the blockchain, which w=
ill lead
us quickly to a centralized currency platform. By then it will be too late,
and the corporations will have complete control of what happens next.
Please take this problem seriously and work with me, to prevent it while we
still have some time.
The exact details can be worked out at a later time, but for now we need at
least an acknowledgment that this problem is dire, and needs to be solved
in a year=E2=80=99s time. I have presented a solution, if someone has a bet=
ter one,
then let him/her step forward, but in any case a solution needs to be
implemented as soon as possible.

*I have given a basic proposal, I am sure there are those among us with
more technical understanding to the nuances of how this idea should be
implemented. I am counting on their help to see this through.*

Adam Shem-Tov

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

<div dir=3D"ltr">This is a link to the most updated version of the problem =
and my proposed solution, granted it still needs work, but this problem nee=
ds to be resolved quickly. So I hope it will receive the attention it deser=
ves, even if the solution comes from somebody else.<br><h2 id=3D"gmail-:fv"=
 class=3D"gmail-hP" tabindex=3D"-1"><a href=3D"https://bitcointalk.org/inde=
x.php?topic=3D2126152.new#new">https://bitcointalk.org/index.php?topic=3D21=
26152.new#new</a></h2><p>The latest version of the day:<br><br><span style=
=3D"font-size:14pt;line-height:1.3em"><b>Solving the Scalability issue for =
Bitcoin=C2=A0 </b></span><br><br><b>What am I trying to solve?</b> Currentl=
y Bitcoin=E2=80=99s blockchain is around 140GB.<br>In 2011 it took 1GB, and=
 it was predicted back then that in 2020 that size would be 4GB.<br>As you =
can see it is not yet 2020, and we are way over that predicted size.<br>At
 our current time, prune nodes which make the block smaller, but they=20
can not be validated without the full node. And this full node is=20
getting exponentially bigger, we need to stop that. Because if we don=E2=80=
=99t=20
no private citizen will have the capability of storing the full node in=20
his computer, and all full nodes will be at private multi-million dollar
 companies. That would literally be the end of decentralization (or=20
non-centralization).<br>What I am proposing also makes sure the=20
blockchain has a maximum finite size, because today the blockchain can=20
grow to any size without limit while it approaches an infinite size! <br>To=
day
 our blockchain is growing at speed which is much faster than Moore=E2=80=
=99s=20
law! This proposal will help set storage growth at a reasonable number.<br>=
<br><br><b>A short list of what I am about to explain:=C2=A0 =C2=A0Steps th=
at need to be taken:</b><br>-----------------------------------------------=
----------------------------------------------------------------------<br>(=
The details are not described in this order)<br>1)
 Create a pair of keys, called the Genesis Pair, or Genesis Account, a=20
private and public key which will be publicly known to all and yet it=E2=80=
=99s=20
use will be restricted and monitored by all. The key will be the source=20
of all funds (Point A).<br>2) Preserve the Genesis Block, its hash code is =
needed. And personally I think its of historical value. <br>3)
 Combine all Blocks up to the most recent (not including the Genesis=20
Block), and cut out all intermediary transactions, by removing All=20
transactions, and replacing them with new transactions sent from A to=20
every public key which has funds in the most recent block, in the amount
 they have. And sign these transactions with A=E2=80=99s private-key. And c=
reate
 a new block with this information. <br>4) This Combined/Pruned Block=20
should point to the Genesis Block hash, and the next block created=20
should point to the Pruned Blocks hash. The random number used for this=20
pruned block will be predefined, this random number normally used to=20
meet the hash difficulty requirement in this case is not needed, since=20
no difficulty setting is necessary for this block, and by predefining=20
it, this block can be easily identified.<br>5) Download the pruned block
 from another node or create it yourself, the hash code will be=20
identical for everyone, since the block will be created exactly the same
 everywhere.<br>6) Preserve a certain amount of the most recent blocks,=20
just in case a longer blockchain is discovered, and then the Pruned=20
Block should be recalculated. <br><br>-------------------------------------=
---------------------------------------------------------------------------=
-----<br><b>Now for a more detailed description: </b><br>I have this idea t=
o solve the scalability problem I wish to make public.<br>If I am wrong I h=
ope to be corrected, and if I am right we will all gain by it. <br>Currentl=
y
 each block is being hashed, and in its contents are the hash of the=20
block preceding it, this goes back to the genesis block.<br><br>What if=20
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=20
in count).<br><br>How would this work?: Once block 1000 has been=20
created, the network would be waiting for a special &quot;pruned block&quot=
;, and=20
until this block was created and verified, block 1001 would not be=20
accepted by any nodes.<br>This pruned block would prune everything from=20
block 2 to block 1000, leaving only the genesis block. Blocks 2 through=20
1000, would be calculated, to create a summed up transaction of all=20
transactions which occurred in these 999 blocks.<br><br>And its hash pointe=
r would be the Genesis block.<br>This
 block would now be verified by the full nodes (or created by them),=20
which if accepted would then be willing to accept a new block (block=20
1001, not including the pruned block in the count).<br><br>The new block
 1001, would use as its hash pointer the pruned block as its reference.=20
And the count would begin again to the next 1000. The next pruned block=20
would be created, its hash pointer will be referenced to the Genesis=20
Block. And so on..<br>In this way the ledger will always be a maximum of 10=
00 blocks.<br><br>=C2=A0A bit more detail: <br><br>All
 the relevant outputs needed to verify early transactions will all be=20
preserved in the pruning block. The only information you lose are of the
 intermediate transactions, not the final ones the community has already
 accepted. Although the origin of the funds could not be known, there=20
destination is preserved, as well a validation that the transactions are
 legitimate.<br>For example:<br><br>A =3D 2.3 BTC, B=3D0 BTC, C=3D1.4 BTC. =
(Block 1)<br>If A sends 2.3 BTC to B.=C2=A0 (Block 2)<br>And then B sends 1=
.5 BTC to C. (Block 3)<br>The pruning block will report:<br>A-&gt;B =3D 0.8=
 BTC and A-&gt;C=3D2.9 BTC. <br>The
 rest of the information you lose, is irrelevant. No one needs to know,=20
what exactly happened, who sent who what, or when. All that is needed is
 the funds currently owned by each key.<br><br>Note:=C2=A0 The Transaction=
=20
Chain would also need to be rewritten, to delete all intermediate=20
transactions, it will show as though transactions occurred from the=20
Genesis block directly to the pruned block, as though nothing ever=20
existed in between. This will be described below in more detail.<br><br>You
 can keep the old blocks on your drive for 10 more blocks or so, just in
 case a longer block chain is found, but other than that the information
 it holds is useless, since it has all been agreed upon. And the pruning
 block holds all up to date account balances, so cheating is impossible.<br=
><br>Granted
 this pruning block can get extremely large in the future, it will not=20
be the regular size of the other blocks. For example if every account=20
has only 1 satoshi in it, which is the minimum, then the amount of=20
accounts will be at its maximum. Considering a transaction is about=20
256bytes. That would mean the pruning block would be approximately=20
500PB, which is 500,000 Terra-bytes. That is a theoretical scenario,=20
which is not likely to occur. (256bytes*21M BTC*100M (satoshis in 1=20
BTC))<br><br>A scenario which could be solved by creating a minimum=20
transaction fee of=C2=A0 for example: 100 satoshis, which would insure that=
=20
even in the most unlikely scenario, at worst the pruning block would be=20
5PB in size.<br>Which is still extremely large for today. But without=20
implementing this idea the blockchain literally does not have a finite=20
maximum size, and over time approaches infinity!<br><br><b>Also, this=20
pruning block does not even need to be downloaded, it could be created=20
by already existing information, each full node by itself, by: </b><br>1) c=
ombining and pruning all previous blocks <br>2) using the genesis block as =
its hash pointer <br>3)
 using a predefined random number &quot;2&quot;, which will be used by all.=
 A=20
random number which is normally added to a block to ensure the block&#39;s=
=20
hash-rate difficulty, is not needed in this case, since all information=20
can be verified by each node by itself through pruning. <br>This number can=
 also be used to identify this block as the Pruned/Combined Block since it =
is static.<br>4)
 Any other information which is needed for the SHA256 hash, for example a
 time-stamp could be copied off the last block in the block chain. <br>Thes=
e steps will ensure each full node, will get the exact hash code as the oth=
ers have gotten for this pruning block.<br><br>And as I previously stated t=
he next block will use this hash code as its hash reference.<br>By
 creating a system like this, the pruning block does not have to be=20
created last minute, but gradually over time, every time a new block=20
comes in, and only when the last block arrives (block 1000), will it be=20
finalized, and hashed.<br>And since this block will always be second, it sh=
ould go by the name &quot;Exodus Block&quot;.<br><br>Above,
 I showed a way to minimize the blocks on the block chain, to lower the=20
amount of space it takes on the hard drive, without losing any relevant=20
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 (Key Pair):</b><br>-------------=
--------------------------------------<br>The
 problem with changing the transaction and block chain, is that it=20
cannot be done without knowing the private key of the sender of the of=20
the funds for each account. <br>To illustrate the problem: If we have a=20
series of block chains with a string of transactions that are A=E2=86=92B=
=E2=86=92C=E2=86=92D,=20
and to simplify the problem, all money was sent during each transaction,
 so that no money is left in A or B or C. And I was to prune these=20
transactions, by replacing them with A=E2=86=92D. Only this transaction nev=
er=20
occurred, nor can anyone create it without A=E2=80=99s private key.<br>Ther=
e is=20
however a way to circumvent that problem. That is to create a special=20
account called the =E2=80=9CGenesis Account=E2=80=9D, this account=E2=80=99=
s Private Key and=20
Public Key will be available to everyone.<br>(Of course, accounts do not re=
ally exist in Bitcoin, when I say account what I really mean is a Private/P=
ublic Key pair)<br>This account will be the source of all funds<br>But
 this account will not be able to send or receive any funds in a normal=20
block, it will be blocked--blacklisted. So no one can intentionally use=20
it. The only time this account will be used is in the pruning block,=20
a.k.a Exodus Block.<br>When creating the new pruned block chain and=20
transaction chain, all the funds that are now in accounts must be=20
legitimate, and it would be difficult to legitimize them unless they=20
were sent from a legitimate private key, which can be verified. That is=20
where the Genesis account comes in. All funds in the Exodus Block will=20
show as though they originated and were sent with the Genesis=20
private-key to generate each transaction.<br>The funds which are sent, must=
 match exactly the funds existing in the most updated ledger in block 1000.=
<br>In
 this way the Exodus Block can be verified, and the Genesis Account=20
cannot give free money to anyway, because if someone tried to, it would=20
fail verification.<br><br>Now the next problem is that the number of=20
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=20
the account which is mining the coins, and it will be the only account=20
in the Exodus Block which =E2=80=9Cmines=E2=80=9D the coins, and receives t=
he mining=20
bonus. In the Exodus Block all coins mined by the real miners will show=20
as though they were mined by Genesis and sent to the miners through a=20
regular transaction.<br><br>I hope this proposal will be implemented as=20
soon as possible so that we can avoid a problem which is growing by the=20
minute. It was brought up about 6 years ago when the blockchain was only
 1GB in size, nobody imagined back then that it would grow so quickly,=20
and the problem was ignored.<br>Today all solutions implemented have=20
been implemented by software, and not on the blockchain itself, these=20
solutions are not helpful in the long run.<br><br>The full node needs to
 be publicly available to everyone, and at this rate, nobody will have=20
the hard-drive capacity to store. This will make us more dependent on=20
private corporation=E2=80=99s to store the blockchain, which will lead us=
=20
quickly to a centralized currency platform. By then it will be too late,
 and the corporations will have complete control of what happens next. <br>=
Please take this problem seriously and work with me, to prevent it while we=
 still have some time.<br>The
 exact details can be worked out at a later time, but for now we need at
 least an acknowledgment that this problem is dire, and needs to be=20
solved in a year=E2=80=99s time. I have presented a solution, if someone ha=
s a=20
better one, then let him/her step forward, but in any case a solution=20
needs to be implemented as soon as possible.<br><br><b>I have given a=20
basic proposal, I am sure there are those among us with more technical=20
understanding to the nuances of how this idea should be implemented. I=20
am counting on their help to see this through.</b><br><br>Adam Shem-Tov<br>=
<br></p></div>

--f403045fa58e0a5e450557b4578b--