Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-07-24 š Original message:On Fri, Jul 24, 2015 at ...
š
Original date posted:2015-07-24
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/a3a73338/attachment.sig>;
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/a3a73338/attachment.sig>;