new spaced repetition spams the lock screen with notifications

[BenWestgate]

these notifications should not reach the lock screen, spaced-repetition should clear it's own notifications after they display, it should not clear other notifications however.

[BenWestgate]

Escalating priority to high because if you leave your computer long enough (24-72 hours) without restarting the notifications will make it run out of memory. This means spaced repetition trainer is slowing down IBD too!

[extrapockets]

I ran into this problem and had to abort the IBD process. Currently I am trying again. I'm having Bitcoin Core download blocks, but this time I am not creating/restoring a wallet - and keeping Bails closed. I'll check in 10 hours and see what happens. Using an older Lenovo Thinkpad and a SanDisk USB3.0 drive with 30GB storage.

[BenWestgate]

A workaround is to shut down Bitcoin Core and restart Tails after you’ve installed Bitcoin Core. The spaced repetition trainer only runs for the initial setup.

…

On Mon, Aug 21, 2023 at 22:49, extrapockets ***@***.***(mailto:On Mon, Aug 21, 2023 at 22:49, extrapockets <<a href=)> wrote: I ran into this problem and had to abort the IBD process. Currently I am trying again. I'm having Bitcoin Core download blocks, but this time I am not creating/restoring a wallet - and keeping Bails closed. I'll check in 10 hours and see what happens. Using an older Lenovo Thinkpad and a SanDisk USB3.0 drive with 30GB storage. — Reply to this email directly, [view it on GitHub](#50 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ARQZ6FYV6XJHDZLEPDB2DETXWQT5LANCNFSM6AAAAAA2VROE2Y). You are receiving this because you authored the thread.Message ID: ***@***.***>

[BenWestgate]

A related improvement:

In discussions with the codex32 authors, the spec for importing and confirming shares will require custom Gtk dialogs.

This means the spaced repetition can check if you're on a typing step and not bother you until you submit your string.

[extrapockets]

Came back to check in. Bitcoin Core has finished catching up after 3 weeks of nonstop block downloading (with a few restarts when it's seemed extra slow). Common block download rates I saw were from 0.2% to 0.05%. Everything is working now.

[BenWestgate]

Thanks for this report @extrapockets!

Would you mind sharing your system's Total RAM and the model of USB stick used?

Very slow synchronizations like this are unfortunately expected from 4 GB laptops using slow USB sticks it would be the same (or worse) to an internal HDD with low RAM.

Another tester with an 8GB laptop using a budget Kingston model synced in under 4 days. And with 16GB of RAM and fast enough internet you can sync in hours.

[BenWestgate]

You can significantly improve the sync time to just a few days, even with 4GB ram by choosing one of the SSD-like flash drives here:

https://github.com/BenWestgate/Bails/blob/master/FAQ.md#what-type-of-flash-drive-should-i-get

I personally synced a 2010 MacBook with 3.6GB RAM and a Core 2 Duo CPU in 2021 in 3.5 days using an external SSD (USB 2.0 of course).

A side benefit of a faster drive (vs more RAM) especially if you use Bails frequently is starting Tails is much quicker, and catching up will reach full speed faster, versus using a cheap USB and getting more RAM.

But the Samsung FIT is $11 and performs very well, likely 2-3 day syncs on 8GB ram and under 2 weeks on 4GB.

[extrapockets]

The RAM warnings during setup helped me to understand that it would take a while. I used a laptop that I was able to keep running without interruption: 4GB RAM, i5-4300U CPU, 128GB Disk Capacity. The Thumbdrive is a SanDisk 128GB, but I am thinking that perhaps not all 128GB was accessible to BAILS since my persistent storage is only 10GB.

[extrapockets]

You can significantly improve the sync time to just a few days, even with 4GB ram by choosing one of the SSD-like flash drives here:

https://github.com/BenWestgate/Bails/blob/master/FAQ.md#what-type-of-flash-drive-should-i-get

I personally synced a 2010 MacBook with 3.6GB RAM and a Core 2 Duo CPU in 2021 in 3.5 days using an external SSD (USB 2.0 of course).

A side benefit of a faster drive (vs more RAM) especially if you use Bails frequently is starting Tails is much quicker, and catching up will reach full speed faster, versus using a cheap USB and getting more RAM.

But the Samsung FIT is $11 and performs very well, likely 2-3 day syncs on 8GB ram and under 2 weeks on 4GB.

I'm planning to clone BAILS next, so I'll get a SSD-style recommend drive to speed up that process and do more testing.

[BenWestgate]

The RAM warnings during setup helped me to understand that it would take a while.

By that you mean the notification that said:

Your computer is low on memory.
Additional RAM might significantly improve sync performance.

Or something I wrote in the FAQ?

I am thinking that perhaps not all 128GB was accessible to BAILS since my persistent storage is only 10GB.

Tails doesn't touch the internal storage at all, so only the USB stored blockchain data. It may have run faster, even on 4G ram, if it had used more of your USB's capacity.

Can you type lsblk in terminal and tell me the SIZE of sda and sda2?
Then type df -h ~/Persistent/.bitcoin and give me Size, Used and Avail

[BenWestgate]

I'm planning to clone BAILS next

Clone has not been implemented into the alpha yet. Before you make any wallets, however, you can make clones safely:

Use tails-cloner (formerly Tails Installer if you're on an old Tails version), and a target USB of equal or greater size.

Roll dice or use head -c10 /dev/urandom | base32 to set a temporary passphrase for their new persistent storage. Have them change it to a more memorable diceware passphrase in the Persistent Storage application.

Making clones after you already have secrets on your Bails requires encrypting your data before tails-cloner runs, and it would be easier to have that temporary passphrase displayed without using terminal or even to get a suggestion like when creating persistent storages.

[extrapockets]

The RAM warnings during setup helped me to understand that it would take a while.

By that you mean the notification that said:

Your computer is low on memory.
Additional RAM might significantly improve sync performance.

Or something I wrote in the FAQ?

I am thinking that perhaps not all 128GB was accessible to BAILS since my persistent storage is only 10GB.

Tails doesn't touch the internal storage at all, so only the USB stored blockchain data. It may have run faster, even on 4G ram, if it had used more of your USB's capacity.

Can you type lsblk in terminal and tell me the SIZE of sda and sda2? Then type df -h ~/Persistent/.bitcoin and give me Size, Used and Avail

Yes, the low memory warning pop-up, and also I had read the README.

$lsblk output:
sda 8:0 0 119.2G 0 disk
├─sda1 8:1 0 498M 0 part
├─sda2 8:2 0 4G 0 part
├─sda3 8:3 0 110.8G 0 part
└─sda4 8:4 0 4G 0 part
sdb 8:16 1 28.6G 0 disk
├─sdb1 8:17 1 8G 0 part /lib/live/mount/medium
└─sdb2 8:18 1 20.6G 0 part
└─TailsData_unlocked
253:0 0 20.6G 0 crypt /run/nosymfollow/live/persistence/TailsData_un
zram0 254:0 0 3.7G 0 disk [SWAP]

$df -h ~/Persistent/.bitcoin output:

size: 21G
used: 9.8G
avail: 9.4G
use: 51%

NOTE: I was incorrect on the thumbrive size in my earlier post. The thumbdrive I'm using for BAILS is 32GB, not 128.

[BenWestgate]

Increasing timeout only somewhat helped the issue I have found the root cause:

Your suspicion is correct: when the screen is locked, pinentry-gnome3 is likely to cancel immediately rather than wait for the timeout period to elapse. This is because pinentry-gnome3 requires an active graphical environment to display its dialog and accept user input. If the screen is locked, the necessary environment for displaying the dialog is not available, causing the program to cancel the operation right away.

This immediate cancellation can lead to a large number of notifications because each attempt to prompt for the passphrase fails instantly, and the script may retry frequently, creating numerous notifications in quick succession.

To handle this, you might consider modifying your script to detect whether the screen is locked before invoking pinentry-gnome3. Here is a possible modification:

Checking if the Screen is Locked

You can use a utility like gnome-screensaver-command or xdg-screensaver to check if the screen is locked:

is_screen_locked() {
    if gnome-screensaver-command -q | grep -q "is active"; then
        return 0
    else
        return 1
    fi
}

get_passphrase() {
    # Check if the screen is locked
    if is_screen_locked; then
        echo "Screen is locked, postponing passphrase prompt."
        return 1
    fi

    passphrase="$(echo -e "SETPROMPT $enter Persistent Storage passphrase:\nGETPIN" | pinentry-gnome3 --timeout 99999 2>&1 | grep D | cut -c3-)"
    if [ -n "$passphrase" ]; then
        return 0  # Success: passphrase is not empty
    else
        return 1  # Failure: passphrase is empty
    fi
}

Example Script with Screen Lock Check

Here is how you can integrate the screen lock check into your script:

#!/bin/bash

min_interval=5
interval=30
exp=1
enter='Enter'
sleep $interval

is_screen_locked() {
    if gnome-screensaver-command -q | grep -q "is active"; then
        return 0
    else
        return 1
    fi
}

get_passphrase() {
    if is_screen_locked; then
        echo "Screen is locked, postponing passphrase prompt."
        return 1
    fi

    passphrase="$(echo -e "SETPROMPT $enter Persistent Storage passphrase:\nGETPIN" | pinentry-gnome3 --timeout 99999 2>&1 | grep D | cut -c3-)"
    if [ -n "$passphrase" ]; then
        return 0
    else
        return 1
    fi
}

while true; do
    get_passphrase
    if [ $? -eq 0 ]; then
        unset passphrase temp_passw
        interval=$((interval * (RANDOM % 2500 + 2000) / 2 ** exp / 1500))
        (( interval < min_interval )) && interval=$min_interval
        sleep $interval
        exp=0
        enter='Enter'
    else
        unset passphrase temp_pass
        zenity --notification --text="Passphrase does not match or screen is locked.\nTry again."
        sleep 2
        enter='Re-enter'
        ((exp = (exp == 0) ? 2 : exp + 1)) 
    fi
done

By including the is_screen_locked function, the script now checks if the screen is locked before attempting to prompt for the passphrase, thus avoiding immediate cancellations and excessive notifications when the screen is locked.

[BenWestgate]

If the screen is locked. No notification should be generated and the current interval should simply continue looping until the screen is unlocked again.