namecoin / namecoin-core

Namecoin full node + wallet based on the current Bitcoin Core codebase.
https://www.namecoin.org/
MIT License
461 stars 147 forks source link

UI to renew multiple domains #377

Closed indolering closed 3 years ago

indolering commented 10 years ago

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.

domob1812 commented 10 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.

JeremyRand commented 10 years ago

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.)

phelixbtc commented 10 years ago

@JeremyRand You're right of course but the client does link the name_ops via the outputs anyway...

JeremyRand commented 10 years ago

@phelixbtc I'm not sure what you mean, what is being linked right now?

domob1812 commented 10 years ago

@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.

JeremyRand commented 10 years ago

@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.

indolering commented 10 years ago

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 : )

indolering commented 10 years ago

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.

JeremyRand commented 10 years ago

@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.

indolering commented 10 years ago

@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.).

JeremyRand commented 10 years ago

@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.

indolering commented 10 years ago

@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. : )

indolering commented 10 years ago

... because humans don't do well with modes and they are the source of a significant amount of error.

JeremyRand commented 10 years ago

@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?

phelixbtc commented 10 years ago

We could also add autorenew or renew all to NMControl.

indolering commented 10 years ago

Well, I have a really cool 'unsafe' mode in mind : )

JeremyRand commented 10 years ago

@phelixbtc True, but what advantage is there in using NMControl for that? I think that would just make it harder to use.

phelixbtc commented 10 years ago

@JeremyRand Only that it's way easier to implement, at least partially it should be available already (nmcautoupdate Python script).