> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
