Topic: Is 0.12 with pruned mode a good idea for newbies? (Read 2818 times)

Yes, if I recall correctly by reading the Core roadmap, it was around 700% faster with the libsecp256k1 now, so I hope that this is the problem and not my bandwidth, since even if my bandwidth is nothing to write about, im sure I could be able to download those sizes way faster if I was downloading it from a well seeded torrent.
My hard drive is rather old but still a pretty decent 4 core CPU and my hard drive is just a regular 72000RPM HD.

The bottleneck is likely the signature validation process for you (based on the speed of your processor and your hard drive), not a bandwidth limitation. The new release is, at least, considerably faster at this, due to libsecp256k1 being implemented.

My biggest problem beside having to use a ton of GB on the blockchain is the fact that it's sooooo slow to download. I don't know at how much kb/s im downloading (any way to know?) but there's now ay im using all of my bandwidth properly, it takes way too much time to download and sync small periods of time like sometimes when I don't open Bitcoin core for 4 days or something.

Yeah, while knightdk did correct me on a few of those points, I'd still tell people to stick with the full node unless they understand all of the tradeoffs. Hard drive space is generally cheap, whereas, bandwidth is more expensive for people, and a pruned node isn't even the smartest way to conserve bandwidth (you can use other command line options for that).

LOL

It's interesting because when I was a newbie to Bitcoin I used core. My friends were hastling me about downloading the bootstrap.dat file to speed up synchronization. I agree with OP that Core is safest, however.

You clearly are not understanding all of the tradeoffs. Please read the post below the one you quoted where I explained how most of that was wrong.


The accounts isn't available in the GUI and AFAIK accounts are slated for removal soon.

And any decent wallet will send change to newly generated change addresses unless you go through some options to specify otherwise. Even with HD wallets, you will still be using a new address for pretty much every transaction.

There is work on making Bitcoin Core use HD wallets so it will also make this a non-issue at some point in the future.

You can group your receiving addresses in accounts.  Don't know if it is supported in the GUI.  haven't used the GUI for years, but I do use accounts a lot.

You don't have to use a new address each time, but it is best practice no matter which client you use.

Nah, the default keypool contains 100 addresses.  You can make 100 transactions with change or recieve to 100 new addresses before you have to back up again.  You can make the keypool larger if 100 is not enough.

Geez it looks like there are bigger tradeoffs than I thought. So what about backups? Since Core doesn't allow HD wallets, every time you create a new address, you need a new backup (and everytime you pay or receive you should be using a newly generated address, so me personally I do backups every 2 week or month). So if I want to use one of those backups on the Bitcoin Core installation (the one I used originally to create said backups), I would need to re-download the entire blockchain? That doesn't sound pretty good, unless I've understood your explanation incorrectly.

I think I will stick to full node until I understand all the tradeoffs.

A lot of this can be avoided if you use 2011 or 2012 model mac minis.

Two mac minis say 2012 basic models and a few external cloned hdds with indentical wallets. + bitcoin core.

One macmini uses an internal hdd without bitcoin core 0.11.2

one macmini uses an internal hdd with bitcoin core 0.11.2 it runs the node 24/7/365 and is up to date

clone the hdd 4 copies

 two in a safedeposit box

two in house .

a clone with made with superduper will work on any 2012 model macmini

when it boots and you start bitcoin core you will not be behind by a lot and you can have pretty good backups.

this also solves the dead mother board issue since the cloned hdd will work on any 2012 mac mini.

the biggest security issue is losing the cloned hdd.  but a decent password on the bitcoin core is pretty helpful.

just do not run two cloned  hdds on two mac minis at the same time since they are the same bitcoin core  it could confuse the block chain

There is a 'business idea'.  Start selling blockchain USB sticks or SD cards on eBay....

The block height might matter. I think there is a field in the wallet.dat file that stores the best chain and that does matter because it would indicate the last block the start scanning from. On a full node, that doesn't really matter since all of the data is there, but on a pruned node, that latest block might not be in the databases so it would be unable to scan for new transactions. If you pulled the wallet file from a fully synced node and transferred it to the pruned node immediately, it should work right away.

When you say that it was on a fully synced node previously, does it matter what the block height was, or, like you said, the wallet should be consistent as long as it was shut down properly?


While there *are* people who have use cases for swapping out wallet.dats on a single machine and rescanning them each time, you're right (based on what you said following this), that the bigger issue isn't, for most people, that of constantly changing wallets, but with people having a wallet stuck in limbo because of a wallet inconsistency, and then not being able to rescan on that machine, and thus, having to download the entire blockchain in some form to be able to rescan it. Like you said, there are ways of rescanning by way of using a full blockchain stored elsewhere, though that could be a pain, depending on a person's circumstances.


Yep, you're right, it doesn't require rescanning. I misinterpreted the ramifications of the bug that I'm experiencing, though the bug itself still stands, as discussed in the linked thread above.


Yeah, I figured something of that sort might work. I'll test it out and get back to you.

