From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4C0B640A for ; Sun, 27 Aug 2017 05:18:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail001.aei.ca (mail001.aei.ca [206.123.6.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19F94A1 for ; Sun, 27 Aug 2017 05:18:41 +0000 (UTC) Received: (qmail 25279 invoked by uid 89); 27 Aug 2017 05:18:41 -0000 Received: by simscan 1.2.0 ppid: 25273, pid: 25277, t: 0.0042s scanners: regex: 1.2.0 attach: 1.2.0 Received: from mail002.aei.ca (HELO mail002.contact.net) (206.123.6.132) by mail001.aei.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Aug 2017 05:18:41 -0000 Received: (qmail 7365 invoked by uid 89); 27 Aug 2017 05:18:41 -0000 Received: by simscan 1.2.0 ppid: 7338, pid: 7340, t: 8.7234s scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD autolearn=disabled version=3.3.1 Received: from dsl-66-36-135-64.mtl.aei.ca (HELO ?192.168.67.200?) (dermoth@66.36.135.64) by mail.aei.ca with ESMTPA; 27 Aug 2017 05:18:32 -0000 To: Adam Tamir Shem-Tov References: From: Thomas Guyot-Sionnest 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 27 Aug 2017 11:48:44 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 05:18:43 -0000 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.