From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
Date: Fri, 24 Jul 2015 13:40:39 -0400 [thread overview]
Message-ID: <20150724174039.GA25947@savin.petertodd.org> (raw)
In-Reply-To: <CALqxMTFWfvc7LL5UgOMNnzNCxwbgyGRXgdV7wt1LYGGZ9h4XWw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]
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.
> 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
000000000000000014438a428adfcf4d113a09b87e4a552a1608269ff137ef2d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-07-24 17:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 2:57 Dave Scotese
2015-07-24 3:37 ` Slurms MacKenzie
2015-07-24 11:38 ` Mike Hearn
2015-07-24 14:09 ` Adam Back
2015-07-24 15:22 ` Simon Liu
2015-07-24 17:40 ` Peter Todd [this message]
2015-07-24 20:28 ` Eric Lombrozo
2015-07-24 20:31 ` Eric Lombrozo
2015-07-24 15:08 ` Dave Scotese
2015-07-24 13:39 ` Thomas Zander
2015-07-24 17:43 ` Peter Todd
2015-07-24 20:23 ` Eric Lombrozo
2015-07-24 21:12 ` Slurms MacKenzie
2015-07-24 15:40 ` Milly Bitcoin
2015-07-25 2:23 Dave Scotese
2015-07-25 11:19 ` Slurms MacKenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150724174039.GA25947@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox