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
118
119
120
121
122
123
124
125
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D13BD407
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 14:09:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7EA61DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 14:09:14 +0000 (UTC)
Received: from mail-qg0-f54.google.com ([209.85.192.54]) by mrelay.perfora.net
(mreueus001) with ESMTPSA (Nemesis) id 0MAvmU-1ZAyAH40U0-009xtU for
<bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 16:09:14 +0200
Received: by qged69 with SMTP id d69so11095688qge.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jul 2015 07:09:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.96.80 with SMTP id j74mr1708807qge.43.1437746953341;
Fri, 24 Jul 2015 07:09:13 -0700 (PDT)
Received: by 10.96.226.68 with HTTP; Fri, 24 Jul 2015 07:09:13 -0700 (PDT)
In-Reply-To: <CA+w+GKS91NWB9ffysD4qEvAm+r1PswMePq6dirshbcZzpFg6Cg@mail.gmail.com>
References: <CAGLBAhepXCaChSBsz49YNnLOOpiy9nsNYqNv0NH+G3W=17=2yA@mail.gmail.com>
<trinity-44986062-638d-4c20-a1f8-56a7c7cec648-1437709050654@3capp-mailcom-bs10>
<CA+w+GKS91NWB9ffysD4qEvAm+r1PswMePq6dirshbcZzpFg6Cg@mail.gmail.com>
Date: Fri, 24 Jul 2015 07:09:13 -0700
Message-ID: <CALqxMTFWfvc7LL5UgOMNnzNCxwbgyGRXgdV7wt1LYGGZ9h4XWw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:yKrAO5+0WbUw4f6ofK/eis8raVL9h8oyD1LHesXDyNHDIObyn7G
qn+fhzj+Sro5/0PaCN9b0bQA8hPZy4b13CegqP5D768ubZZ10Mcz81bVcPfQIqJwlP77t65
oaoGgiulXqDebMT3x9UeSyZwHHqSlZEfzamvosOIo+rTHQnZG7tvDDrTfyFsIYf1FxnBYdW
u7EULlykdSGvZxZNnLHwg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Z9+5JMrNPIo=:PT76fviYmE2E001yIKe7Hf
98+CK9tdL886m1HGrCC26FXzrBXfAK7EysRi7rK6W1Sw9M7szVwDV8LuM57z0wvurwCTH13DZ
Ff+mLsWM74UdGH/NFSi8e00X3W0UDIZNTMl8HxLfRdQmUF+d2mOcVaH+wGZI+1tBoe4V1z7hS
/9R1BWgshDkghFIYwQXigiDhzrYNKUOd3tz8/XdJUIJh6e6x1XDxt05BVLzVAAqNDY+XnUlPv
V8AxohIGdwaPZkZIrgQS4PsLQ7a9Z+aJTwao+Mfa4FzyzxeRuvsLEUlDWtbGG2zTnfJHlTsS3
hpfZeGvqj3VeezdtOPczKeaQmYmRHAMLK7MTgb3drrWL0mWGMJ12ZwzJ4qsZWOX/7dHdmg44X
Bf2ZFc7Z2zPe0NpXlxUOqDOIlIkasG1DHKNBWkKgn+Mp5sh6ft1L7MYNotXYEZFzocKXNyQ1F
yw1ZUc/6y1mO7eb7QAY7NwL8rEL5LAS/x4Hrb8r/ClEzBz+wjXPRO3hNOgk72pwlHo6xMKClI
4hyK4RmrTENSlQPrcPnf41aaAF52q5BZDFdff+5qRGUPEqi2Z44cguFDrKDvUpwA2NKQHmMER
Hh5bcYq/zAOAzZjFiy5EkE+QA9TY2BIEuxgLtPMqaqZjJhqEKVVk0HaDYY2Q2YMxtzQ73d+eu
zlbhAgEJ7jC7CUbkUYost6B/nBZ62tffrKt1j/bgseUDipg==
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20,LOTS_OF_MONEY,
RCVD_IN_DNSWL_LOW 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] Bitcoin Roadmap 2015,
or "If We Do Nothing" Analysis
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 24 Jul 2015 14:09:16 -0000
(Claim of large bitcoin ecosystem companies without full nodes) this
says to me rather we have a need for education: I run a full node
myself (intermittently), just for my puny collection of bitcoins. If
I ran a business with custody of client funds I'd wake up in a cold
sweat at night about the security and integrity of the companies full
nodes, and reconciliation of client funds against them.
However I'm not sure the claim is accurate ($30m funding and no full
node) but to take the hypothetical that this pattern exists, security
people and architects at such companies must insist on the company
running their own full node to depend on and cross check from
otherwise they would be needlessly putting their client's funds at
risk.
The crypto currency security standards document probably covers
requirement for fullnode somewhere
https://cryptoconsortium.github.io/CCSS/ - we need some kind of basic
minimum bar standard for companies to aim for and this seems like a
reasonable start!
Reducing custody in my opinion should also be an aim eg 2 of 2
multisig + timelock seems like a more prudent approach, transaction
throughput permitting. Right now exchange volume wouldnt fit on
chain, once bitcoin scaling has improved, perhaps it can. I am
optimistic that within a year Bitcoin scaling and decentralisation
will look much better with current active work on decentralisation,
layer 2 scaling solutions. As part of that I could see a modest
blocksize increase to smooth out the transition to layer 2.
In terms of a constructive discussion, I think it's interesting to
talk about the root cause and solutions: decentralisation (more
economically dependent full nodes, lower miner policy centralisation),
more layer 2 work. People interested in scaling, if they havent,
should go read the lightning paper, look at the github and participate
in protocol or code work. I think realistically we can have this
running inside of a year. That significantly changes the dynamic.
Similarly a significant part of mining centralisation is artificial
and work is underway that will improve that.
What I mean about decentralisation is if decentralisation simple
metrics were in a healthy place, it would be a simple conversation to
make use of bandwidth improvements (in the range of 15%/year per Cisco
numbers) to get more throughput. I do think flexcap is interesting as
a way to add one more control variable such that we can have
economically validated scaling. Pushing fees to zero and increasing
centralisation to levels that weaken security with economically weak
payments is probably not desirable. Without flexcap it seems the next
best thing we can do is rely on miners to balance user utility against
mining revenue, and it seems plausible that they would in extremis but
to my mind there are factors suggesting this could be problematic
incrementally: miners have not often been responsive to editing
defaults, or reacting to security or soft-fork upgrades; miners may
have some conflict of interest of users, eg they could use switching
cost economics to optimise for miner profit at the expense of user
utility, or attack each other in selfish-miner or other variants as
miners are also pitted against each other while being held honest by
economically dependent full nodes.
Adam
|
