SSD vs HDD: what it means for Bitcoin scaling?

[maldini]

SSDs are becoming cheaper as years go by, and the storage capacities are also increasing too, so I don't think it'll be much of a problem in the future. But yeah, if the blockchain continues to expand at a rapid pace in terms of size, the miners have to increase their storage capacities as well, and so the cost of mining will effectively increase too. Then again, technological developments on that area isn't stagnating, so I think we're still okay. Just 40 or so years ago, we managed to get by with very little storage spaces compared to what we have today for very important events for Mankind, so we're good, I think.

SSDs will indeed be cheaper with time and also the amount of capacity will be even greater and may even be replaced by new storage technologies such as intel optane or whatever. And with time, bitcoin will continue to grow where the capacity of nodes will be bigger and miners need more storage, but of course miners will not buy storage every day because this enters the depreciation costs of their mining results.

What is clear is that there is no need to worry because in the future technology experts will certainly adjust to existing industrial needs, and of course all will be synchronous as 40 years ago.

[1713306557]

1713306557

[1713306557]

1713306557

[1713306557]

1713306557

[1713306557]

1713306557

[Mike Mayor]

You not quite right. A SSD is a HDD all SSD are HDD but not all HDD are SSD got it?? You first got ata HDD then sata HDD.
SSD means solid state and doesn't move that is why it is so fast. It is like a memory card they are solid state too and have no moving parts and that is why they are fast. Basicall an SSD is a very big much better made and much larger in size version of a memory card like the one you have in your phone.

Gameboy games used to also use solid state and so did n64 and sega and the like.

Running the blockchain on SSD is not very expensive anymore. They use to be very costly but not so much anymore.

[Wind_FURY]

You can prune it if you need the space. Open the bitcoin.conf file and type "prune =" without the quotes, and set it to 5,000 for 5 GB. It will only store 5 GB of the blockchain, prune the rest. But you will still need to sync, and validate the whole 200 GB of data.

Thanks for the suggestion, I totally forgot about it, and I might actually do it in the future. But the problem is that everyone started pruning, it would increase centralization, because few nodes will have the full blockchain and all new nodes will have to rely on them for the initial sync.

Yes and no, and you assume that "everyone" will start pruning. I will tell you that not everyone will start pruning, although archive nodes will decrease as costs of storing the whole blockchain increases.

It centralizes the source of the blockchain for the initial sync, but it's debatable if it centralizes the network, because all full nodes validate.

[franky1]

a full node archives and validates. thats why its called FULL
nodes that prune, filter, strip are not full nodes. they might aswell just be spv nodes

using torrent analogy. a prunned node is a LEACHER not a SEEDER

we should not classify prunned nodes as part of the main full relay network as they dont help the relay network with other nodes needing syncing. same goes for the stripped, filtered, bridged nodes that devs buzzword. (compatible nodes)
the prunned feature should be something only coded into lite nodes as it deceives people into thinking they are still a full node when its included in core. and other nodes that want to sync with other full nodes dont like wasting bandwidth on leachers that then are not going to help the network

as for things about blocksize vs latency/propagation. comparing things to a 2015 1mb block. things have already changed. blockheaders only and other things have made things (as gmax quotes) 88% more efficient on bandwidth. so with 1mb not being an issue in 2015 8mb is not an issue in 2019.
limiting maxsigops down to say 1k would also improve the risk of latency issues for the whole legacy tx sigop debate of 2015

as for SSD vs HDD
people that want $20/tx fee can afford the extra expense of a SSD. so dont play that argument
if someone cant afford $200* every ~4 years for a hard drive. then they should not be part of the same crowd praising for high tx fee's to be a persuasion tactic to deburden bitcoin of utility in favour of other networks.
after all if you think $200 every 4 years is too much then math says making 1-2 transactions a year is too much..
think about how many users will want/need to be a full node if all they could 'afford' was under 2 transactions a year


*8mb legacy block=400gb max buffer per year (2TB SSD =$200)

[Wind_FURY]

a full node archives and validates. thats why its called FULL

I can accept whatever "names" you want to call them.

