1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
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.
|