No. As long as the wallet.dat is either actually brand new or was on a fully synced node previously, it will still work and not require a full rescan. Wallet files contain the necessary transaction information in the wallet, not in some other database on the node, so it is all self-contained inside of the wallet file.

That is a drawback, but it really cannot be fixed. The solution is to make sure that the software properly shuts down and exits every single time.

How often do you make a new wallet? What are you doing that requires you to constantly be changing wallets?

Anyways, creating a new wallet doesn't require a rescan. Try it yourself.

If they are going to copy it over, then the device that they are using to transfer the data obviously has enough storage. Once the blockchain is loaded onto that device, they can run Bitcoin Core on either the source or the target and set the data directory temporarily to the flash drive and then prune it. That would work, but is kind of a hassle. Or the source machine could just have a pruned blockchain.
[/quote]

So, with a pruned node, you still have to download and verify the *entire* blockchain as it goes along -- it's just that your computer doesn't have to store all of it, so it minimizes the amount of hard drive space that you need. For newbies, this is probably going to take too long.

More importantly, a big usability issue with this seems to be that for *every* wallet.dat that you want to use in tandem with a pruned node, it must be a *brand new* one, because, with a pruned node, you can't import a previously used wallet.dat, as there's no way to rescan. So, you have to re-download and re-verify the *entire* blockchain for *each* wallet.dat that you want to start using, not just for each computer that you use them on.

In my testing, if something goes wrong during the initial verification process, like a machine is turned off or Bitcoin Core is closed, there might currently be buggy cases where the wallet gets out of sync and you have to start all over again from scratch. I'm trying to re-produce this at the moment, but you would get an error message similar to this (and you'd probably become pissed): https://github.com/bitcoin/bitcoin/issues/6345

Also, if something goes wrong with the newbie's wallet sync in the future, they'll have to start from scratch again, and their wallet.dat will be in limbo, as they can't simply rescan/reindex to import it back in.

As far as target audiences, if we're talking about lower end devices that don't have a lot of hard drive space, these devices may also not have fast processors, so, the thing stopping people from really starting to use this would be the fact that their slower processors are going to take a while to re-verify the entire blockchain from scratch (even with the new optimizations). People experimenting with this may end up wasting network bandwidth just to come to this realization.

For people who have faster processors but just want to conserve hard drive space, they're going to quickly realize that for every time they want to create a new wallet, they will have to download and verify the *entire* blockchain, instead of just having to do this every time they get a new machine. These people may also end up wasting network bandwidth, as they might not realize until the *next time* they need a new wallet that they're going to have to re-download the entire blockchain again. They will probably be annoyed, as they erroneously thought that running a pruned node would save them such trouble.

For people that are wanting to use this on a machine that physically doesn't have enough hard drive space *and* they don't want to leach additional network bandwidth, they obviously can't just physically copy the entire blockchain over and re-verify and prune it on the target machine by physically copying over from a full node, as the target machine doesn't have enough hard drive space. So, they might decide to do a -connect to a local full node that has the entire blockchain, but this, again, isn't newbie friendly, and they're *still* going to have to wait for the target machine to re-verify from the beginning. And, for *every* new wallet that they want to create, like I said before, they'll have to do this all over again.

Hopefully I'm missing something in terms of people quickly and easily getting wallets (old and new) up and running on pruned nodes without leaching additional network bandwidth, but, TL;DR, it's probably not something that newbies can benefit from at the moment.

Still a pass for me. If you were to ask me the same question a year ago I'd say Multibit (non HD). To me the HD version of Multibit is too feature heavy for newbies. Being resource intensive is another thing but I think that a full blockchain download should also be avoided. There's no reason for non advanced users to do this while all they want is a quick an easy way to transact bitcoin from their machine.

If you have the HD capacity, I would run a full node wallet every time...

That is what I do for my home computer.  I have over 1TB on a magnetic drive, and its cheap if the blockchain ever gets too big

Its handy if you want to use multiple wallet.dat files... you can't re-index with a pruned wallet


I am experimenting with pruned mode on my hosted web-server.  I am trying to limit disk space because it costs $1/month/10GB

I downloaded 0.12rc2 last night and set it for:  -prune=550 (the minimum)
It's at block 350k, less than a year behind, and is only using 1.67GB of disk space (so far)... /blocks = 507MB, /chainstate=1.1G, debug.log=77MB

I decided to use core as a newbie because I didn't know enough to decide which alternatives were safe, honest and secure. In fact I was 2 years late getting into Bitcoin while I decided how to use core. I know, it's really easy to install, but I wanted to mine and do everything else right from the start.

If you have got the disk space, then I wouldn't advise using pruning. It's another thing to learn and to go wrong.

I think it isn't a bad idea, but for some newbies, setting up Bitcoin Core in pruned node can be a hassle. Also, if the databases become corrupted, it will require a resync. You should check their internet speed before recommending since the sync takes a long time.

Even a pruned node has to download the entire blockchain in the beginning, to do initial validation.