Scanning a QRcode that does not include an address component crashes about bitcoin-wallet

[schildbach]

BIP21 formatted QR codes require an address. Even if I extend it with BIP72, I will continue requiring an address (and an amount, if present in the payment request) in order to link the URL to the payment request. For backwards compatibility I expect services to use these fields anyway.

[mikehearn]

That's not compliant with the spec, which says

If the "r" parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be omitted (the URI will be of the form: bitcoin:?r=... ).

That means it's up to the creator of the URI if backwards compatibility is required or not, not the wallet author.

I don't understand what you mean by "link the URL to the payment request"? If a payment request is present the data in the URI is ignored. At any rate, crashing with a NPE is definitely the wrong thing to do.

[schildbach]

We talked about the linking several times. The goal is I can be sure the payment request is from the person who showed me the QR code. Since up to now no better solution was agreed on, I will use what I have.

The spec is "draft" for a reason.

[mikehearn]

Why would someone show you a QR code with someone else's payment request on it?

[schildbach]

The "request for the payment request" can be MITM'ed. X.509 is of no value for face to face payments.

[mikehearn]

Sure, I'm not saying generate addressless qr codes yourself. Just don't
crash when reading them :)
On 7 Feb 2014 18:48, "Andreas Schildbach" [email protected] wrote:

The "request for the payment request" can be MITM'ed. X.509 is of no value
for face to face payments.

—
Reply to this email directly or view it on GitHubhttps://github.com/schildbach/bitcoin-wallet/issues/44#issuecomment-34480251
.

[schildbach]

Sure, I'm with you on that. I will fix this crash shortly.

[schildbach]

Fixed.