Restore ability to display addresses in GUI #5861

pull luke-jr wants to merge 1 commits into bitcoin:master from luke-jr:gui_restore_addresses changing 5 files +25 −1

luke-jr commented at 3:14 PM on March 6, 2015: member

This reverts commit bdba2dd000f030b1dce3d2bc6caef84929438679 (PR #4610). I don't understand why it was removed in the first place, and didn't get an answer on IRC when I inquired a week ago. But since the commit message states "no-one cares about" the option, it seems reasonable to restore it so long as it is cared about.

Note: This needs adapting if #5833 gets merged first. git will NOT detect the conflict.

Restore ability to display addresses in GUI

This reverts commit bdba2dd000f030b1dce3d2bc6caef84929438679.

de4939a440

laanwj commented at 3:56 PM on March 6, 2015: member

NACK. See #4580 for rationale on removing this feature. Apart from you, I've heard no one complain about this.
luke-jr commented at 4:00 PM on March 6, 2015: member

#4580 does not make sense. It states that "addresses are always displayed", but they aren't... right now there is no way to get them displayed.
fsb4000 commented at 1:11 PM on March 8, 2015: contributor

ACK
dgenr8 commented at 12:01 AM on March 9, 2015: contributor

@luke-jr On recent master, I see addresses in the transaction list. Have you tried a fresh wallet.dat?
luke-jr commented at 12:37 AM on March 9, 2015: member

@dgenr8 No, I've read the code, and it does not show addresses in normal circumstances (ie, labels set).
fsb4000 commented at 3:25 AM on March 9, 2015: contributor

@dgenr8 there are no addresses, only labels...
dgenr8 commented at 6:30 AM on March 9, 2015: contributor

@luke-jr I wonder if, like me, @kazcw has no labels, so he thought the option was broken. The property and tooltip text should read "Always display addresses in transaction list"
laanwj added the label GUI on Mar 9, 2015
laanwj commented at 10:51 AM on March 9, 2015: member

So from a UI perspective why would you want to see addresses in this list? Do they convey any meaning to you? It's like having a 'SHA256 hash' column in your mail client.
luke-jr commented at 12:06 PM on March 9, 2015: member

@laanwj It occurs to me I have no good use case for it (I was trying to get a list of used addresses matching a given label term, which is something better done via RPC anyway and has no GUI value except when addresses have been reused). Leaving this open for now in case @fsb4000 has some better reason for it.
dgenr8 commented at 4:42 PM on March 9, 2015: contributor

Of course addresses convey meaning. They are the actual ID that is exchanged OOB between parties. I'm not going to read my private label to somebody when he claims he didn't receive payment.
fsb4000 commented at 2:21 AM on March 10, 2015: contributor

Another reason: If you have multiple addresses under one label. For example: donations. Different addresses for different projects, but one label. Of course, you can make a longer labels include a fuller description, but I do not really like long labels...
laanwj commented at 11:45 AM on March 10, 2015: member

A while ago there was extensive discussion on the mailing list, that it was bad idea to expose addresses to the end user. This is in line with increasing usage of payment requests, and other innovation.

Of course there are some edge cases where you do want the address, but in that case you can click on the transaction to get full information (or even hover?). It seems pointless to show the address for every single transaction. So I'm closing this.
laanwj closed this on Mar 10, 2015
rebroad commented at 4:36 PM on March 1, 2016: contributor

utACK
luke-jr referenced this in commit 1b5f1ac691 on Jun 27, 2016
luke-jr referenced this in commit 8d22335909 on Jun 27, 2016
DrahtBot locked this on Sep 8, 2021

Contributors

Labels

Linked (view graph)

#4610 qt: Remove an obscure option no-one cares about #5833 GUI: Label fixups