Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GUI unnecessarly encourages address reuse #2429

Closed
gmaxwell opened this issue Mar 30, 2013 · 7 comments · Fixed by #3099
Closed

GUI unnecessarly encourages address reuse #2429

gmaxwell opened this issue Mar 30, 2013 · 7 comments · Fixed by #3099

Comments

@gmaxwell
Copy link
Contributor

Providing a stack list of past receive addresses as a top level GUI element encourages reuse, it makes addresses seem like something scarce which should be conserved. It also can result in people accidentally sending coins to addresses created prior to wallet encryption.

The interface should probably be adjusted to make it clear that used addresses are used and shouldn't be reused, e.g. by only displaying the initial digits of all but the most recent address and requiring context click to get details.

@laanwj
Copy link
Member

laanwj commented Mar 30, 2013

If the workflow for receiving coins is "1) create a new receiving address..." then maybe the message could be improved as well, it's currently: "These are your Bitcoin addresses for receiving payments. You may want to give a different one to each sender so you can keep track of who is paying you."

When we're in this discussion anyway: the send UI also encourages address reuse, by offering an "address book" of past sending addresses. But TBH I don't think much can be done here until there is a standardized payment protocol of some kind.

@qubez
Copy link

qubez commented Mar 30, 2013

Agreed. The default address should be shown on Qt as it was in the original client. However the language should indicate the temporal nature of the current address shown; "Your Bitcoin Address" makes it seem like this is the only one that you get and it won't be automatically changing. (screenshot for wx reference)
oldAddress

Probably what is easiest to interpret would be an upper pane on "Receive coins" that shows the "current receiving address" with a "label this address" option, and a lower pane called "previous addresses" where labeled addresses are moved. They can be marked "used" when an address has received a payment (to discourage multiple payments and reduce the balance-containing addresses with their pubkeys previously broadcast).

The text "You may want to give a different one to each sender..." -> "you should give out a new address for each payment you wish to receive."

@laanwj
Copy link
Member

laanwj commented Mar 31, 2013

No, the "default address" will not be back. It encourages unlabeled addresses, it causes automatic empty labels to be created, and confuses users because there is a "changing address". No way we're going back there.

I'd propose changing the "Receive" tab so that the primary function is not a list, but a form in which a payment request can be created. Similar to what is now the QR code dialog. A workflow of

  1. fill in label
  2. fill in amount (optional)
  3. click "Make payment request"
  4. show the new receiving address that can be copy/pasted as well as a QR code and Bitcoin: URI

It is then made clear to the user that he should give this address to the person that wants to send him coins.

Listing the current receiving addresses is secondary; it could remain at the bottom of the tab, or behind a special menu item.

@rebroad
Copy link
Contributor

rebroad commented Apr 1, 2013

How about showing "your last used" bitcoins address, and "your new bitcoin address" for one which has not been used? I've already encountered problems with "new address" giving me an address that's already been used for change. I think "new address" should only ever give unused addresses.

@gmaxwell
Copy link
Contributor Author

gmaxwell commented Apr 6, 2013

Adding to this, apparently the address use triggers some OCD in some users and they really want to "delete" addresses which are "cluttering" the list. Any revisions here should be mindful of that and help those people out without creating a coinloss risk.

@laanwj
Copy link
Member

laanwj commented Apr 14, 2013

@rebroad: dealing out change addresses as "new" sounds like something that warrants a seperate issue

@laanwj
Copy link
Member

laanwj commented Apr 24, 2013

Ugh. More indications that low-level abstractions such as addresses and individual keypairs are dangerous to users. They should just regard a wallet as a wallet.

https://bitcointalk.org/index.php?topic=185185.msg1927752#msg1927752

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants