Is 0.12 with pruned mode a good idea for newbies?

[thejaytiesto]

So usually I don't recommend full node (Core) to newbies because they would be put off by the fact that you have to download GB's of data at slow speeds which take ages.

So I wonder if Core in pruned node is a good way to get them started, couple with the fact the new features make it boot faster too. Of course Electrum should be enough, but since I have been using Core for years im paranoid now to use anything that isn't Core for any relevant amounts of BTC, so I would recommend Core in your computer for main amount of BTC + Mycelium for "let's do groceries" type of amount of BTC for newbies if Core in pruned mode is light enough so they don't get pissed off with waiting time or just a frustrating experience.

Of course the remaining drawbacks would be:

1) The wallet in Core is still too minimalistic, it doesn't even allow you to order your receiving/sending addresses nicely in groups, or in order of creation etc, only by of alphanumerical order, so you end up with a mess since it's recommended to use 1 address each time.

2) The fact that you have to use an address each time is in itself an annoyance for noobs. Im wishing in the future stuff like BIP47 can solve this? Since I've heard HD by default is not possible with Core?

3) Then we have the need of doing backups for each single new address we make. Obviously it's too paranoid, but every month or so, you would need to copy your current wallet.dat to your backup devices since the backup devices would lack the generated addresses during that period.

Im just trying to think how to get people involved in running nodes and running a "lite node" is a start but we need to give them feel like they are getting something extra. For me the extra in security and reliance is enough to deal with it but not everyone is as paranoid or even holds enough BTC to care.

[1715279954]

1715279954

[1715279954]

1715279954

[xyzzy099]

So usually I don't recommend full node (Core) to newbies because they would be put off by the fact that you have to download GB's of data at slow speeds which take ages.

So I wonder if Core in pruned node is a good way to get them started, couple with the fact the new features make it boot faster too. Of course Electrum should be enough, but since I have been using Core for years im paranoid now to use anything that isn't Core for any relevant amounts of BTC, so I would recommend Core in your computer for main amount of BTC + Mycelium for "let's do groceries" type of amount of BTC for newbies if Core in pruned mode is light enough so they don't get pissed off with waiting time or just a frustrating experience.

Of course the remaining drawbacks would be:

1) The wallet in Core is still too minimalistic, it doesn't even allow you to order your receiving/sending addresses nicely in groups, or in order of creation etc, only by of alphanumerical order, so you end up with a mess since it's recommended to use 1 address each time.

2) The fact that you have to use an address each time is in itself an annoyance for noobs. Im wishing in the future stuff like BIP47 can solve this? Since I've heard HD by default is not possible with Core?

3) Then we have the need of doing backups for each single new address we make. Obviously it's too paranoid, but every month or so, you would need to copy your current wallet.dat to your backup devices since the backup devices would lack the generated addresses during that period.

Im just trying to think how to get people involved in running nodes and running a "lite node" is a start but we need to give them feel like they are getting something extra. For me the extra in security and reliance is enough to deal with it but not everyone is as paranoid or even holds enough BTC to care.

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

[achow101]

So usually I don't recommend full node (Core) to newbies because they would be put off by the fact that you have to download GB's of data at slow speeds which take ages.

So I wonder if Core in pruned node is a good way to get them started, couple with the fact the new features make it boot faster too. Of course Electrum should be enough, but since I have been using Core for years im paranoid now to use anything that isn't Core for any relevant amounts of BTC, so I would recommend Core in your computer for main amount of BTC + Mycelium for "let's do groceries" type of amount of BTC for newbies if Core in pruned mode is light enough so they don't get pissed off with waiting time or just a frustrating experience.

Of course the remaining drawbacks would be:

1) The wallet in Core is still too minimalistic, it doesn't even allow you to order your receiving/sending addresses nicely in groups, or in order of creation etc, only by of alphanumerical order, so you end up with a mess since it's recommended to use 1 address each time.

2) The fact that you have to use an address each time is in itself an annoyance for noobs. Im wishing in the future stuff like BIP47 can solve this? Since I've heard HD by default is not possible with Core?

3) Then we have the need of doing backups for each single new address we make. Obviously it's too paranoid, but every month or so, you would need to copy your current wallet.dat to your backup devices since the backup devices would lack the generated addresses during that period.

Im just trying to think how to get people involved in running nodes and running a "lite node" is a start but we need to give them feel like they are getting something extra. For me the extra in security and reliance is enough to deal with it but not everyone is as paranoid or even holds enough BTC to care.

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.

[Jet Cash]

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.

[Moloch]

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

[alani123]

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.

[mmortal03]

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.

[achow101]

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.

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.

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.

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.

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.

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.

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.

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]

[mmortal03]

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.

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?

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.

It just happened to me again. I just mentioned this bug here: https://bitcointalk.org/index.php?topic=1347286.msg13832507#msg13832507

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

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.

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

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.

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.

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

[achow101]

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?

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.

[af_newbie]

So usually I don't recommend full node (Core) to newbies because they would be put off by the fact that you have to download GB's of data at slow speeds which take ages.
...

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

[philipma1957]

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

[thejaytiesto]

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.

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.

[sturle]

1) The wallet in Core is still too minimalistic, it doesn't even allow you to order your receiving/sending addresses nicely in groups, or in order of creation etc, only by of alphanumerical order, so you end up with a mess since it's recommended to use 1 address each time.

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.

2) The fact that you have to use an address each time is in itself an annoyance for noobs. Im wishing in the future stuff like BIP47 can solve this? Since I've heard HD by default is not possible with Core?

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

3) Then we have the need of doing backups for each single new address we make. Obviously it's too paranoid, but every month or so, you would need to copy your current wallet.dat to your backup devices since the backup devices would lack the generated addresses during that period.

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.

[achow101]

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.

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.

1) The wallet in Core is still too minimalistic, it doesn't even allow you to order your receiving/sending addresses nicely in groups, or in order of creation etc, only by of alphanumerical order, so you end up with a mess since it's recommended to use 1 address each time.

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.

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

2) The fact that you have to use an address each time is in itself an annoyance for noobs. Im wishing in the future stuff like BIP47 can solve this? Since I've heard HD by default is not possible with Core?

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

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.

3) Then we have the need of doing backups for each single new address we make. Obviously it's too paranoid, but every month or so, you would need to copy your current wallet.dat to your backup devices since the backup devices would lack the generated addresses during that period.

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.

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.

[tommorisonwebdesign]

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.

[miguelmorales85]

So usually I don't recommend full node (Core) to newbies because they would be put off by the fact that you have to download GB's of data at slow speeds which take ages.
...

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

LOL

[mmortal03]

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.

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).

[thejaytiesto]

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.

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).

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.

[mmortal03]

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.

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.