From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A9013C8 for ; 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 ; 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 To: Adam Back Message-ID: <20150724174039.GA25947@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--