Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]

Incentivize investigations for public consumption.  The people on this list
are the ones who probably care the most.

When I looked up that IP address, the Whois info names "OVH" and "Octave
Klaba" (who founded OVH, according to Wikipedia) as the owner.  "
blockchain.info" appears in the HTML header as retrieved by the
"Anti-Hacker Alliance" (
http://anti-hacker-alliance.com/index.php?details=37.187.136.15).
Blockchain.info itself returns IP addresses managed by CloudFlare whenever
I try it.

On Fri, Jul 24, 2015 at 2:12 PM, Slurms MacKenzie via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> They do not run anything but BitcoinJ (evidenced by them blindly following
> invalid chains), so no proper consensus checking going on here at all.
> Connected to my nodes is a bad peer (doesn’t relay inventory but downloads
> everything) from 37.187.136.15, with the user agent
> /BitcoinJ:0.12SNAPHOT/Satoshi:0.2.0/ which is owned by blockchain.info.
> You can also submit an invalid transaction through their /pushtx interface
> and get a mixture of noise and BitcoinJ error messages out of it as well.
>
> If even the people who have to their claim hundreds of thousands of
> wallets are relying on their security don’t bother running even a single
> node to sanity check against, who are we really going to expect people to
> in the future if the load goes 8x, 16x, 32x higher? Like CoinBase and
> others, these are the companies which are claimed will be the ones
> supporting the network with ludicrous sized blocks because they have a
> financial incentive to.
>
> Well, they don't even do it now when it could be achieved with a $5 VPS.
>
>
> > Sent: Friday, July 24, 2015 at 8:43 PM
> > From: "Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>
> > To: "Thomas Zander" <thomas@thomaszander.se>
> > Cc: bitcoin-dev@lists.linuxfoundation.org
> > Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing"
> Analysis
> > We can test the fact that blockchain.info's wallet and block explorer
> > has behaved in a way consistent with not running a full node - they have
> > shown invalid data that any full node would reject on multiple
> > occasions, most recently invalid confirmations during the BIP66 fork.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3602 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Slurms MacKenzie]

The answer to that is a less illegal than probing other peoples web servers. Up until recently the reverse name lookup for that IP address was markets.blockchain.info, which I resolve when I log incoming connections in an attempt to filter out some abusive clients coming from university connections. 

Other people have noticed these abusive clients too. There’s mentions of other connections running the same version of BitcoinJ coming from sources that appear to be blockchain.info which display similar behavior. A user in #bitcoin-dev was complaining about this client hammering closed ports with connections when they are kicked off. 

http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/02/09#l1423513396.0
 
 
> Sent: Saturday, July 25, 2015 at 4:23 AM
> From: "Dave Scotese via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

> When I looked up that IP address, the Whois info names "OVH" and "Octave Klaba" (who founded OVH, according  to Wikipedia) as the owner.  "blockchain.info[http://blockchain.info]" appears in the HTML header as retrieved by the "Anti-Hacker Alliance" (http://anti-hacker-alliance.com/index.php?details=37.187.136.15[http://anti-hacker-alliance.com/index.php?details=37.187.136.15]).  Blockchain.info itself returns IP addresses managed by CloudFlare whenever I try it.

 

[bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

I used Google to establish that there is not already a post from 2015 that
mentions "roadmap" in the subject line.  Such would be a good skeleton for
anyone new to the list (like me).

1. Increase the 7 Tx per second - by increasing block size.

2. Do something about the trend toward centralization.  This is really two
issues in my mind:
A) Mining is falling to an ever shrinking number of businesses with the
infrastructure to run a datacenter.
B) The protocol as it is will soon make common computing machines
inadequate for running full nodes, and as a result they will not be able to
contribute to the ecosystem in meaningful ways.

Feel free to copy and then remove or alter any of that.

