Update pruning tooltip

BitcoinErrorLog commented at 7:17 am on June 30, 2020: none

This tooltip was a bit confusing and a deterrent more than informative. Can we adjust to something that fits a user looking for a way to save disk space?

This tooltip was a bit confusing and a deterrent more than informative. Can we adjust to something that fits a user looking for a way to save disk space?

dc47298a1f

in src/qt/forms/optionsdialog.ui:58 in dc47298a1f outdated

54@@ -55,7 +55,7 @@
55         <item>
56          <widget class="QCheckBox" name="prune">
57           <property name="toolTip">
58-           <string>Disables some advanced features but all blocks will still be fully validated. Reverting this setting requires re-downloading the entire blockchain. Actual disk usage may be somewhat higher.</string>
59+           <string>>Enabling pruning significantly reduces the disk space required to verify transactions by removing some advanced features. Reverting this setting requires downloading the entire blockchain again.</string>

hebasto commented at 7:29 am on June 30, 2020:

Please remove redundant >.

hebasto commented at 7:37 am on June 30, 2020: member

Some personal opinions:

actually “significantly” depends on the -prune setting value
“re-downloading” is equivalent to “downloading … again”, but is shorter
pruning does disable “some advanced features”, not removes them
“all blocks will still be fully validated” is important and shouldn’t be dropped

hebasto commented at 7:40 am on June 30, 2020: member

@BitcoinErrorLog To make reviewing more constructive mind elaborating what exactly is confusing in the current tooltip for you?

BitcoinErrorLog commented at 7:54 am on June 30, 2020: none

I’m totally okay with nitpicking for accuracy as long as it results in a useful tooltip. If I read it as is released, it sounds risky, resource-intensive and does not communicate that I could run Bitcoin with much smaller footprint. Pruning is a huge thing for node adoption, it should be clear to a typical user there is a huge benefit to using it.

Sjors commented at 9:44 am on June 30, 2020: member

Concept ACK on making the option more appealing. I’ve often found people are surprised to learn that blocks are still validated when prune is enabled.

Original message:

Disables some advanced features but all blocks will still be fully validated. Reverting this setting requires re-downloading the entire blockchain. Actual disk usage may be somewhat higher.

Current proposal in this PR:

Enabling pruning significantly reduces the disk space required to verify transactions by removing some advanced features. Reverting this setting requires downloading the entire blockchain again.

This suggest a cause and effect that isn’t really correct. We never needed the disk space to verify transactions - only chainstate and a few recent blocks are needed for that - and removing the advanced features is just a side-effect; they’re not the reason pruning isn’t a default.

Here’s my attempt (with @hebasto’s points included):

Enabling pruning significantly reduces the disk space required to store transactions. All blocks are still fully validated, but the are removed after some time. Pruning disables some advanced features and reverting this setting requires re-downloading the entire blockchain.

actually “significantly” depends on the -prune setting value

Which by default is extremely small, so that’s not worth mentioning imo.

BitcoinErrorLog commented at 1:11 pm on June 30, 2020: none

Edited for typo and brevity:

Enabling pruning significantly reduces the disk space required to store transactions. All blocks are still fully validated. Pruning disables some advanced features. Reverting this setting requires re-downloading the entire blockchain.

Also, please consider:

Enabling pruning significantly reduces the disk space required to store transactions. All blocks are still fully validated. Reverting this setting requires re-downloading the entire blockchain.

This is even shorter, as I doubt any advanced feature user cares about a tooltip UI detail like that. Are such advanced features even in the UI?

Sjors commented at 10:11 am on July 1, 2020: member

Either looks good to me. It could be annoying for someone, once they decide they need an index, to then realize they shouldn’t have pruned. But I’m fine with leaving the sentence about advanced features out.

Update to pruning tooltip after feedback

Update to pruning tooltip after feedback

1c82a82c94

BitcoinErrorLog commented at 10:29 am on July 1, 2020: none

File has been updated with shorter version.

BitcoinErrorLog commented at 10:41 am on July 1, 2020: none

Now where do I go to lobby/edit for prompting the user to choose whether to turn on pruning on first run at install? :)

Sjors commented at 7:11 pm on July 1, 2020: member

~ACK 1c82a82~ (after squash)

Pruning is automatically suggested for users with insufficient disk space, see https://github.com/bitcoin/bitcoin/pull/16714.

Currently it suggests pruning if your free disk space less than the expected blockchain size plus 10 GB, see intro.cpp:

