Wow. Classic-cloud.net is at max capacity [Capacity increased to 1500 nodes]

[arnoudk]

I just opened classic-cloud.net to see how many people are running nodes in the amazon cloud through this service.

Turns out that they are over capacity.

They have limited the number of nodes that can be spun up, probably to stay within the account payment limits of amazon.

I am happy that the ddos is having the exact opposite effect. There have never been so many classic nodes!

[iFixBTCmemoryIssues]

I just opened classic-cloud.net to see how many people are running nodes in the amazon cloud through this service.

Turns out that they are over capacity.

They have limited the number of nodes that can be spun up, probably to stay within the account payment limits of amazon.

I am happy that the ddos is having the exact opposite effect. There have never been so many classic nodes!

Great news for classic!!!!!

[arnoudk]

So 530 nodes are currently running through classic-cloud.net.

They cannot raise the limit until the billing cycle completes. That would be a few weeks probably.

I wonder how much higher it can go before growth stops!

It is just amazing how many nodes can get launched in so short a period of time.

I'm probably going to set up an extra node for a year or so on a non US VPS in the next weeks. Although I think I will go for an Unlimited node that also supports Classic. I really like the extreme thin blocks feature.

[arnoudk]

The capacity for classic-cloud.net has been increased to 1500 nodes now!

So if you want to spin up some more cloud nodes - this is the easiest way to do it.
You can read a bit more about it here: https://www.reddit.com/r/btc/comments/4 ... d_to_1500/

It is quite hard to DDoS the classic cloud

I'm not involved in it in any way, other than I have funded a few nodes on this platform.

I am now synching two extra VPS nodes, and one AWS micro instance is also still synching.

Thanks.

[iFixBTCmemoryIssues]

The capacity for classic-cloud.net has been increased to 1500 nodes now!

So if you want to spin up some more cloud nodes - this is the easiest way to do it.
You can read a bit more about it here: https://www.reddit.com/r/btc/comments/4 ... d_to_1500/

It is quite hard to DDoS the classic cloud

I'm not involved in it in any way, other than I have funded a few nodes on this platform.

I am now synching two extra VPS nodes, and one AWS micro instance is also still synching.

Thanks.

Why can't a 50GB file download in seconds!!!!!!!!!!!!!!

[arnoudk]

Why can't a 50GB file download in seconds!!!!!!!!!!!!!!

It should, if you have the network capacity for that. The bottleneck is in the verification of the signatures in all the transactions, not in the downloading of the data. Although there are some suggestions to improve that further that I am aware of.

I wonder (I have not looked into this) if it is really necessary to verify all the signatures before starting to serve the blockchain. Could a node not assume that the blockchain - lets say 1000 blocks down - is most likely valid because there is so much work done on top of it? It would then only need to verify the block hashes and not the individual signature hashes.

Once downloaded, it could start an additional, low priority, thread to check it anyway. But it should not block using bitcoin. I guess, if you are bitpay, you would want to enable the --force-full-check-anyway flag. But for 99.99% of the users having 1000 blocks of certainty is enough for the first few days of usage.

[iFixBTCmemoryIssues]

Why can't a 50GB file download in seconds!!!!!!!!!!!!!!

It should, if you have the network capacity for that. The bottleneck is in the verification of the signatures in all the transactions, not in the downloading of the data. Although there are some suggestions to improve that further that I am aware of.

I wonder (I have not looked into this) if it is really necessary to verify all the signatures before starting to serve the blockchain. Could a node not assume that the blockchain - lets say 1000 blocks down - is most likely valid because there is so much work done on top of it? It would then only need to verify the block hashes and not the individual signature hashes.

Once downloaded, it could start an additional, low priority, thread to check it anyway. But it should not block using bitcoin. I guess, if you are bitpay, you would want to enable the --force-full-check-anyway flag. But for 99.99% of the users having 1000 blocks of certainty is enough for the first few days of usage.

In this case, I would say that it would depend on the type of application Bitcoin is being used for.

[arnoudk]

In this case, I would say that it would depend on the type of application Bitcoin is being used for.

Absolutely. I referred to BitPay as an example of a company that would not want to do this.

For the "average user" (whatever that is!), I think you could use bitcoin safely with the certainty of 1000 valid last blocks. This is the logic of SPV wallets. The software could be pretty certain that the entire blockchain is valid, if the last 1000 blocks are valid and have valid poof of work. Building 1000 fake blocks is expensive. Obviously your node would verify these last 1000 blocks with multiple nodes on the network, so that a Sybil attack would be harder to pull off.

The software could then work backwards, from block 1001 from the top, all the way to the genesis block. The further down, and the more valid proof of work and valid transactions, the more certainty you have that everything is kosher.

This validation does not need to be done upfront, I don't think, for the majority of users. If it is done in a low priority side thread in the software, it could do this in the background while bitcoin is running and functional. It could display some progress indicator to show what it is doing, but even that would be optional.

I actually quite like this idea. I wonder why it would or would not work.

[ladoga]

25% are full nodes while the rest are pruned nodes storing 10GB of the blockchain · you choose the data center

Technically both pruned and non-pruned nodes are "full nodes". Full comes from fully validating. From 0.12 on pruned node also does block relay of the most recent blocks.

[arnoudk]

25% are full nodes while the rest are pruned nodes storing 10GB of the blockchain · you choose the data center

Technically both pruned and non-pruned nodes are "full nodes". Full comes from fully validating. From 0.12 on pruned node also does block relay of the most recent blocks.

They are fully validating nodes, that is true. But they need their data from other nodes, and do not have the full blockchain.

I'm not sure what the "official" definition is. Do you have some thoughts on that?

In my book, a full node is a node that - if that node is the ONLY one that is available for whatever reason - could serve an unlimited number of new nodes to fully validate a block. A pruned node does not match that definition.

I run full nodes, and pruned nodes. Pruned nodes are great - they help the network and they can be run on smaller VPS machines. They are fully validating, but not full nodes.