Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-24 📝 Original message:Peter, it’s a work in ...
đź“… Original date posted:2015-07-24
📝 Original message:Peter, it’s a work in evolution, it’s not complete yet. It’s still missing a bunch of stuff - please feel free to contribute.
> On Jul 24, 2015, at 1:28 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>>
>> On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/0e2bcbdf/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/0e2bcbdf/attachment.sig>;
📝 Original message:Peter, it’s a work in evolution, it’s not complete yet. It’s still missing a bunch of stuff - please feel free to contribute.
> On Jul 24, 2015, at 1:28 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>>
>> On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/0e2bcbdf/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/0e2bcbdf/attachment.sig>;