summaryrefslogtreecommitdiff
path: root/83/b08368f0e33088788069177185dbf2bd18497e
blob: 5423c3d6eb8dcd9820e69aa20802c65c88641edd (plain)
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
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 21FA4267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 20:28:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com
	[209.85.214.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67DE016E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 20:28:32 +0000 (UTC)
Received: by obnw1 with SMTP id w1so22671037obn.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 13:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=fM30VFHtZNG0Pw1lynLh6MLckuaj5grG2AqqXsd2SYE=;
	b=QbB+tWfb1vDJmQfMJu53+sTJ1XKdUOBH3xFGZ5Do+kp4bOXzUfAAfKb631hjjDfacw
	tmVTDhl5Nr61+p6SsszC0d5d98t5fCX3jWsS9S3ARhK/TB5KqlqqAbE4sdR5iJZTRIhs
	5XNqhDTW51hjNmgdKqNEJ41t+BuV+xrfBcJKR5iQvtnKiXWaeICqPaF6GTXR7D5Pp+As
	9EtHbXHyk3zaj09rHoFwsl0MKMYUFKuDTDrRMOTMNc6vQ0PTuvwwpHoDUvj/V1ATk6V3
	e+H+s39fxxnmV1pgg6ROw+rbaMHU+IaI3JjssXQgDNsad2NiAQtaB3PPJ5lM/isPx+/t
	0n+w==
X-Received: by 10.182.142.202 with SMTP id ry10mr16862052obb.27.1437769711827; 
	Fri, 24 Jul 2015 13:28:31 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by smtp.gmail.com with ESMTPSA id sx2sm5591203obc.0.2015.07.24.13.28.29
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 24 Jul 2015 13:28:30 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_5D6C91DA-5859-41C4-B90C-C7296B2EAD11";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <20150724174039.GA25947@savin.petertodd.org>
Date: Fri, 24 Jul 2015 13:28:28 -0700
Message-Id: <79149E7A-0357-448D-BE59-BF1FC46C33BA@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>
	<CALqxMTFWfvc7LL5UgOMNnzNCxwbgyGRXgdV7wt1LYGGZ9h4XWw@mail.gmail.com>
	<20150724174039.GA25947@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
Cc: bitcoin-dev@lists.linuxfoundation.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 20:28:33 -0000


--Apple-Mail=_5D6C91DA-5859-41C4-B90C-C7296B2EAD11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev =
wrote:
>> (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.
>>=20
>> 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.
>=20
> FWIW, blockchain.info is obviously *not* running a full node as their
> wallet was accepting invalid confirmations on transactions caused by =
the
> recent BIP66 related fork; blockchain.info has $30m in funding.
>=20
> Coinbase also was not running a full node not all that long ago, =
instead
> running a custom Ruby implementation that caused their service to go
> down whenever it forked. (and would have also accepted invalid
> confirmations) I believe right now they're running that implementation
> behind a full node however.
>=20
>> 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!
>=20
> Actually I've been trying to get the CCSS standard to cover full =
nodes,
> and have been getting push-back:
>=20
> https://github.com/CryptoConsortium/CCSS/issues/15
>=20
> tl;dr: Running a full node is *not* required by the standard right now
> at any certification level.
>=20
> This is of course completely ridiculous... But I haven't had much much
> time to put into getting that changed so maybe we just need some =
better
> explanations to the others maintaining the standard. That said, if the
> standard stays that way, obviously I'm going to have to ask to have my
> name taken off it.

For the record, there=E2=80=99s pretty much unanimous agreement that =
running a full node should be a requirement at the higher levels of =
certification (if not the lower ones as well). I=E2=80=99m not sure =
exactly what pushback you=E2=80=99re referring to.


>> 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.
>=20
> I would point out that lack of understanding of how Bitcoin works, as
> well as a lack of understanding of security engineering in general, is
> probably a significant contributor to these problems. Furthermore
> Bitcoin and cryptocurrencies in general are still small enough that =
many
> forseeable low probability but high impact events haven't happened,
> making it difficult to explain to non-technical stakeholders why they
> should be listening to experts rather than charlatans and fools.
>=20
> After a few major centralization related failures have occured, we'll
> have an easier job here. Unfortunately there's also a good chance we
> only get one shot at this due to how easy it is to kill PoW systems at
> birth...
>=20
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000014438a428adfcf4d113a09b87e4a552a1608269ff137ef2d
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_5D6C91DA-5859-41C4-B90C-C7296B2EAD11
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVsp/sAAoJEJNAI64YFENU00oP+wYSPYqHeIlGFwtlt155SDur
0D4v4NLRHOaUkrKR6/AdDkGIMehhyHqtR1lwH4Y6qYOSN/VOeapn5AWEGVXY2/CC
c5edmFwRal9zqvDDqkZGrP+jtjJ0StO5t0YU5E8hmyJ6aleQFrkz7XamGU/o2R0b
YCXDBC9qkWKLk3tAbr4Ayo6yafxm4U24rnMbTfO2VPgWPA6xt5OS9vefgoyc6ohu
77nlkDw8FsZ/xiX5JVJMNYVIAEJPLr/OfARBOoUeYvv3IUhQn5wBc8ARPhhMop/3
oW3O49WtqRZ1zpvf0Dd7o2bVFQQl9xfBZcz5rnmKzk8Y9atfGSGBOauLoxphF/BP
ZyWY5SRKwlwKaHJR9BisvWbxOaXNNAI5cqgL1zpF+AipkKLF27lvly2PTYktPPf6
VVvTfriTn8vgE8Fl3CiMl573n1FnljX1TKuIKxIy95JcEmfHWze5LdZMKgRbQtUq
CYVy9Lv7Fm6znrcRlNpUr355fIgw8f+jcAYjQJaAot571XT7hZji+ZyZDzwQTNH+
fMMUfwJx7FwZAWeCr/PNL9BMCcF9o8R1UxVdRproCVCOCVo5iRTcHMN4LAf/OK5m
bjqCXEAT5DfXPHx0JzfgFx77bh86b4na5PTDl/We8bAwFAkx4lleDSMjfH0tfw3u
asy1qMkS39ZoKjFpGr4A
=bHd2
-----END PGP SIGNATURE-----

--Apple-Mail=_5D6C91DA-5859-41C4-B90C-C7296B2EAD11--