[-- Attachment #2: Type: text/html, Size: 812 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Slurms MacKenzie]

It's worth noting that even massive companies with $30M USD of funding don't run a single Bitcoin Core node, which is somewhat against the general concept people present of companies having an incentive to run their own to protect their own wallet. 


> Sent: Friday, July 24, 2015 at 4:57 AM
> From: "Dave Scotese via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
> 
> B) The protocol as it is will soon make common computing machines inadequate for running full nodes, and as a result they will not be able to contribute to the ecosystem in meaningful ways.

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

>
> It's worth noting that even massive companies with $30M USD of funding
> don't run a single Bitcoin Core node


This has nothing to do with block sizes, and everything to do with Core not
directly providing the services businesses actually want.

The whole "node count is falling because of block sizes" is nothing more
than conjecture presented as fact. The existence of multiple companies who
could easily afford to do this but don't because they perceive it as
valueless should be a wakeup call there.

[-- Attachment #2: Type: text/html, Size: 773 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Adam Back]

(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.

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!

Reducing custody in my opinion should also be an aim eg 2 of 2
multisig + timelock seems like a more prudent approach, transaction
throughput permitting.  Right now exchange volume wouldnt fit on
chain, once bitcoin scaling has improved, perhaps it can.  I am
optimistic that within a year Bitcoin scaling and decentralisation
will look much better with current active work on decentralisation,
layer 2 scaling solutions.  As part of that I could see a modest
blocksize increase to smooth out the transition to layer 2.

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.

What I mean about decentralisation is if decentralisation simple
metrics were in a healthy place, it would be a simple conversation to
make use of bandwidth improvements (in the range of 15%/year per Cisco
numbers) to get more throughput.  I do think flexcap is interesting as
a way to add one more control variable such that we can have
economically validated scaling.  Pushing fees to zero and increasing
centralisation to levels that weaken security with economically weak
payments is probably not desirable.  Without flexcap it seems the next
best thing we can do is rely on miners to balance user utility against
mining revenue, and it seems plausible that they would in extremis but
to my mind there are factors suggesting this could be problematic
incrementally: miners have not often been responsive to editing
defaults, or reacting to security or soft-fork upgrades; miners may
have some conflict of interest of users, eg they could use switching
cost economics to optimise for miner profit at the expense of user
utility, or attack each other in selfish-miner or other variants as
miners are also pitted against each other while being held honest by
economically dependent full nodes.

Adam

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Simon Liu]

Would a 1MB increase to 2MB, as outlined in BIP 102, be considered a
"modest" increase?

On 07/24/2015 07:09 AM, Adam Back via bitcoin-dev wrote:
> I am
> optimistic that within a year Bitcoin scaling and decentralisation
> will look much better with current active work on decentralisation,
> layer 2 scaling solutions.  As part of that I could see a modest
> blocksize increase to smooth out the transition to layer 2.

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Eric Lombrozo]

[-- 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 --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 4617 bytes --]

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@gmail.com> wrote:
> 
>> 
>> 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 #1.2: Type: text/html, Size: 8543 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Fri, Jul 24, 2015 at 4:38 AM, Mike Hearn <hearn@vinumeris.com> wrote:

> It's worth noting that even massive companies with $30M USD of funding
>> don't run a single Bitcoin Core node
>
>
> This has nothing to do with block sizes, and everything to do with Core
> not directly providing the services businesses actually want.
>
> The whole "node count is falling because of block sizes" is nothing more
> than conjecture presented as fact. The existence of multiple companies who
> could easily afford to do this but don't because they perceive it as
> valueless should be a wakeup call there.
>

Regardless of why node count is falling, many people who used to run a full
node stopped doing so.  To mitigate that, their chances of getting
something out of it have to be greater.  What if propagating a valid
transaction generated a small chance of earning a piece of the fee?