nodes that prune, filter, strip are not full nodes. they might aswell just be spv nodes

But how can they be SPVs if they fully validate? Validating pruned nodes accept transactions and blocks, validates them, and relays them if they are valid, they are part of the network. SPVs are not, and don't do anything for the network.

[hatshepsut93]

Yes and no, and you assume that "everyone" will start pruning. I will tell you that not everyone will start pruning, although archive nodes will decrease as costs of storing the whole blockchain increases.

It centralizes the source of the blockchain for the initial sync, but it's debatable if it centralizes the network, because all full nodes validate.

I mean, I can imagine a dystopian scenario where there's like a dozen of archival nodes left, they are owned by big companies and they charge a fee for downloading the blockchain, and they can even refuse for political reasons. But this can only happen in big block scenario, if Bitcoin will keep the same blocksize and will only make small increases in the far future, enthusiasts will still be able to run archival nodes.

[coolcoinz]

Yes and no, and you assume that "everyone" will start pruning. I will tell you that not everyone will start pruning, although archive nodes will decrease as costs of storing the whole blockchain increases.

It centralizes the source of the blockchain for the initial sync, but it's debatable if it centralizes the network, because all full nodes validate.

I mean, I can imagine a dystopian scenario where there's like a dozen of archival nodes left, they are owned by big companies and they charge a fee for downloading the blockchain, and they can even refuse for political reasons. But this can only happen in big block scenario, if Bitcoin will keep the same blocksize and will only make small increases in the far future, enthusiasts will still be able to run archival nodes.

The downloading part is what I would be more concerned about. It's really cheap to get enough storage space to hold your own copy, but it can take weeks for your core client to download it. It can take days with a high speed connection, but the majority of the world doesn't have access to it. For many of us 50 or 100 megabit connection is nothing to brag about, but in many countries 2 is all that you will get. Getting a node to run in such conditions, especially with the client messing up the database from time to time, requires a huge effort.

[xWolfx]

Do you know what is the easiest and most effective solution for that problem?

Waiting...And those with talents related to the industry could help working in places that develop the future of data storage, just like humanity didn't stay with those floppy disks or regular cds we shouldn't stay forever using hdds.

Instead of trying to change a technology with a lot of possibilities for the future it's a lot better to work in replacing something that is becoming obsolete.

[hatshepsut93]

The downloading part is what I would be more concerned about. It's really cheap to get enough storage space to hold your own copy, but it can take weeks for your core client to download it. It can take days with a high speed connection, but the majority of the world doesn't have access to it. For many of us 50 or 100 megabit connection is nothing to brag about, but in many countries 2 is all that you will get. Getting a node to run in such conditions, especially with the client messing up the database from time to time, requires a huge effort.

I have 50 Mbps and syncing takes forever, it feels like my connection is not being fully utilized and also peer discovery is slow. Sadly I was too lazy too investigate this issue to find a solution, and eventually I gave up on running a full node altogether. So, even now running a full node is kinda problematic.

[ranochigo]

The downloading part is what I would be more concerned about. It's really cheap to get enough storage space to hold your own copy, but it can take weeks for your core client to download it. It can take days with a high speed connection, but the majority of the world doesn't have access to it. For many of us 50 or 100 megabit connection is nothing to brag about, but in many countries 2 is all that you will get. Getting a node to run in such conditions, especially with the client messing up the database from time to time, requires a huge effort.

Not everyone needs to run a full node; my stand is that if you aren't capable of running a full node, just use a SPV client.

For those who are able to run a node, the internet connection is probably not the main issue. With the current state of Bitcoin, the downloading won't take that long with the simultaneous downloading from the connected nodes. The main limiting factor is probably with the disk speed and the CPU verification speed. In the long term, the disk space is probably the main constraints that we will face. Memory density isn't growing all that fast and the memory space is still fairly expensive.

[franky1]

But how can they be SPVs if they fully validate? Validating pruned nodes accept transactions and blocks, validates them, and relays them if they are valid, they are part of the network. SPVs are not, and don't do anything for the network.