0        if (ui->prune->isEnabled()) {
1            ui->prune->setChecked(m_bytes_available < (m_blockchain_size_gb + m_chain_state_size_gb + 10) * GB_BYTES);

The easiest change you could propose is to increase that margin, e.g. to 100 GB. People with giant disks are likely to care less about pruning.

hebasto commented at 5:51 am on July 2, 2020: member

Let me share my concerns regarding this PR.

The GUI has two places where the -prune option is available for an user to change:

the intro window, and
the “Main” tab in the “Options” window

It seems reasonable to synchronize tooltips in both places.

As pruning consequences (e.g., time-consuming block chain re-downloading) could be frustrating for an inexperienced user, I’d move important details from tooltips to window labels to let the user to focus on them. Also see Human Interface Guidelines - Help Tags (Tooltips).
We could start to align the Bitcoin Core GUI with Optech Style Guide (cc @harding @jnewbery):

s/“blockchain”/“block chain”/

harding commented at 9:10 am on July 2, 2020: contributor

Block chain as two words is historically consistent with Bitcoin Core naming, e.g. https://github.com/bitcoin/bitcoin/pull/6666 , and it’s what nearly everyone used when I started writing about Bitcoin. I’ve continued using two words for consistency with my previous writing and that’s why it’s that way in the Optech style guide. However, I have no opposition to the one-word term.

Beyond the one-word/two-word debate, the phrasing in this PR LGTM. @BitcoinErrorLog FYI: the maintainers will probably ask for this to be squashed before they merge.

BitcoinErrorLog commented at 9:36 am on July 2, 2020: none

Could you link me to the other tooltip? I’m not exactly expert in this environment, but happy to review it and try to keep things consistent. I’m not sure this will be important since it is two different situations for a user. Or maybe you are proposing only having the tooltip text appear once in the code to remove redundancy?
I’m not personally interested in excessive hand-holding. I’m skeptical there is/will be problematic frustration about reverting pruning consequences, and I don’t think window labels, as I understand them, are notably user-friendly.
Blockchain is one word. There is no debate on this anymore.

ryanofsky commented at 9:46 am on July 2, 2020: contributor

Blockchain is one word. There is no debate on this anymore.

Blockchain is a word, but it has some negative connotations and associations that “block chain” avoids

hebasto commented at 10:10 am on July 2, 2020: member

@BitcoinErrorLog

Could you link me to the other tooltip?

https://github.com/bitcoin-core/gui/blob/d6fe5b28dff4c512bad7c9576232d6def10608d4/src/qt/forms/intro.ui#L216

BitcoinErrorLog commented at 10:46 am on July 2, 2020: none

Blockchain is a word, but it has some negative connotations and associations that “block chain” avoids

With respect, this is software, not a political forum. There is no useful statement being made by making it two words. I’ll just end up trolling such topics to meaninglessness by requesting “timechain” or “time chain” is a better argument, etc.

Would prefer productivity, personally.

Sjors commented at 11:34 am on July 2, 2020: member

Let’s not touch the spelling of “blockchain” in this PR. That can be done for the whole codebase in a separate PR, which I’ll probably NACK and mute :-)

Please squash. Regarding the other tooltip: no strong preference if you tweak it. By the time a user visits those settings, as opposed to the intro screen, they probably have a bit more knowledge.

block chain re-downloading) could be frustrating for an inexperienced user

But I don’t expect inexperienced users to want this, especially GUI users. E.g. a txindex is more likely useful for a server-type application.

harding commented at 12:07 pm on July 2, 2020: contributor

I’ll just end up trolling such topics to meaninglessness by requesting “timechain” or “time chain” is a better argument, etc.

I think this threat should be taken seriously. @BitcoinErrorLog has a history of such trolling. I suggest that this message serve as a warning that such behavior here will result in a permanent ban from this project’s hosted repositories.

MarcoFalke commented at 12:13 pm on July 2, 2020: contributor

Please squash your commits according to https://github.com/bitcoin-core/gui/blob/master/CONTRIBUTING.md#squashing-commits

BitcoinErrorLog closed this on Jul 2, 2020

laanwj referenced this in commit 31bdd86631 on Jul 15, 2020

jonasschnelli referenced this in commit 9453fbf5a0 on Oct 22, 2020

laanwj referenced this in commit 924a4ff7eb on Oct 29, 2020

jonasschnelli referenced this in commit c45e1d9aa7 on Nov 20, 2020

MarcoFalke referenced this in commit bce09da122 on Apr 28, 2021

MarcoFalke referenced this in commit eb9a1fe037 on May 7, 2021

MarcoFalke referenced this in commit c857148636 on May 15, 2021

bitcoin-core locked this on Feb 15, 2022

Update pruning tooltip #15