diff options
author | Thomas Guyot-Sionnest <dermoth@aei.ca> | 2017-08-27 01:18:32 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-08-27 05:18:43 +0000 |
commit | 8c18bd4bf2632029ae394b5fa91462cde1ee3750 (patch) | |
tree | 8fbdc8eddabedae9bbb3c1ab1dbeba00c7dafb8e | |
parent | 772013de4dc84105c246e68af88e000908bbf219 (diff) | |
download | pi-bitcoindev-8c18bd4bf2632029ae394b5fa91462cde1ee3750.tar.gz pi-bitcoindev-8c18bd4bf2632029ae394b5fa91462cde1ee3750.zip |
Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
-rw-r--r-- | b0/ed1fc8f25d54ee1868318ee5dfcf9433d2bf76 | 117 |
1 files changed, 117 insertions, 0 deletions
diff --git a/b0/ed1fc8f25d54ee1868318ee5dfcf9433d2bf76 b/b0/ed1fc8f25d54ee1868318ee5dfcf9433d2bf76 new file mode 100644 index 000000000..9d5e6c402 --- /dev/null +++ b/b0/ed1fc8f25d54ee1868318ee5dfcf9433d2bf76 @@ -0,0 +1,117 @@ +Return-Path: <dermoth@aei.ca> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 4C0B640A + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <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 +X-Mailman-Approved-At: Sun, 27 Aug 2017 11:48:44 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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. + + + |