but being prunned also dos not offer a full service for the network. so they dont deserve the title full node. they just leach data without being great at seeding, so there is not much point in starting as a full node if your just gonna prune.

my point is.
from the buzzword games of devs, spv means simple payment verification. there is no set node type. some are webwallets that rely on custodians that then let users re-verify. some leach from the relay network itself, and some are full nodes that then dont archive. but if you want to get more anal about the grey area's.. lets give it 3 categories instead of 2
lite=spv/web/phone app
compatible=is nearly full but misses something(verify(some dont fully verify). archive(prunned, stripped, filtered))
full=verify and archive

from the user function.
if you dont care about seeding other nodes you dont want/need to be a full node, if you only care about your own transactions and not the community collective. then you might aswell just run lite/compatible

[Wind_FURY]

But how can they be SPVs if they fully validate? Validating pruned nodes accept transactions and blocks, validates them, and relays them if they are valid, they are part of the network. SPVs are not, and don't do anything for the network.

but being prunned also dos not offer a full service for the network. so they dont deserve the title full node. they just leach data without being great at seeding,

I agree, pruned validating nodes might be a better way to call them.

so there is not much point in starting as a full node if your just gonna prune.

I disagree, if it fully validates, then it's part if the network, and does its job for the network, pruned or not pruned.

my point is.
from the buzzword games of devs,

Stop the social drama, and the "Core is evil" propaganda.

spv means

Stop. SPVs are not nodes, they don't fully validate, and they should not be in the same debate as full nodes, pruned or an pruned.

[franky1]

I disagree, if it fully validates, then it's part if the network, and does its job for the network, pruned or not pruned.

'fully validating' is a service purely for the user using the node to trust the data it got. its not a 'network' service
'fully archive' is a network service for other nodes to get data for their syncs

a prunned node cannot offer old blocks of say the first 5-9 years of bitcoin, thus useless for network services.
its stuff like prunned being treated like full that gives issues like what 'hatshepsut93' experienced. because even without any hardware or bandwidth withstraints i presume the nodes he was connecting to were not full network service nodes

imagine it like torrents. you see torrents list for a movie that has many users, but. 98% of users have only downloaded the packets for the final 10 minutes of the movie (the credits/casting list) it doesnt matter how fast the intrnet is or hard drive space is. by listing these 98% as seeders means theres only 2% chance of getting the full data.
and if your not keeping an eye on it to cancel download to particular user to then search out a better source. you nd up just waiting for the other user to disconnect themselves before your system rescans for a new source

...
anyway back to the topic of SSD vs HDD
when a system uses a hard drive as its 'virtual memory'/paging file(extended ram utility) then it makes a difference of th read/write speed. but just archiving the blockchain. thats more of a background activity after all the validation stuff is complete thus not really affecting the network propagation. after all a average old 7200rpm hdd is atleast 80mb/s.. blocks are not even 3mb so storing a block which occurs in ~10 minutes, takes less than a second.

so the real limitation is not really ssd vs hd for archiving. but actually ram utility for the validation/UTXO store

[Wind_FURY]

I disagree, if it fully validates, then it's part if the network, and does its job for the network, pruned or not pruned.

'fully validating' is a service purely for the user using the node to trust the data it got. its not a 'network' service
'fully archive' is a network service for other nodes to get data for their syncs

You call it whatever you want, but if the node validates and relays transactions and blocks, and make sure that they are valid, then it is part of the network.

Capable of participating in a UASF.

a prunned node cannot offer old blocks of say the first 5-9 years of bitcoin, thus useless for network services.

But still not useless enough to make sure that everything follows the consensus rules.

[coolcoinz]

The downloading part is what I would be more concerned about. It's really cheap to get enough storage space to hold your own copy, but it can take weeks for your core client to download it. It can take days with a high speed connection, but the majority of the world doesn't have access to it. For many of us 50 or 100 megabit connection is nothing to brag about, but in many countries 2 is all that you will get. Getting a node to run in such conditions, especially with the client messing up the database from time to time, requires a huge effort.

