An idea to solve the big block size problem

HelloGuy

Member
Mar 16, 2016
42
20
I want to run a full node on VPS, with all the full history of block data stored and let other nodes who needs the full data to download.

If the block size increases and the throughput of Bitcoin increase, the resources required to run a full node is increasing.

1. RAM, >2GB will be better, as it will be able to store the unspent output in the memory, and the memopool for unconfirmed transactions.

2. Large disk spaces

3. Fast CPU.

Among them, the RAM and CPU is quite expense, while at the same time we can easily find cheap disk spaces service.

for example, the digitalocean.com provides very stable VPS service, even during the DDoS attacking against the classic nodes, my full nodes on the digitalocean is not down. but you can see the pricing table of digitalocean. If you want to run a 160GB vps, it will be very expensive:

https://www.digitalocean.com/pricing/

The problem here is that we don't need an 8-core & 16GB RAM server to run the full node. What we need is 2-core & 2GB memory, with very large disk spaces to be prepared for the big block.

While the same time, there is lots of server on the market which has very large disk space and large bandwidth but low RAM.

I think we should combine these two kind of VPS service together, to have a solution to let volunteers who want to provide full block history seeding. The "front end" will run VPS has 2-4GB RAM VPS which shall be very stable on the DDoS attacking and has fast SSD/CPU resources, storing the pruned data, unspent outputs, most recent blocks, etc; and majority of the blockchain data stored on a "back end" VPS which has 1GB RAM and 500GB HDD spaces, or even seedbox service. like http://seedstorm.com/metered-seedbox-plans.php
 
Last edited:
  • Like
Reactions: freetrader

HelloGuy

Member
Mar 16, 2016
42
20
If anyone can provide the code, and is merged into Classic or Core or Unlimited, I will provide 2 Bitcoin bounty.
 
  • Like
Reactions: freetrader

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
I think that nodes will partition by use case and you have identified one partition -- nodes that server the "history" slowly, vs nodes that serve the "now" quickly.

You seem to want to hide this difference underneath the client layer so that all nodes seem equal. Why not expose it?

Today, you can run in "blocks-only" mode to implement your history server. And run in "pruned" mode to implement your "now" server... (disclaimer, I haven't tried this).
 
  • Like
Reactions: sickpig

sickpig

Active Member
Aug 28, 2015
926
2,541