Bitcoin-Qt: show address labels when using bitcoin: URIs #2994

• ensure that user-defined address labels are shown in the sendcoins dialog, when using bitcoin: URIs or insecure payments (no changes to the secure payments UI)
• favors supplied labels over user-defined ones from addressbook

Updated to prefer user-defined labels over supplied ones, so saved labels in the users address book are not overwritten.

Rebased to fix a merge conflict.

@laanwj ping

I'm not so sure about this. I'd like it to show the merchant's specified information at least in the payment form. When will this be triggered? The merchant shouldn't be reusing addresses in the first place for secure payments.

Also how does this fit into avoiding address reuse and deprecating the address book into a list of historically used addresses? We should not provide any special conveniences for reused addresses (and later on, probably associate labels with specific transactions not addresses).

@laanwj This change just ensures that address labels, that ARE in our address book are shown, when using a normal bitcoin: URI or insecure payments. And because of that ensures we don't overwrite labels in the users address book.

So for secure payments there is no change at all, we will see the merchant displayed and no address or label in the sendcoinsdialog. I'm not sure if I'm with you, that this change is related to address re-use at all, it just brings our normal sendcoins mechanism (chose address -> label from address book is displayed in sendcoins) into play when using URIs or insecure payments.

Rebased and fixed a merge-conflict.

@laanwj I would love to get an agreement on this pull, see my comments above :).

I'm just not happy that this adds more special cases, more complexity to the address book code, even though nothing is really broken.

So to be clear, you think it's fine if some URI or payment-request is overwriting your user-defined labels? It's also fine to not recognize it's an address that is in your addressbook?

The other way around, if an URI doesn't specify a label currently our addressbook isn't even searched for a label ;). Thast is what I could change this pull to, so we have at least same functionality as when using sendcoins ourself.

Yes, I think the two should be separate. When opening a bitcoin URL, the program should display the information from the URL. After selecting an address from the address book, it should display the label from the address book. These are disparate sources of recipient information, so trying to combine them will only confuse things.

Would you agree to display our user-defined label, if the URI or payment-request doesn't contain any information?

Updated: Changed back so that supplied labels override user-defined ones, but displays user-defined labels, if there are any and none was supplied.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/6581b893af9e8aed9aeabae87041aaf0faccd49b for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

@diapolo agree to close this one? As we want to reduce interaction of payment requests with labels, it makes no sense to show user-defined labels with payment requests in any circumstances.

Yes that's fine then, I'll perhaps just introduce the updateLabel() function in another pull, because I remember it was a pain looking for that code ^^.

Yes, that's fine -- though be careful touching any of the address book view stuff, as I'm now working on reorganizing it as I planned before. Finally making a real ReceiveCoinsDialog that doesn't show a list of receiving addresses but a form to request payment.