I have 50 Mbps and syncing takes forever, it feels like my connection is not being fully utilized and also peer discovery is slow. Sadly I was too lazy too investigate this issue to find a solution, and eventually I gave up on running a full node altogether. So, even now running a full node is kinda problematic.

I had the same problem. With 100 Mb/s I needed about 3 or 4 days to download the blockchain with my qt client and syncing was taking at least 10 minutes if I remembered to start it up every day. When I went somewhere for the weekend and forgot, I had to wait like 30 min the next time I started the client. To top it off it was all happening more than a year back. Right now it must be much worse. I still have my outdated qt client but not running it anymore.

Not everyone needs to run a full node; my stand is that if you aren't capable of running a full node, just use a SPV client.

For those who are able to run a node, the internet connection is probably not the main issue. With the current state of Bitcoin, the downloading won't take that long with the simultaneous downloading from the connected nodes. The main limiting factor is probably with the disk speed and the CPU verification speed. In the long term, the disk space is probably the main constraints that we will face. Memory density isn't growing all that fast and the memory space is still fairly expensive.

Yes, not everyone has to do it, but what will be the incentive in the near future? If every year it takes longer to download the blockchain and you need a better computer to run a node, why would you? Surely there will always be enthusiasts willing to do it but as years pass by there will be less and less of them. There should be either a way to make it easier and cheaper or a way for the node owners to profit from it.

IMO disk space is still very cheap compared to the cost of electricity and the other components you will need to run a node. You can get a 3tb drive for $50. Isn't this cheap? It will probably die a natural death before blockchain outgrows it.

[franky1]

Capable of participating in a UASF.

i know you love to derail. but ill bite
1. the UASF was just in name, not in action. it did not require user opt-in
2. 'compatible nodes' including legacy nodes that dont validate segwit still would have functioned under uasf
3. now to finish off the meander.. research 1037.. its an important number in relation to full node

now getting back to the topic.
ssd vs last gen HDD is not expensive. especially when comparing to to cost of tx's those in favour of fee wars, when you add up utility over a 4 year period

if people are ok to spend hundreds over the years for transactions. then spending a bit on a hard drive every 3-4 years is a non issue.
but if you wanna prune, and just be a leacher and not a sync seeder. then just start as mediocre node and be happy, stop pretending your still full node

[vladimirhf]

You not quite right. A SSD is a HDD all SSD are HDD but not all HDD are SSD got it?? You first got ata HDD then sata HDD.

a bit confusing here. some devices are hybrid,  HDD + SSD. But no, SSD is not a HDD.

HDD means hard DISK drive, a magnetic disk, SSD is not a disk.

SATA is another different thing, the type of connection cable / data transfer of the device.

[Wind_FURY]

Capable of participating in a UASF.

i know you love to derail. but ill bite

I do not "love" to derail. You simply post a lot of misinformation in the forum.

1. the UASF was just in name, not in action. it did not require user opt-in
2. 'compatible nodes' including legacy nodes that dont validate segwit still would have functioned under uasf
3. now to finish off the meander.. research 1037.. its an important number in relation to full node

I do not know what dimension you're living in, but nodes give demand to what miners produce. Blocks. The UASF forced the miners' hands to activate Segwit because there was a threat from users that it would reject non-Segwit blocks if they don't activate. In truth, I believe soft forks should be activated as a UASF. Next time.

[bob123]

~snip~

I do not "love" to derail. You simply post a lot of misinformation in the forum.

You just noticed that now ?

He is a known troll on this forum, trying to spread misinformation with his sciolism.

The best you can do, is to put him onto you ignore list and enjoy a less retarded forum from this moment on.

[Wind_FURY]

~snip~

I do not "love" to derail. You simply post a lot of misinformation in the forum.

You just noticed that now ?

He is a known troll on this forum, trying to spread misinformation with his sciolism.

The best you can do, is to put him onto you ignore list and enjoy a less retarded forum from this moment on.

The best we can do is to be informed ourselves, and counter-post the correct information. We don't want newbies to be misinformed just because all informed users are too afraid to debate him.

Ignoring him only encourages him.