diff options
| author | Adam Tamir Shem-Tov <tshachaf@gmail.com> | 2017-08-27 07:09:08 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-08-27 04:09:13 +0000 |
| commit | b7d6dd710054891c1ec4947a258141f62b7a4070 (patch) | |
| tree | 6e7d38136a75034fbfff51ea5015ebe2d9fc4e09 | |
| parent | 8c18bd4bf2632029ae394b5fa91462cde1ee3750 (diff) | |
| download | pi-bitcoindev-b7d6dd710054891c1ec4947a258141f62b7a4070.tar.gz pi-bitcoindev-b7d6dd710054891c1ec4947a258141f62b7a4070.zip | |
[bitcoin-dev] Revised - Solving the Scalability Problem on Bitcoin
| -rw-r--r-- | 73/e352000b97bf26e3e8c3606d3382413ac77b98 | 529 |
1 files changed, 529 insertions, 0 deletions
diff --git a/73/e352000b97bf26e3e8c3606d3382413ac77b98 b/73/e352000b97bf26e3e8c3606d3382413ac77b98 new file mode 100644 index 000000000..bdeee1fa8 --- /dev/null +++ b/73/e352000b97bf26e3e8c3606d3382413ac77b98 @@ -0,0 +1,529 @@ +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 "pruned block"= +;, 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->B =3D 0.8= + BTC and A->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 "2", which will be used by all.= + A=20 +random number which is normally added to a block to ensure the block'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 "Exodus Block".<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-- + |