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 59CD13EE for ; Fri, 24 Jul 2015 20:31:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A0F9173 for ; Fri, 24 Jul 2015 20:31:50 +0000 (UTC) Received: by obnw1 with SMTP id w1so22713784obn.3 for ; Fri, 24 Jul 2015 13:31:49 -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=vfgxTRVaqTvyHizjRo3ofhHTj0OHP/d0kOVAeLCNkoU=; b=b0Qif07hroGqkVikunUYubRar6xKSc//fBjvRQ9GvD2mAc3kS19OzzM7OTXo7X54yb 3Qm2AhEBLQEppw3DXCWIJMzphdZB3+AeWQ7RKq1I5fC2J+tqfc5R6zhDlPyPhyKXzaQn NkY3GjdHzBltaR4Vc1ZV8d07BABvWuTaR61lf1rLvm4/LJZ9dYjnNvrQmgT7pX82IpmD A18GP8aNd1SEQJZZ8TR7SmDXgyl3/nOzRhOwhJSkO/qDLr2Ea74trCAQpA7RKlKqRAzC TJyMKM9coRKqMOzW1O19wHo8BmZAAi1E+IQyOxG6niwoMZAx7jiILJ98+yx+c81suGKy aEyg== X-Received: by 10.60.134.19 with SMTP id pg19mr17544771oeb.12.1437769909614; Fri, 24 Jul 2015 13:31:49 -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 sx2sm5597070obc.0.2015.07.24.13.31.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jul 2015 13:31:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C3349B33-F35B-4C62-8C0A-C0A1176B90C0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: <79149E7A-0357-448D-BE59-BF1FC46C33BA@gmail.com> Date: Fri, 24 Jul 2015 13:31:46 -0700 Message-Id: <081736BF-5DF8-4302-9680-A8395F2498B5@gmail.com> References: <20150724174039.GA25947@savin.petertodd.org> <79149E7A-0357-448D-BE59-BF1FC46C33BA@gmail.com> 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,HTML_MESSAGE,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:31:51 -0000 --Apple-Mail=_C3349B33-F35B-4C62-8C0A-C0A1176B90C0 Content-Type: multipart/alternative; boundary="Apple-Mail=_8C5FC45C-128A-4963-87E5-E41484008EB8" --Apple-Mail=_8C5FC45C-128A-4963-87E5-E41484008EB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Peter, it=E2=80=99s a work in evolution, it=E2=80=99s not complete yet. = It=E2=80=99s still missing a bunch of stuff - please feel free to = contribute. > On Jul 24, 2015, at 1:28 PM, Eric Lombrozo = wrote: >=20 >>=20 >> 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. >=20 > 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. >=20 >=20 >>> 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=_8C5FC45C-128A-4963-87E5-E41484008EB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Peter, it=E2=80=99s a work in evolution, it=E2=80=99s not = complete yet. It=E2=80=99s still missing a bunch of stuff - please feel = free to contribute.

On Jul 24, 2015, at 1:28 PM, = Eric Lombrozo <elombrozo@gmail.com> wrote:


On Jul 24, 2015, at = 10:40 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

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.

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

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

--
'peter'[:-1]@petertodd.org
000000000000000014438a428adfcf4d113a09b87e4a552a1608269ff137ef2= d
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /blockquote>

= --Apple-Mail=_8C5FC45C-128A-4963-87E5-E41484008EB8-- --Apple-Mail=_C3349B33-F35B-4C62-8C0A-C0A1176B90C0 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 iQIcBAEBCgAGBQJVsqCyAAoJEJNAI64YFENUiyEP/iJP+rK42FX0FM1UEaa5FFlo ND/WWbJyPhAXRXaxENnf17z/48TkGyEi6LY45iZZFZBTPmemJJQO0Qans7HmZ/dY VzCWee7T0GLva8Z2NMsgJ4bTBEaCI/ku4GlgNt476Ph/M1yVQaClDsPPIkdYe6zZ z4j+M6tAYCFRnAZBM583cvKV3sceCALhp824FKt4Loie998HLDDsjg4BVLxxWjxX J3c0F154AiCHOLAz6lc3zHW4gWvZhLjJveg006PlMj9pvp7FyCMJptq2KrZsQ+O2 iF/lht4OHG1u36WvARnwb7pzoXZy51fIYwQb538TzIPLiRi8dfNY0NcusruVHSMg BjubPv8+Jw/lTQ4Drtgjsf2zcJjAJv5YApnXGzhDyoH+AbKATIntfGl+2s4Uu1ww LxdYWYyoqaC7pacrsNRmv62wenu5UfHOkygr5687dTO1QYfVqtlibP2YbykvwM1m 9wzWFZeIq7fVRZM/LHYI8N+t3N/ddT41Wmv891Jm+b4znAjwqOr6dXIOfCzqA85Y QZP89QHVJv4L9Sp4S0WBC1o7VWje3IxnrAheALZ1QJ57bUUMFDebtnYF4PLeI2za R1OlI9wTm+kXx/IC3y704Q9XFuePrkq0knpvK79fjI67trIYWLHR74c1PfvEAhC3 v7tNSxKMdtji8pJIq2OI =xuLX -----END PGP SIGNATURE----- --Apple-Mail=_C3349B33-F35B-4C62-8C0A-C0A1176B90C0--