[-- Attachment #2: Type: text/html, Size: 1458 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Thomas Zander]

On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
> It's worth noting that even massive companies with $30M USD of funding don't
> run a single Bitcoin Core node,

I assume you mean that they don't have a Bitcoin Core node that is open to 
incoming connections. Since that is the only thing you can actually test, no?

Most companies are still terrified of accepting incoming connections from the 
scary Internet. So I'm not entirely surprised by this conclusion.  I would be 
very surprised if companies don't actually have a node at all.
-- 
Thomas Zander

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote:
> On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
> > It's worth noting that even massive companies with $30M USD of funding don't
> > run a single Bitcoin Core node,
> 
> I assume you mean that they don't have a Bitcoin Core node that is open to 
> incoming connections. Since that is the only thing you can actually test, no?

We can test the fact that blockchain.info's wallet and block explorer
has behaved in a way consistent with not running a full node - they have
shown invalid data that any full node would reject on multiple
occasions, most recently invalid confirmations during the BIP66 fork.

-- 
'peter'[:-1]@petertodd.org
000000000000000006baf20e289b563e3ec69320275086169a47e9c58d4abfba

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 1906 bytes --]

Thanks for bringing up the CCSS, Adam and Peter.

I was actually working on a post inviting everyone in this mailing list to come and participate…but you guys beat me to it. :)

The CCSS is an open standard, born out of the belief that sharing the industry's best practices amongst each other and with the community at large benefits everyone.

To read more about it and how you can contribute, please visit http://blog.cryptoconsortium.org/contributing-to-the-ccss/ <http://blog.cryptoconsortium.org/contributing-to-the-ccss/>

The standard:  https://cryptoconsortium.github.io/CCSS/ <https://cryptoconsortium.github.io/CCSS/>

The github repository: https://github.com/CryptoConsortium/CCSS <https://github.com/CryptoConsortium/CCSS>


- Eric

> On Jul 24, 2015, at 10:43 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote:
>> On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
>>> It's worth noting that even massive companies with $30M USD of funding don't
>>> run a single Bitcoin Core node,
>> 
>> I assume you mean that they don't have a Bitcoin Core node that is open to
>> incoming connections. Since that is the only thing you can actually test, no?
> 
> We can test the fact that blockchain.info's wallet and block explorer
> has behaved in a way consistent with not running a full node - they have
> shown invalid data that any full node would reject on multiple
> occasions, most recently invalid confirmations during the BIP66 fork.
> 
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000006baf20e289b563e3ec69320275086169a47e9c58d4abfba
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 3153 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Slurms MacKenzie]

They do not run anything but BitcoinJ (evidenced by them blindly following invalid chains), so no proper consensus checking going on here at all. Connected to my nodes is a bad peer (doesn’t relay inventory but downloads everything) from 37.187.136.15, with the user agent /BitcoinJ:0.12SNAPHOT/Satoshi:0.2.0/ which is owned by blockchain.info. You can also submit an invalid transaction through their /pushtx interface and get a mixture of noise and BitcoinJ error messages out of it as well. 

If even the people who have to their claim hundreds of thousands of wallets are relying on their security don’t bother running even a single node to sanity check against, who are we really going to expect people to in the future if the load goes 8x, 16x, 32x higher? Like CoinBase and others, these are the companies which are claimed will be the ones supporting the network with ludicrous sized blocks because they have a financial incentive to. 

Well, they don't even do it now when it could be achieved with a $5 VPS. 


> Sent: Friday, July 24, 2015 at 8:43 PM
> From: "Peter Todd via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
> To: "Thomas Zander" <thomas@thomaszander.se>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
> We can test the fact that blockchain.info's wallet and block explorer
> has behaved in a way consistent with not running a full node - they have
> shown invalid data that any full node would reject on multiple
> occasions, most recently invalid confirmations during the BIP66 fork.

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

[Milly Bitcoin]

On 7/23/2015 10:57 PM, Dave Scotese via bitcoin-dev wrote:
> I used Google to establish that there is not already a post from 2015
> that mentions "roadmap" in the subject line.  Such would be a good
> skeleton for anyone new to the list (like me).

Just a point about terminology:

Roadmap - A plan of proposed changed used to meet some sort of goal.  If 
the goal is increased scaling then you list a series of changes that 
need to be done to achieve that goal.

Baseline - That is the "If We Do Nothing" Analysis.  Each proposed 
change will generally have one or more alternatives which are compared 
to the "baseline."

those would be 2 different documents.

Russ