Block Size Limitations
Now let’s address the problem with scaling the blockchain. At some point there will be a need to increase the block size. But I propose a current solution that could virtually increase the storage of the current 1 Megabyte block by up to 1000 times.
If a Block was hashed and the hash stored in a new transaction OP_RETURN, the Block could be stored anyplace including on unsecured networks. Now if that Block was sufficiently verified the miner would not need to keep anything but the transaction pointing to the block off-chain or in other storage on his computer. Possibly the block could be encrypted with the address of the new transaction as the key and a hash of the encrypted block stored in the transaction OP_RETURN if more security were needed as discussed at http://hlygrail.com.
The OP_RETURN could contain indexing up to 4 billion blocks in 8-bytes. 8-bytes + 32-byte hash code is 40 bytes. If more were needed the OP_RETURN could be increased to 80 bytes with little impact because most of the blocks could be stored off-chain. A better solution would be to just start with another page location for blocks beyond four billion and you could have another four billion blocks before needing another page containing pointers (transactions) pointing to the blocks off chain.
Technically only the transactions holding the hash of the blocks would need to be saved on the miner’s computer. Practically, you would keep several thousand blocks because they are probably the most active. As new blocks are added, new transactions of older blocks could be created and the older block moved to off-chain storage. If a certain old block was being accessed often, the block could be moved back to the miner’s computer until no longer active.
Many copies of the blockchain stored blocks could be stored at many locations privately and public. The HlyGrail algorithm would validate the OP_RETURN hash as a valid block. In fact, special nodes could be set up to serve up queries from the off-chain blocks.
This can be done currently by anyone without changing the current software. Ideally the code would be built into core so that after several hundred blocks a new transaction would be created with the hash and the old block moved to a recognized repository or several repositories. The validity of the off chain block can be check by anyone looking at the transaction pointing to the block and validating the hash in the OP_RETURN then decode with the address and finally compare the original block with the off chain block.
Now only transactions linking to Blocks, recent blocks and active unspent transactions would need to be held in the miner’s computer if all they are doing is pier to pier relay. If they mine, they determine how much of the full blockchain they need in their computer and load the necessary blocks from the repositories. If using repositories, their computer would automatically replace blocks with transactions pointing to blocks as they appear in the repository with sufficient delay to counter double spends.
Originally mentioned and covered by:
HlyGrail Patent / Copyright Number 18hsnexG7KGUBtKgYnCS2Zyg59V5CsBPAt
HlyGrail Patent / Copyright Number 187ckcgWJWfa82mD4nrNLxUChtX5QJCg12