Closed indolering closed 3 years ago
While the UI could be optimised (or you could use tools like my nmupdate
included in libnmcrpc), you cannot avoid paying the fee. In the current protocol, each renewal needs to be a transaction by itself. This could be changed, of course, but would be a hardfork and I don't really see the benefits. After all, isn't making renewals more expensive what you have advocated a lot of times? ;) However, this issue is valid concerning the usability of the UI.
Renewing a bunch of domains at the same time is a serious privacy leak, which many users will not understand. I strongly suggest that if this is implemented, at the least users should be explicitly warned that they will be associating their domains with each other statistically. Even better would be to randomly space them out to increase the entropy in the system.
(This topic should also be brought up in an eventual namecoin.info article on privacy considerations... but that's an issue for another ticket.)
@JeremyRand You're right of course but the client does link the name_ops via the outputs anyway...
@phelixbtc I'm not sure what you mean, what is being linked right now?
@JeremyRand I guess he means that there's a chance that you'll use change from the first transaction to pay the second's fees, in which case you get an "almost sure" link between the names anyway. It is maybe not so direct as in the case of multiple names being renewed at the same time, but users still have to assume that all names held in a single wallet can be linked together.
@domob1812 That's true, but coin control would solve that particular issue (which presumably is on the agenda for the rebase). Anything that produces additional linkage should be warned about IMHO. Even though we don't endorse any usages where anonymity is required, we should be aiming to improve that situation where feasible, and at least not make it worse.
After all, isn't making renewals more expensive what you have advocated a lot of times? ;)
Ahh yeah, I was thinking in terms of the protocol : p But still, one should be able to renew all the domains in one-fell swoop.
Renewing a bunch of domains at the same time is a serious privacy leak, which many users will not understand.
I totally agree with you, but (as others have stated) your proposal will need to make such spacing transparent to the user, including if they attempt to manually renew multiple domains in serial. Usability == Security : )
Oops, Jeremy replied while I was replying.
Anything that produces additional linkage should be warned about IMHO.
Assume that such warnings will be ignored. Yes, really.
@indolering regarding your first point, the way I would do this would be to have radio buttons labeled "randomly delay this name operation by up to 60 minutes to protect my privacy" (checked by default) and "this name operation is mission critical, do it immediately even if it affects my privacy" which come up on the confirmation dialog whenever a 2nd name transaction is being done within a short period. Reasonably transparent and usable.
Regarding your second point, I think having a radio button is less easy to ignore than a standard "should I proceed" warning. Even if it isn't, keep in mind that there are multiple demographics we're targeting; a lot of users will consider such a warning if it's presented in a non-confusing way. Those users make a warning worthwhile, even if the warning doesn't convince all users.
@JeremyRand I'll try to get around to checking out ZeroCoin (cash?) and how it works and then take a crack at the UI.
It might be the case that we just have the client follow the most robust privacy settings and assume that clients whom do not wish total anonymity would use a registrar (which would also auto renew domains, etc.).
@indolering not certain how Zerocash is specifically related to this? (Zerocash = current state of the art anonymity. Zerocoin = older version of Zerocash which is way less efficient. zerocoins (not capitalized) = the anonymous coins used in a Zerocash-based currency, as opposed to basecoins, which are the non-anonymous coins used in a Zerocash currency.)
There are cases where people will have legitimate reasons for not waiting for the delay. For example, let's say they think a server is compromised and they need to revoke the TLS keys. In such cases, depending on threat model, the name owner may wish to update the names with a much shorter delay, or immediately, at the cost of some statistical anonymity. In at least some cases, this is probably safe if done very rarely. Many of these users probably don't want to use a registrar.
@JeremyRand Sorry, let me put that another way: I haven't had time to look at the underlying system to see what can be done in regards to the UI. It sounds like you are just trading one mode (a dialog box) for another (radio buttons) when you should be trying to get rid of the mode entirely.
Obviously, I'm not up to speed on how Zero* does it's magic so I can't give any intelligent advice just yet. : )
... because humans don't do well with modes and they are the source of a significant amount of error.
@indolering I'm not seeing a good way to eliminate the user choice entirely. Some name operations need privacy, others need speed. There's no way to provide both.
That said, it is highly unlikely that a renew operation will require speed. It is also much less likely for a user to alter two names at once than for the user to renew two names at once. So it is quite plausible that this knowledge could be used to inform the GUI about a reasonable default.
Thoughts on this?
We could also add autorenew or renew all to NMControl.
Well, I have a really cool 'unsafe' mode in mind : )
@phelixbtc True, but what advantage is there in using NMControl for that? I think that would just make it harder to use.
@JeremyRand Only that it's way easier to implement, at least partially it should be available already (nmcautoupdate Python script).
I have multiple domains that I wish to renew but I'm unable to select multiple domains and click on the renew button.
This forces me to pay the minimum fee for each domain.