Congratulation, Bitcoin has reached 500 GB size hard disk data

[nullama]

~snip~
Running a pruned node has downsides for users. It can limit your ability to validate older transactions and blocks. In the event of a dispute, it can be more difficult to prove the validity of your transactions. Additionally, you won't be able to fully participate in the decentralized network as a fully validating node, making the network less secure.

You always validate all the transactions in the blockchain, prunned or not.

When you're running a prunned node you simply remove older data that has been already validated.

You're usually checking transactions that are relatively current, so there are no major issues in running a prunned node, you can also set the size to whatever you like so you can have say the last 5 years of Bitcoin transactions. That is plenty enough for most people.

[1714788816]

1714788816

[1714788816]

1714788816

[1714788816]

1714788816

[1714788816]

1714788816

[1714788816]

1714788816

[franky1]

You always validate all the transactions in the blockchain, prunned or not.

When you're running a prunned node you simply remove older data that has been already validated.

You're usually checking transactions that are relatively current, so there are no major issues in running a prunned node, you can also set the size to whatever you like so you can have say the last 5 years of Bitcoin transactions. That is plenty enough for most people.

when new tx formats come out(rule/format change to consensus). unless you have upgraded to have new format recognition (they done away with/removes requirement of the 2009-2016 upgrade requirement pre consensus activation)

you wont be validating everything... you will be treating new formats (in an unupgraded node which does not recognise) as 'default: isvalid' without the thorough checks
thus the dev politics is making people more reliant on one brand of node to be the most uptodate that people should upgrade to the moment new versions are announced(the extra flaw of the centralisation debate in other topics)

[Nhazwrath]

