Re: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov

["Jorge Timón" <jtimon@jtimon.cc>]

[-- Attachment #1: Type: text/plain, Size: 5600 bytes --]

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 <criley@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
>
>

[-- Attachment #2: Type: text/html, Size: 8967 bytes --]