From: Eric Lombrozo <elombrozo@gmail.com>
To: Peter Todd <pete@petertodd.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:28:28 -0700 [thread overview]
Message-ID: <79149E7A-0357-448D-BE59-BF1FC46C33BA@gmail.com> (raw)
In-Reply-To: <20150724174039.GA25947@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 4316 bytes --]
> 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’s 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’m not sure exactly what pushback you’re 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
> 000000000000000014438a428adfcf4d113a09b87e4a552a1608269ff137ef2d
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2015-07-24 20:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 2:57 [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis 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
2015-07-24 20:28 ` Eric Lombrozo [this message]
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=79149E7A-0357-448D-BE59-BF1FC46C33BA@gmail.com \
--to=elombrozo@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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