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, 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 outputs needed to verify early transactions will all be in the pruning block. The only information you lose are of the intermediate transactions, not the final ones the community has already accepted. For example:
A = 2.3 BTC, B=0, C=1.4. (Block 1)
If A sends 2.3 BTC to B. (Block 2)
And then B sends 1.5 to C. (Block 3)
The pruning block will report:
B = 0.8 and C=2.9.
The rest of the information you lose, is irrelevant. No one needs to know that A even existed since it is now empty, nor do they need to know how much B and C had previously, only what they have now.
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.

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*23M BTC*100M (satoshis in 1 BTC))
A scenario which could be solved by creating a minimum transaction fee of 100 satoshis, which would insure that even in the most unlikely scenario, at worst the pruning block would be 5PB in size.
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 hashrate difficulty, is not needed in this case, since all information can be verified by each node by itself through pruning.
4) Any other information which is needed for the SHA256 hash, for example a timestamp 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".
Adam Shem-Tov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshachaf at gmail.com Sat Aug 26 21:01:56 2017 From: tshachaf at gmail.com (Adam Tamir Shem-Tov) Date: Sun, 27 Aug 2017 00:01:56 +0300 Subject: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov Message-ID: Solving the Scalability Problem Part II --------------------------------------------------------------------
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.
Here is how that would work:
The Genesis Account: -----------------------------------------
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.
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 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.
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).
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 ?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.
Adam Shem-Tov -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Sat Aug 26 21:31:11 2017 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 26 Aug 2017 17:31:11 -0400 Subject: [bitcoin-dev] Solving the Scalability Problem on Bitcoin In-Reply-To: References: Message-ID: Pruning is already implemented in the nodes... Once enabled only unspent inputs and most recent blocks are kept. IIRC there was also a proposal to include UTXO in some blocks for SPV clients to use, but that would be additional to the blockchain data. Implementing your solution is impossible because there is no way to determine authenticity of the blockchain mid way. The proof that a block hash leads to the genesis block is also a proof of all the work that's been spent on it (the years of hashing). At the very least we'd have to keep all blocks until a hard-coded checkpoint in the code, which also means that as nodes upgrades and prune more blocks older nodes will have difficulty syncing the blockchain. Finally it's not just the addresses and balance you need to save, but also each unspent output block number, tx position and script that are required for validation on input. That's a lot of data that you're suggesting to save every 1000 blocks (and why 1000?), and as said earlier it doesn't even guarantee you can drop older blocks. I'm not even going into the details of making it work (hard fork, large block sync/verification issues, possible attack vectors opened by this...) What is wrong with the current implementation of node pruning that you are trying to solve? -- Thomas On 26/08/17 03:21 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote: > > Solving the Scalability issue for bitcoin
> > 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, 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Sat Aug 26 21:41:34 2017 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 26 Aug 2017 17:41:34 -0400 Subject: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov In-Reply-To: References: Message-ID: <57de4421-0162-67c5-8905-10f6b477644c@aei.ca> 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: > > Solving the Scalability Problem Part II > -------------------------------------------------------------------- >
> 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.
> Here is how that would work:
> The Genesis Account: > -----------------------------------------
> 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.
> 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 > 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.
> 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).
> 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 ?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. > >
> > Adam Shem-Tov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From criley at gmail.com Sat Aug 26 21:42:16 2017 From: criley at gmail.com (Christian Riley) Date: Sat, 26 Aug 2017 17:42:16 -0400 Subject: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov In-Reply-To: References: Message-ID: There have been a number of similar (identical?) proposals over the years, some were discussed in these threads: https://bitcointalk.org/index.php?topic=56226.0 https://bitcointalk.org/index.php?topic=505.0 https://bitcointalk.org/index.php?topic=473.0 https://bitcointalk.org/index.php?topic=52859.0 https://bitcointalk.org/index.php?topic=12376.0 https://bitcointalk.org/index.php?topic=74559.15 > On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote: > > Solving the Scalability Problem Part II > -------------------------------------------------------------------- >
> 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.
> Here is how that would work:
> The Genesis Account: > -----------------------------------------
> 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.
> 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 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.
> 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).
> 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 ?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. >
> 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.
> Here is how that would work:
> The Genesis Account: > -----------------------------------------
> 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.
> 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 > 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.
> 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).
> 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 ?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. > >
> > 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, 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 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.
>> Here is how that would work:
>> The Genesis Account: >> -----------------------------------------
>> 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.
>> 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 >> 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.
>> 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).
>> 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 ?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. >> >>
>> >> 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, 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.. >> >>