Regarding storage space, have you heard about pruning? Probably you should.
On 27 Aug 2017 12:27 am, "Adam Tamir Shem-Tov via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thank You Christian for your response. > > https://bitcointalk.org/index.php?topic=473.0 : I dont see the relevance. > https://bitcointalk.org/index.php?topic=52859.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=12376.0 : Same answer as 505.0. > https://bitcointalk.org/index.php?topic=74559.15 : I think his proposal > is 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=56226.0 > <https://bitcointalk.org/index.php?topic=56226.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 <cri...@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=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 < >> 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 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.<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.<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.<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).<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 >> 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. >> >> <BR> >> >> Adam Shem-Tov >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev