@andrewkozlik's option 4' (more like 3+):

Allow powering down during the dry-run part of the process, but once dry-run is complete, the repeated backup needs to take place at worst, one reboot later.
IOW, the "Backup available" banner stays up until you unplug the device, plus on the next reboot until you unplug.

From my POV, this should be "1 backup or 1 reboot", whichever happens sooner, so:

• once you create a backup, you can't do it again,
• if you don't create a backup, the mode will disable itself after the second unplug (implementation-wise we'll drop the storage item on first boot-up, but keep the mode enabled in cache)

Meeting notes from 2024-03-26 with @matejcik and @Hannsek.

We excluded Options 1 and 3 and agreed that Options 2 and 4, possibly 3+ mentioned in @matejcik's post, are on the table.

I think the main problem with Option 2 is that it is somewhat counterintuitive, given that the user can power down in between entering recovery shares, it might be surprising that they can't power down before the repeated recovery.

The problem with Option 4 is that it takes us even further away from Trezor's security model, which relies on not being able to pull out the seed from Trezor once onboarding is complete.

We also clarified some details about Option 2, which also applies to Option 5 below. Once dry-run is complete, Trezor would offer the user to do on-device recovery, i.e. an on-screen choice between basic and advanced. Trezor would await user input or a BackupDevice message from Suite with the backup details. Thus it could work in both detached state, e.g. with a power bank, as well as in a Suite-attached state.

In the future @Hannsek is considering making it possible to do Shamir backup of individual shares the same way as we do recovery, i.e. making it possible to unplug the device between the back-up of each share. (This idea needs more thought.) In light of these considerations I propose one more option:

5. Allow powering down at any time during the entire process, but no workflows are allowed in between.

So it boils down to two questions:

• Allow power-down after dry-run and allow continuing with repeated backup after powering up later?
  • Yes: Options 4 and 5.
  • No: Options 1, 2 and 3.
  • Possibly limit this to at most one power down (Option 3+).
• Allow other workflows in between dry-run and repeated backup?
  • Yes: Options 3 and 4.
  • No: Options 1, 2 and 5.

• Change the dry-run field to an enum {RECOVERY=0, DRY_RUN=1, UNLOCK_REPEATED_BACKUP=2}, which should be backwards compatible.

Let's go with this option.

Meeting notes from 2024-04-16.

We narrowed down the options to Option 2 and Option 5, i.e. do not allow other workflows in between dry-run and repeated backup, but we did not reach a concensus about whether Trezor should continue with repeated backup if the user powers down after dry-run. Proposals that were discussed:

• Allow continuing with repeated backup always. There is a chance that the user will accidentally leave the Trezor in this state. The obvious advantage is that they can do dry-run in airgapped mode and then they are able to relocate as well as connect to a computer to complete the repeated backup.
• Allow continuing with repeated backup after power-cycling only if PIN is configured. Perhaps this is a separate issue and there are other scenarios which should only be allowed if PIN is configured.
• Show a dialog offering the user to "Back up now", "Back up later" or "Cancel". "Back up later" would enable continuing with repeated backup after power-cycle and ask the user to unplug the device. Disconnecting without choosing anything would be equivalent to "Cancel".
• Abort repeated backup if the user power-cycles after completing dry-run recovery and deferr any sort of improvements to a later PR.

Suite should be able to clearly identify from the Features message what state the Trezor is in

• Normal operation.
• Recovery in progress. Maybe even distinguish whether it's a normal recovery, dry-run recovery or unlock-repeated-backup dry-run?
• Dry-run recovery complete and ready to accept a BackupDevice message.

Right now we have a flag to identify the recovery mode:

message Features {
    ...
    optional bool recovery_mode = 29;           // is recovery mode in progress
    ...
}

Perhaps we should extend this to an enum such as {NONE=0, RECOVERY=1, DRY_RUN=2, UNLOCK_REPEATED_BACKUP=3, REPEATED_BACKUP_READY=4}.

Seems pretty clear to me.

Perhaps the main question is how to signal that we want to start a "dry run" recovery followed by a backup.

It was suggested to:

Change the dry-run field to an enum {RECOVERY=0, DRY_RUN=1, UNLOCK_REPEATED_BACKUP=2}, which should be backwards compatible.

What I don't like about this is that we would still call that field "dry-run". Which it is not, really... "dry-run" implies nothing happens... it's more of a sanity check. Which in this case, it is not.

How if we see this process more like a backup request preceded by a verification rather than a recovery followed by a back up? Would it be more clear? So it would all happen using backup, not using recovery?

On the other hand, "recovery" does kinda sound right to me as well, and we could indeed also use that.

Just not "dry run" recovery!

Perhaps this is better then?

Add a new field optional bool unlock_repeated_backup = ...;.

If so, this should probably be orthogonal to and mutually exclusive with dry-run?

So basically a "recovery" request would either be:

A) normal recovery
B) dry run. A way to double-check that the backup is fine. This is something most people should do straight away after setting up a Trezor.
C) repeated backup [perhaps without unlock_ word - which makes sense only if coupling this flow with the dry run] This is something people would optionally do later on - definitely not right after setting up a new Trezor.

Change the dry-run field to an enum {RECOVERY=0, DRY_RUN=1, UNLOCK_REPEATED_BACKUP=2}, which should be backwards compatible.

renaming fields has no compatibility costs so we can just rename the field to recovery_action or something

If so, this should probably be orthogonal to and mutually exclusive with dry-run?

which is why introducing a new field is the strictly worse option

I see, renaming fields without changing the index means the wire protocol stays the same. Great then!

Before being allowed to do so, the user would be required to perform dry-run recovery.

why?

why?

To prove ownership of the seed stored in the device.

why?

To prove ownership of the seed stored in the device.

you prove it by holding the device physically, providing the PIN and optionally password for the given wallet

if you require the dry run this important feature is devalued

yes, one will be able to change the backup scheme or create an alternative one

but you will not allow to "clone" the device which is very important and totally ignored scenario - the user should never be forced to touch his shares unless his last working device is dead

you prove it by holding the device physically, providing the PIN and optionally password for the given wallet

This changes the original threat model and we are not doing this. To create another set of shares you need to prove ownership of the seed. Having the device and PIN is not the same and is not enough.

the user should never be forced to touch his shares unless his last working device is dead

Says you, but we disagree here.

you prove it by holding the device physically, providing the PIN and optionally password for the given wallet

This changes the original threat model and we are not doing this. To create another set of shares you need to prove ownership of the seed. Having the device and PIN is not the same and is not enough.

device possession and PIN is enough move the coins (from standard wallet) - hence it's equivalent to holding the seed in any form, I don't see any incompatibility with the thread model but you are the experts here

the user should never be forced to touch his shares unless his last working device is dead

Says you, but we disagree here.

what should a serious user do having two (primary and backup) devices when one of them stops working - travel (potentially to another continent) to fetch the shares and compromise their storage? or move the UTXOs, pay the fees, mess with coin control and redistribute the shares?
or is it reasonable to expect that one should be able to use his working device to clone new backup device?
it's not 2014, things are getting serious, people function globally, implement disaster recovery schemes and there are many sensible scenarios to consider

one would expect that bitcoiners will understand that protecting people against their own mistakes causes often more damage than the threat itself... just saying

I don't see any incompatibility with the thread model

threat model is modified - with device and PIN possession I can only steal coins now; if I could generate the seed I would be able to steal coins at any time in the future (even if I do not have access to the device+PIN anymore)