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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
Return-Path: <mbtc-dev@xe0.me>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B398149B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2017 16:32:39 +0000 (UTC)
X-Greylist: delayed 00:08:24 by SQLgrey-1.7.6
Received: from m.emmx.me (m.emmx.me [106.187.39.224])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6F55D14E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Feb 2017 16:32:38 +0000 (UTC)
Received: from localhost (m.emmx.me [127.0.0.1])
by m.emmx.me (Postfix) with ESMTP id 98E9D11A00B;
Tue, 7 Feb 2017 01:24:13 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xe0.me; h=
message-id:references:in-reply-to:subject:subject:to:from:from
:date:date:content-transfer-encoding:content-type:content-type
:mime-version; s=dkim; t=1486398251; x=1487262252; bh=lDznkHNh+W
Q99jefHKd8fKVxL2fjJi2lhclML5I+iKU=; b=Vp31Td6lqYbcpBO+8M1Gu80T6p
qTLJddS756Fsb3+FGCCimmqcMNPSasZbzOwuLRig5lhfiHRvGksMlyJUI1wqUDsr
249qJGGFosQ32ElsaHATBJR2rC21G3/rGCVJwvy68GczZK64AiPQNQ+DUJLZvDZb
d2L7xVzu22AhINCqm49ZfTJd7r09/mFuS+bAKc7tiJq6DoeU3yzHLdnjjo4g1ykc
DvgRJVqZEozfQBkHh8RDaSwDP3Bd7hVKVpcAzCqMmmC2CCXyxUoyUyo2s2Zb8eo8
xzK4G/ZP0DZASnPa5w+F9YOxiUmk9//3Q71JZywafqFZB6qnJpOAvrzWYYvQ==
X-Virus-Scanned: Heimdallr with amavisd-new at emmx.me
Received: from m.emmx.me ([127.0.0.1])
by localhost (m.emmx.me [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id JNeMQlXCKjwu; Tue, 7 Feb 2017 01:24:11 +0900 (JST)
Received: from localhost (m.emmx.me [127.0.0.1])
by m.emmx.me (Postfix) with ESMTP id F32BC11A009;
Tue, 7 Feb 2017 01:24:10 +0900 (JST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 06 Feb 2017 08:24:10 -0800
From: mbtc-dev@xe0.me
To: Luke Dashjr <luke@dashjr.org>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <201701280403.05558.luke@dashjr.org>
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
<201701280403.05558.luke@dashjr.org>
Message-ID: <af8301fc246c8c3fae857167968d94d4@xe0.me>
X-Sender: mbtc-dev@xe0.me
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 07 Feb 2017 08:56:57 +0000
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: Mon, 06 Feb 2017 16:32:39 -0000
On 27.01.2017 20:03, Luke Dashjr via bitcoin-dev wrote:
> 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.
>
Lets think like people in sales and marketing for a moment.
There's an implicit assumption here that ANY protocol or consensus-rule
based solution exists that would reverse the trend of diminishing full
node verified economic activity. Since there's no economic advantage to
running a full node, there's no inherent motivation for implementation
(or outright purchase) of full nodes by the very large percentage of
people who fall in the non-technical "I just want it to work, and I
don't want my money stolen" category. Yes, anyone on this list
understands that "don't want my money stolen" is inherently connected to
running your own node and using it for transactions, but the average
user does not, and even if they did, they don't have the resources (time
and/or money) to do anything about it. Running your own full node
increases the protection agains double spend attacks and other protocol
bases shenanigans, but now you've taken on another set of security
exposures related to the physical box that is running the node.
Anti-virus, off and on-site backups, multiple boxes/devices for
multi-sig, backup of key seeds.
Reducing (or even maintaining) the block size doesn't somehow increase
the number of people who are capable of running full nodes, and it
doesn't add any incentive for people already in that "capable" set to
suddenly take up the task of running and transacting via a full node.
I'd argue that the size of the block-chain and the time to download it
are the least concerning aspects to anyone faced with running their own
node and actually storing some of their wealth on it and using it for
transactions.
You're looking for a (maybe dangerous/maybe impossible) balance between
choking off casual (not full node) usage of bitcoin and yet trying to
make it more popular among the people (and organizations) who have the
capability and resources to run and transact on full nodes.
We should sit with this for a moment.
On one hand, Bitcoin may ultimately end up as digital currency "only for
geeks and B2B transactions." I'd speculate we'd loose a big subset of
the geeks that way too, unless they happen to do a lot of transactions
with medium to large size businesses. (Small businesses won't be able to
afford the expense of or the time to maintain the node.) There's some
level of risk that this pushes bitcoin into oblivion. And is it really a
decentralized P2P currency if it's only used by medium and large
businesses and a small set of technically capable individuals that
transact with those entities directly in BTC? And is it really a
decentralized currency in this scenario if its used mainly by medium and
large businesses, banks, and exchanges? (I've purposely excluded small
businesses because while they like the benefits of flexible payment
systems, more don't have the time or skill (or resources to hire the
skill) needed to do a full node implementation.)
I feel inherent cognitive dissonance between "keep it decentralized" and
"not useful to small business and individuals." One can make the
argument that L2 solutions will be available for the small businesses
and individuals but that doesn't solve the stated intent of reversing
the trend of transactions not originating from or being received by full
nodes. I guess you're saying bitcoin will be stronger, more resistant to
outside power agency and censorship if its only used by exchanges,
banks, large businesses, and die-hard technically inclined people.
On the other hand, maybe there's a scenario where an average person
walks into a big box electronics store in any developed country and buys
a "personal digital bank" appliance. I frame it this way because the
majority of the worlds population is never going to run a full node on
their desktop or laptop. There's no viable scenario where that happens.
Laptops and desktops are already diminishing in market share due to the
introduction of tablets and smartphones. General purpose OS's are also
inherently un-secure, so going down this route means we are immediately
in the realm of lots of theft. Preventing theft (or loss due to errors)
requires additional digital key devices, or additional devices for
multi-sig transactions just for basic financial safety, not to mention a
functioning backup plan, including off-site backups.
Ransomeware/phishing protection? Checking email and surfing the web on
the computer that holds your standard (non-multi-sig) wallet?
Forgetaboutit. It'll never reach critical mass. It's not a viable
proposal. Not to mention, you can't physically carry your laptop with
you when you go to the shopping mall. In order for this appliance model
to function, smartphone based implementations will need to interact with
your personal or family server/appliance, and you'll need to be able to
do multi-sig with a smartphone and another physical token you carry with
you. Imagine a 2 of 5 multi-sig wallet where your phone and an NFC or LE
bluetooth device are sufficient to create a transaction on your home
node while shopping. Or your phone has a single sig wallet and you top
it up from your appliance and it never has a high balance. In any case,
I've made the argument before that the definition of "bitcoin protocol"
should, in addition to the consensus protocol, probably include a secure
API protocol between wallet client and full node, and it still seems to
be an important missing piece. I want to be able to travel and spend BTC
and I DON'T want to do general purpose computing like email and web
surfing on the same computer where I have a big chunk of life savings
stored! I think defining this API will actually really support the use
of user controlled full nodes for transactions! Imagine Trezor owners
using their own node for transactions! Bitpay is the only player I know
of that provides enough of a software stack to set this up for yourself.
I think reversing the non-full node transaction trend will have to be
based the appliance usage model. You buy a new 200-500Gb nvme SSD every
year and put it in one of the free slots. You upgrade when all slots are
full. This is one scenario that could put us on a trend of increasing
transactions originating and being received by personal full nodes, i.e.
reversing centralization trends.
If there is any solution to this problem, it will need to recognize the
fact that the supermajority of people on the planet are not technically
savvy nor are they inclined to take the time to learn how to protect
themselves with basic computer security much less how to use a full node
for bitcoin transactions. The solution, if it exists, will need to be
handed to them, and they'll need a reason to buy it. Any solution will
also need to recognize the fact that it will cost resources (time and
money) to run a full node. Lots of people spend a huge portion of their
income just to get a smartphone because it's a useful communication
device that does lots of other useful things. There's not nearly the
same level of need to spend on a full node for bitcoin security.
Any solution to this problem should also recognize the fact that there's
a significant amount of work to do to have a functioning personal
implementation of a node and to use it for transactions. Even in my
imagined future of polished and easy to use appliances, if you have
enough capital in BTC that you need it and you can afford to buy it,
you're now only starting to deal with implementation issues. You've now
become your own bank. Now you have to secure that appliance physically,
secure and back up the key seed material, secure the devices used to
access it, connect an app on your smartphone to the appliance so you can
create transactions while out of your home, connect your home
computer(s) to the appliance, do key exchange with the app/PC and the
appliance or implement some sort of PKI on all devices. You've just
taken on the responsibility of a bank and a sysadmin! The higher the
balance, the more of a target you are, and the more time/money you have
to spend mitigating risk. This is a huge centralizing force that no one
really seems to talk about. If you're the average person, you want to
find a trustworthy company or trusted friend/family to take care of that
stuff for you. If you're a technically inclined person AND maybe there's
a way to reap some of the mining reward on a small scale, you're
slightly more interested.
As a sysadmin for many years, I've seen first hand that most people want
tools that just work, whether its software to make spreadsheets,
operating systems, phones, or thermostats. My point here is that the
number of people in the world who have the technical chops to run a node
is ALWAYS going to be vastly lower than the number of people who will be
using bitcoin (or cryptocurrency).
Of course we can make the argument that the definition of "bitcoin" is
by design something to be used exclusively by institutions and geeks,
and that this definition falls out of the necessity to ensure that it
remains decentralized and censorship resistant. However, I'm not sure
that logic holds or that it doesn't introduce risk that that sort of
definition drives bitcoin toward diminished relevance.
At the end of all this though experiment, I'm still convinced that if
the tools are built to enable flexible usage of full nodes (i.e. my
phone, tablet or desktop app interfaces with the full node) then there's
a large potential for increased usage of full nodes.
Thanks,
G
|
