To: Adam Tamir Shem-Tov <tshachaf@gmail.com>
References: <CACQPdjphPmSC7bmicXGytuD3YAXYmsEGOECTTTuLfB_5iqDQGw@mail.gmail.com>
	<a9015271-7f61-7bba-c550-afdd76319b21@aei.ca>
	<CACQPdjoqph7RJhk8Ec8B8SiXixdCQ0VQB5B3+U-1pPxyp=hj4g@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <0dd361fb-8983-44c4-7f14-cd1e43049feb@aei.ca>
Date: Sun, 27 Aug 2017 01:18:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CACQPdjoqph7RJhk8Ec8B8SiXixdCQ0VQB5B3+U-1pPxyp=hj4g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
Precedence: list

How do you trust your <1000 block blockchain if you don't
download/validate the whole thing? (I know it should be easy to spot
that by looking at the blocks/tx or comparing to other nodes, but from a
programmatic point of view this is much harder). You can of course
include a checkpoint in the code to tell which recent block is valid
(which is already done afaik), but you still need all blocks from that
checkpoint to validate the chain (not 10!). If you rely on such
checkpoint, why not just include the UTXO's as well so you can start
mid-way based on code trust?

Indeed pruning doesn't allow you to start mid-way yet but there are much
easier solutions to that than what you propose.

--
Thomas

On 26/08/17 06:32 PM, Adam Tamir Shem-Tov wrote:
> Thank you Thomas for your response.
>
> 1) Implement solution is impossible... I have given a solution in part
> II. By adding a Genesis Account which will be the new sender.
>
> 2)Keeping older blocks: Yes as I said 10 older blocks should be kept,
> that should suffice. I am not locked on that number, if you think
> there is a reason to keep more than that, it is open to debate.
>
> 3) Why 1000? To be honest, that number came off the top of my head.
> These are minor details, the concept must first be accepted, then we
> can work on the minor details.
>
> 4)Finally it's not just the addresses and balance you need to save...=20
> I think the Idea of the Genesis Account, solves this issue.
>
> 5) The problem with node pruning is that it is not standardized, and
> for a new node to enter the network and to verify the data, it needs
> to download all data and prune it by itself. This will drastically
> lower the information needed by the full nodes by getting rid of the
> junk.  Currently we are around 140GB, that number is getting bigger
> exponentially, by the number of users and transactions created. It
> could reach a Terrabyte sooner than expected, we need to act now.
>
> On your second email:
> When I say account: I mean private-public key.
> The way bitcoin works, as I understand it, is that the funds are
> verified by showing that they have an origin, this "origin" needs to
> provide a signature, otherwise the transaction won't be accepted.
> If I am proposing to remove all intermediate origins, then the funds
> become untraceable and hence unverifiable. To fix that, a new
> transaction needs to replace old ones. A simplified version: If there
> was a transaction chain A->B->C->D, and I wish to show only A->D, only
> a transaction like that never actually occurred, it would be
> impossible to say that it did without having A's private key, in order
> to sign this transaction. In order to create this transaction, I need
> A's private key. And if I wish this to be publicly implemented I need
> this key to be public, so that any node creating this Exodus Block can
> sign with it. Hence the Genesis Account. And yes, it is not really an
> account.