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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C3059905
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 04:04:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 56D8CE1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 04:04:16 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id AD4E438A1799;
Sat, 28 Jan 2017 04:03:06 +0000 (UTC)
X-Hashcash: 1:25:170128:bitcoin-dev@lists.linuxfoundation.org::0HpyN91p+Ne90Bbc:abWT+
X-Hashcash: 1:25:170128:andrew.johnson83@gmail.com::xZXdMEVB1ENIeRMX:cpdFl
X-Hashcash: 1:25:170128:decker.christian@gmail.com::07qfrMpyUydeSbGH:a4xcN
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Andrew Johnson <andrew.johnson83@gmail.com>
Date: Sat, 28 Jan 2017 04:03:03 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.39-gentoo; KDE/4.14.24; x86_64; ; )
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
In-Reply-To: <CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201701280403.05558.luke@dashjr.org>
X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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: Sat, 28 Jan 2017 04:04:16 -0000
On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote:
> I don't think that the 17% yearly increase is too far off base considering
> current global trends(although I still don't particularly like the idea of
> centrally planning the limit, especially not that far into the future), but
> the 66% decrease first seems completely out of touch with reality.
Assume as a premise (despite your apparent disagreement below) that for
Bitcoin to function, a supermajority of economic activity needs to be verified
using full nodes operated by the recipient. Evidence suggests that at this
current time, at best 10% of economic activity is in fact using a full node to
verify the transaction. On this basis, it seems pretty clear that serious
action must be taken to change the status quo, and so for efforts to do so
without dropping the block size have proven ineffective.
> I'd also like to point out to Luke that Satoshi envisioned most full nodes
> running in data centers in the white paper, not every single user needs to
> run a full node to use bitcoin.
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full node security so long as they were
not isolated. But as a matter of fact, this vision has proven impossible, and
there is to date no viable theory on how it might be fixed. As a result, the
only way for nodes to have full-node-security is to actually be a true full
node, and therefore the plan of only having full nodes in datacenters is
simply not realistic without transforming Bitcoin into a centralised system.
> That a lot of people want to continue to move in that direction shouldn't
> be a surprise.
I think it's likely safe to say that if this were a possibility, everyone
would want to continue to move in that direction. But as the facts stand, it
simply isn't possible.
Luke
|
