Update delegated alteration docs

[JeremyRand]

No description provided.

[JeremyRand]

@yanmaani Are these changes okay? Have I missed anything important?

[yanmaani]

Concept ACK, suggested changes:

loaded into a Tails live system

for example, loaded into a live system

in order to transfer

to transfer

More generally, the point is that since the transfer key only needs to be accessed rarely, at predictable intervals (i.e. renewing the name), the transfer key can be held in a wallet that is highly secure but also inconvenient to access.

In general, if you only need the transfer key rarely (e.g. to renew the name), you can keep it in a secure wallet that's more inconvenient to access.

[JeremyRand]

Concept ACK, suggested changes:

loaded into a Tails live system

for example, loaded into a live system

All of these bullets are stated to be examples. I see no reason to not mention Tails; it has a good reputation and is a likely candidate for real-world users to use.

in order to transfer

to transfer

I think this change would deviate from the intended meaning. It is not intended that the user wants to require the name to be transferred; the user wants to set a requirement if the name is to be transferred.

More generally, the point is that since the transfer key only needs to be accessed rarely, at predictable intervals (i.e. renewing the name), the transfer key can be held in a wallet that is highly secure but also inconvenient to access.

In general, if you only need the transfer key rarely (e.g. to renew the name), you can keep it in a secure wallet that's more inconvenient to access.

A subset of these changes are okay. Specifying the predictability of the interval is relevant; "e.g." is wrong here (it's not an example, it's an elaboration; there is no other predictable reason that we are talking about here). Not really fond of the rewording of the last clause (requires more cognitive effort to read).

[yanmaani]

for example, loaded into a live system

All of these bullets are stated to be examples. I see no reason to not mention Tails; it has a good reputation and is a likely candidate for real-world users to use.

Well, it's restrictive - it makes it sound like there's something about Tails and that you can't do it in any other way, which is not true. The focus of that entry ought to be upon the wallet, not on how it's loaded - loading it into standard Electrum on your desktop is probably better than nothing too, for instance. I think it makes more sense to put the specific recommendations (e.g. Tails) in the security FAQ.

to transfer

I think this change would deviate from the intended meaning. It is not intended that the user wants to require the name to be transferred; the user wants to set a requirement if the name is to be transferred.

Does this imply that?

A subset of these changes are okay. Specifying the predictability of the interval is relevant;

Can't you load paper wallets with an unpredictable interval, as long as you're given some advance notice? What exactly does it mean that the interval is predictable?

"e.g." is wrong here (it's not an example, it's an elaboration; there is no other predictable reason that we are talking about here).

Well, what about selling the name?

Not really fond of the rewording of the last clause (requires more cognitive effort to read).

De gustibus.

[JeremyRand]

Well, it's restrictive - it makes it sound like there's something about Tails and that you can't do it in any other way, which is not true.

It is a list of examples. Examples are supposed to be specific. Listing Tails is therefore appropriate.

Does this imply that?

It's definitely how I initially read your wording.

Can't you load paper wallets with an unpredictable interval, as long as you're given some advance notice? What exactly does it mean that the interval is predictable?

Predictability of access time is useful for accessing many high-security wallet configurations. Advance notice implies predictability from the time of the advance notice.

Well, what about selling the name?

Selling the name is less predictable than the renewal interval, and in many cases is not predictable at all. So I don't think it's relevant to this point.

[yanmaani]

It is a list of examples. Examples are supposed to be specific. Listing Tails is therefore appropriate.

They're supposed to be specific, but not overly specific.

Trezor is a specific example of a hardware wallet, Tails is a specific example of a live system, but writing "Tails live system" is overly specific, because it implies Tails is uniquely well-suited to loading paper wallets in a way that, say, Ubuntu isn't.

It is slightly better for that purpose, but it should be made clear that Tails is not the only way to use a live system to load paper wallets.

Thus, you could write:

• You want to require signing with a paper wallet loaded into a live system (e.g. Tails)
  or
• You want to require signing with a paper wallet (e.g. loaded into a live system, such as tails)

But writing "(loaded into a Tails live system)" is confusing. At least it should say "e.g." like the others.

It's definitely how I initially read your wording.

OK, withdrawn.

Predictability of access time is useful for accessing many high-security wallet configurations. Advance notice implies predictability from the time of the advance notice.

I don't understand what you mean by this.

Why can't you just remove the "and at predictable intervals" restriction?

Selling the name is less predictable than the renewal interval, and in many cases is not predictable at all. So I don't think it's relevant to this point.

It's relevant inasmuch as leaving it out makes the documentation confusing. Transferring the name is the most obvious application of the transfer key.