summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Guyot-Sionnest <dermoth@aei.ca>2017-08-27 01:18:32 -0400
committerbitcoindev <bitcoindev@gnusha.org>2017-08-27 05:18:43 +0000
commit8c18bd4bf2632029ae394b5fa91462cde1ee3750 (patch)
tree8fbdc8eddabedae9bbb3c1ab1dbeba00c7dafb8e
parent772013de4dc84105c246e68af88e000908bbf219 (diff)
downloadpi-bitcoindev-8c18bd4bf2632029ae394b5fa91462cde1ee3750.tar.gz
pi-bitcoindev-8c18bd4bf2632029ae394b5fa91462cde1ee3750.zip
Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
-rw-r--r--b0/ed1fc8f25d54ee1868318ee5dfcf9433d2bf76117
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.
+
+
+