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 21FA4267 for ; 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 ; Fri, 24 Jul 2015 20:28:32 +0000 (UTC) Received: by obnw1 with SMTP id w1so22671037obn.3 for ; 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 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: <20150724174039.GA25947@savin.petertodd.org> To: Peter Todd 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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--