Just saw a advertisement news article(note I didn't call it news or advertisement )

Seagate is coming out with 18 and 24 terabyte HD's this year.

no longer worried about 500 gigs. 

Although id like to see in the future is nodes that can download in reverse so full nodes can function.  but have a minimum of the last year of data. 

[LoyceMobile]

Although id like to see in the future is nodes that can download in reverse so full nodes can function.  but have a minimum of the last year of data.

That's not how a blockchain works. You need to start from the genesis block to be able to verify everything belongs to the same chain.

[franky1]

to mitigate initial sync /initial block download time there are some options

one is a 'ball&chain'
where say for instance its assumed that block 0-630,000 are assumed as immutible. and mile stoned where you just download a ball of UTXOset(lump of data of utxo with its own string ID) of which you then build a chain from block point 630,001 assuming and calling the block 630,000 as the 'genesis' (first block of full chain data)

thus not needing to keep any "spents" of blocks 0-629,999 in the form of a chain

ofcourse it would need some coding and activation for nodes to understand this concept, but thats a discussion for the future

[AverageGlabella]

to mitigate initial sync /initial block download time there are some options

one is a 'ball&chain'
where say for instance its assumed that block 0-630,000 are assumed as immutible. you just download a ball of UTXOset(lump of data of utxo with its own string ID) of which you then build a chain from block point 630,001 assuming and calling the block 630,000 as the 'genesis' (first block of full chain data)

thus not needing to keep any "spents" of blocks 0-629,999 in the form of a chain

ofcourse it would need some coding and activation for nodes to understand this concept, but thats a discussion for the future

How would you verify transactions then? Having a incomplete blockchain would not be able to verify that you are on the right chain. The only exception to this are pruned nodes but then they do not function like a complete node. There is no way around the increasing blockchain size except for better hard drives. Most hard drives up to 4TB are cheap today. I think by the time we reach higher then that higher capacities will be cheaper to and you could split the blockchain onto two hard drives and still keep the integrity of the blockchain.

[franky1]

its a middle of between pruning vs full chain.
not saying its a proposal. just saying there are ways.

same principles apply. but if whole network deems blocks 0-630 are immutable you no longer need all chain data of such and just the state of position from 630k, everyone agrees state of utxoset of 0-630k can be milestoned and given a strong id ..where previous to 630k is just utxo of position upto block 629,999

but as said that would require whole network activation of new data set recognition and rule defining the 'ball' as the dataset of blocks 0-630k state

[larry_vw_1955]

Just saw a advertisement news article(note I didn't call it news or advertisement )

Seagate is coming out with 18 and 24 terabyte HD's this year.

the problem with these higher capacity hard drives is #1) they cost alot of money and #2) they probably won't last as long as older lower capacity hard drives until they die for one reason or another.

no longer worried about 500 gigs. 

if you have an 18TB hard drive then you got alot to be worried about as it is including what you're going to do if it dies.  because that's alot of data to have to backup....

[Sarah Azhari]

So if HD is not enough space to save the blockchain, if I am a student college that has a student email with 1 terabyte of free google drive. Is it safe to save bitcoin folder to google drive?

I have downloaded google drive.exe and installed it as a local (E) google drive, which I think must take advantage of the moment.

[LoyceV]

same principles apply. but if whole network deems blocks 0-630 are immutable you no longer need all chain data of such and just the state of position from 630k, everyone agrees state of utxoset of 0-630k can be milestoned and given a strong id ..where previous to 630k is just utxo of position upto block 629,999

You'll have to trust whoever you download the data on the first 630,000 blocks from. One of the main reasons to run your own Bitcoin Core node is so you don't have to trust anyone, and the only way to do that is by starting from the genesis block.

if I am a student college that has a student email with 1 terabyte of free google drive. Is it safe to save bitcoin folder to google drive?

I wouldn't do it.
It's probably safe in the sense that Google isn't going to change your blocks to make you believe some addresses have a different balance, and it can probably work if it's mounted as a network drive. But what if it gets disconnected? Bitcoin Core won't be able to save it's data, which will lead to data corruption.
And there's really no point: if you want to reindex your wallet, you'll have to read all block data through your internet connection again. If you want your node to upload data, it will have to first download every byte it uploads, so effectively it passes through your internet connection twice.
If you're low on disk space, prune is much easier.

I have downloaded google drive.exe and installed it as a local (E) google drive, which I think must take advantage of the moment.

Downloading software from Google sounds terrible for privacy.

[franky1]

same principles apply. but if whole network deems blocks 0-630 are immutable you no longer need all chain data of such and just the state of position from 630k, everyone agrees state of utxoset of 0-630k can be milestoned and given a strong id ..where previous to 630k is just utxo of position upto block 629,999

You'll have to trust whoever you download the data of the first 630,000 blocks from. One of the main reasons to run your own Bitcoin Core node is so you don't have to trust anyone, and the only way to do that is by starting from the genesis block.

by the way its not my idea, nor is it even a proposal. its just demonstrating that there are ways

and like i said it would have to be a future discussion thing where everynode has a known milestone ID for block 630k utxo state.. this would be given a strong Id of the utxoset where the network nodes identify and share this ID for 100k blocks+ before being settled into data law of consensus.. thus plenty of time to notify nodes before even then taking a ball id, which obviously matches the data because they are all milestoning the same data

after all its like having al blocks and knowing the ID of block 774435 today compares to everyone around, to know we are all working on the same chain if exact data matches the ID and the id matches id of block heigh and everyone is at same chain height with same id means they all have the same data

but the ball idea.. is not full blocks, but a mile stone  blokckheight in the past, back long enough to be considered immutable where the spents are 'pruned' out already
and the hash of the ball is easily verifiable to a network known milestone much the same as the genesis hash is known throughout the network to keep nodes united and building on the same milestone

[ABCbits]

Although id like to see in the future is nodes that can download in reverse so full nodes can function.  but have a minimum of the last year of data. 

It's not matter of time, but rather whether someone would bother modify existing full node software to add such feature. It can be done by downloading all block headers then download blocks in reverse which skip many verification.

to mitigate initial sync /initial block download time there are some options

one is a 'ball&chain'
where say for instance its assumed that block 0-630,000 are assumed as immutible. and mile stoned where you just download a ball of UTXOset(lump of data of utxo with its own string ID) of which you then build a chain from block point 630,001 assuming and calling the block 630,000 as the 'genesis' (first block of full chain data)

thus not needing to keep any "spents" of blocks 0-629,999 in the form of a chain

ofcourse it would need some coding and activation for nodes to understand this concept, but thats a discussion for the future

UTXO commitment also has similar idea.

#2) they probably won't last as long as older lower capacity hard drives until they die for one reason or another.

Is this statement based on your own experience or certain article/research?

[AverageGlabella]

by the way its not my idea, nor is it even a proposal. its just demonstrating that there are ways

I do not mean to attack your idea but I think the integrity of the Blockchain is more important then saving a few bucks off already cheap technology. Those that are interested in running a full node will want that integrity so I do not think that this discussion in the future will lead to anywhere but recommending multiple storage locations. I think our full node and pruned nodes already cater to their purpose and we do not need something in the middle which will only confuse things.

[NotATether]

So if HD is not enough space to save the blockchain, if I am a student college that has a student email with 1 terabyte of free google drive. Is it safe to save bitcoin folder to google drive?

I have downloaded google drive.exe and installed it as a local (E) google drive, which I think must take advantage of the moment.

You can't store Bitcoin Core blocks directly to the cloud. First you have to mount the file system using something like FUSE and rclone, but that is prone to unexpected unmounting errors so it is not something that I particularly recommend.

Besides, irrespective of your storage quota, there is a 750GB monthly transmission limit between your computer and Google drive, and Bitcoin Core already jumps half of that, meaning this method will become impractical very soon. It is already impossible to accomplish on some other clouds.

[AverageGlabella]

So if HD is not enough space to save the blockchain, if I am a student college that has a student email with 1 terabyte of free google drive. Is it safe to save bitcoin folder to google drive?

I have downloaded google drive.exe and installed it as a local (E) google drive, which I think must take advantage of the moment.

You can't store Bitcoin Core blocks directly to the cloud. First you have to mount the file system using something like FUSE and rclone, but that is prone to unexpected unmounting errors so it is not something that I particularly recommend.

Besides, irrespective of your storage quota, there is a 750GB monthly transmission limit between your computer and Google drive, and Bitcoin Core already jumps half of that, meaning this method will become impractical very soon. It is already impossible to accomplish on some other clouds.

Cloud is probably more expensive then just getting 4 hard drives of 2-4TB and connecting them up to the node. 8TB-16TB probably means you will not run out of space for the node in decades and it would come at a cheap cost. You could use 2nd hand hard drives to keep the cost down if you wanted. Probably spend around $50-100 to get those 4 hard drives or you could just buy more as you are needed and put them in a caddy together.

[Welsh]

heres a prospective for how huge 500gb is
500gb.. double it. and then you have

its not a case of 500gb is "huge"
its that something that can secure hundreds of millions of peoples value, and 14 years history of transactions can all fit in the palm of your hand

Bare in mind, that SD cards are more prone to failure than traditional storage methods like hard drives, and SSDs. SSDs, are generally more expensive, along with SD cards. Hard Drives do the job for storing the blockchain, have stood the test of time, and are generally quite reliable, and cheap. It doesn't matter what brand you have of hard drive, we've got to the point that most have decent longevity, and are relatively cheap to replace when they finally give in.

When you're looking at storage methods for the blockchain, at the moment it has to be a hard drive. They're the most cost effective, while your second option would likely be a SSD card, but they have a limited amount of lifespan, that's determined by the cell usage, so if you're writing a lot of data to the SSD you could potentially hit that relatively soon compared to that of a hard drive. Although, the amount you're writing to the disk with the Blockchain isn't massive when you take into consideration 24/7 RAID servers that are basically operating constantly.

That being said, hard drives are generally bigger so won't fit in the palm of your hand as much as a SDcard, although that entirely depends on how big your hands are doesn't it . Most SSD cards today are tiny, and aren't far from a SD card, especially m2 SSDs. Although, I don't think many users here would have a problem accommodating a hard drive that can store massive amounts of data at a small cost compared to the alternatives. 

With a Pi, I expect the limited RAM and CPU to be the bottleneck.

Either the RAM, CPU or the storage method. Some users might cheap out on the SD card, and get one that's got relatively low write speeds, which could be the bottleneck.

[DaveF]

If anyone really cares the new price everywhere I can see here in the US for a 2TB Samsung 870EVO SSD is $149.99
Amazon, newegg, Microcenter, wherever it's $150.
These are all brand new sealed in a box drives.

Just about EVERY 4TB spinning drive is under $100 until you get into the higher end ones which you DO NOT NEED for this. Yes, your IBD might take a bit longer if the rest of your system is good enough. But if there is ANY other bottleneck be it RAM, CPU, download speed, then the drive speed does not matter.

Back to what I said back in November higher hour used 1TB and 2TB drives are being given away by a lot of people since they have NO real value anymore.

-Dave

[Sarah Azhari]

I wouldn't do it.
It's probably safe in the sense that Google isn't going to change your blocks to make you believe some addresses have a different balance, and it can probably work if it's mounted as a network drive. But what if it gets disconnected? Bitcoin Core won't be able to save it's data, which will lead to data corruption.
And there's really no point: if you want to reindex your wallet, you'll have to read all block data through your internet connection again. If you want your node to upload data, it will have to first download every byte it uploads, so effectively it passes through your internet connection twice.
If you're low on disk space, prune is much easier.

I was thinking it also if the internet is not stable.
Right now, I still have enough space, I just want to make it mobile.

Cloud is probably more expensive then just getting 4 hard drives of 2-4TB and connecting them up to the node. 8TB-16TB probably means you will not run out of space for the node in decades and it would come at a cheap cost. You could use 2nd hand hard drives to keep the cost down if you wanted. Probably spend around $50-100 to get those 4 hard drives or you could just buy more as you are needed and put them in a caddy together.

Student got 1 terabyte gdrive when login in using college email. and maybe more than 5 terabytes when you have enough shrewd to modify your friend email using Cbackups software.

[LoyceV]

I just want to make it mobile.

My solution: I use different wallets for different purposes. Bitcoin Core stays at home, Mycelium/Coinomi/Blue Wallet/Phoenix Wallet are for the road (and funded with no more than I can afford to lose).

[franky1]

the way the visualised network topology plays out recently

majority of "always on" fullnodes* belong to the economic nodes crowd(merchants and services), compared to where many usernodes just drop in-out once a week-month to re-sync and then move some main stash funds to daily-spend wallets(mobile/lite wallets)

this is why some people think usernodes are unimportant to the network security and IBD seeding, thus they make features of "backward compatible" and pruning. where user nodes dont have to upgrade node often nor need to store all data 24/7
or thats how they want to promote it

not saying its right or wrong or making any social drama. its just how the network and dev/peer politics plays out

* yes fullnodes = full validation of latest ruleset, full archiving and full broadcasting
not "fool nodes" =pruned enabled, listen only enabled and out of date to ruleset
if your not in need of moving large sums or not receiving multiple payments where you just instead want to be able to play around with small amounts daily. then using a cell phone wallet of small daily spend amounts whilst then having a full node* separate for weekly-updates sync session(when stable electric is available) for your main bigger stash of coins would be your best case scenario of utility

but each person is different, you might(unknown to us) be a business getting alot of payments and wanting to pay alot off suppliers so may need a full node* more. where as after work just spending personal smaller amounts you use a cell phone app