summaryrefslogtreecommitdiff
path: root/8d/5f92c4f21557e398ae4d78bc30abacc9af6775
blob: 55037001759ec0cef6d8a02bedbfa4f832b0e808 (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
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A9013C8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 17:40:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148108.authsmtp.net (outmail148108.authsmtp.net
	[62.13.148.108])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3203A12A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 17:40:48 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6OHehRl014520;
	Fri, 24 Jul 2015 18:40:43 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6OHed5U057528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 24 Jul 2015 18:40:42 +0100 (BST)
Date: Fri, 24 Jul 2015 13:40:39 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20150724174039.GA25947@savin.petertodd.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition: inline
In-Reply-To: <CALqxMTFWfvc7LL5UgOMNnzNCxwbgyGRXgdV7wt1LYGGZ9h4XWw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 1b6ad98e-322b-11e5-9f75-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdAYUEkAYAgsB AmMbWlxeVF17XWE7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRRp+ fktKV3xycgJDenY+ ZEBgXnYVXRZ8JBJ0
	ShtJFm8EN3phaTUa TUkOcAZJcANIexZF O1F8UScOLwdSbGoL
	FQ4vNDcwO3BTJTpg CisMMVkVQEBDJDk1 SxULBX11RRRYA200
	NVRsC1BUI0tZHkJ6 F1w9WVMePFVwQiRY FkVcGy5CTwAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 17:40:49 -0000


--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

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.

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.

> 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!

Actually I've been trying to get the CCSS standard to cover full nodes,
and have been getting push-back:

https://github.com/CryptoConsortium/CCSS/issues/15

tl;dr: Running a full node is *not* required by the standard right now
at any certification level.

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.

> 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.

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.

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

--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVsniPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNmJhZjIwZTI4OWI1NjNlM2VjNjkzMjAyNzUwODYxNjlh
NDdlOWM1OGQ0YWJmYmEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfug2QgAswwR1Nn9eJNztISwX9yRgUyf
eYVWobJzID2lz9E5Qdqc5wVNXWphCwmMpXlCV+aHgcLrM0x3piWv5YxwuAYCEnxo
Tp/OnNpY/JcXhpDrCfyrWTCAERawDwD2LxiW7PBgjNhRQ3unruAVTIleObyrfsqI
oh7zFhgJfvHEqLMWFizmNedPMBrjaF5lRSECqaYa3NaumRsugavgP2i8D+BDKotM
8x8bkdg5aDfx5XIi54QBMS0g2dPEEkTcadlBHYw5zhWq9iruIEXh5pDCHCeHmgjb
Yo6i7wWCCcRwMBrcGaak2HbTdCx7ShsUbSW+TRDG4tJSbhB+H8HMFC3ubmQN0Q==
=dzOR
-----END PGP SIGNATURE-----

--J2SCkAp4GZ/dPZZf--