GUI unnecessarly encourages address reuse #2429

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.

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.

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)

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

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.

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.

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.

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

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