Is it possible to have a QR code that generates a different address every scan?

[Pineapple30]

A restaurant may have a QR code to pay them with bitcoin, but the restaurant still wants to keep privacy of its income. So can they have a QR code that generates a different bitcoin address for their wallet every time someone scans it?

I was thinking in the form of a BIP that will standardize wallets to recognize this special type of QR code and will randomly generate an address that belongs to the wallet of the restaurant, but without having their seed of course.

How do you think such a thing would be implemented?

[1715175815]

1715175815

[1715175815]

1715175815

[1715175815]

1715175815

[1715175815]

1715175815

[1715175815]

1715175815

[Carlton Banks]

Basically, no

Because addresses are publicly viewable on the blockchain, if you display the same address QR for every customer to use, then all transactions received and made using that address are visible to anyone who scans the QR code. The solution is to generate a new QR code for each customer. It's not possible to use the same QR code to encode different information.

[Pineapple30]

You didn't understand my question. I'm asking if it's possible to have some kind of a script or code embedded in the qr code that the scanning wallet will be able to recognize and based on that code, generate an address that fits a specific wallet.

So when someone scans the QR code, he won't get the same address as the previous guy (it would be unlikely to happen, exactly like generating the same private key that someone else is already using)

[Carlton Banks]

It could be done, but it would be less private than the existing method.

The receiving wallet (for the business) would need the sending wallet (the customer's) to send a message to them telling which address in the wallet hierarchy had been used (there are too many to scan in an address chain, it's impractical to scan every possible address to see if you received funds every time a new block is found). And the customer would need an extended public key (xpub key) belonging to the business for it to work. And so if motivated enough, a customer can find out every address (or most of them) generated by the extended public key.  So when I say "less private", it means that anyone who knows that extended public key can find out every transaction done with every address from that xpub key. That's every transcation ever, if the business only ever uses 1 xpub key. The existing way is better.   

[qwk]

I'm asking if it's possible to have some kind of a script or code embedded in the qr code that the scanning wallet will be able to recognize and based on that code, generate an address that fits a specific wallet.

Possible, but not reliable. You can create a kind of public seed that allows the creation of new addresses.
So, you read the qr code and create a new address to send the coins to.
Unfortunately, without a sequence of some kind, you can not be sure if a certain address has already been created.
It's likely that many people will just generate the same (most likely the "first") address.

[RGBKey]

It's possible but not likely. They could do something like Samourai Wallet did by using BIP 47. That way, individual customers could create their own address chain with the merchant. However it would be cost and time prohibitive, and stop people that did not have phone wallets that supported it.

Much more easy is just a QR on a screen that changes when that address receives money.

[swirox]

May be if you use a third party wallet or a payment gateway but not directly with a btc wallet.
Simply because if you use the wallet QR code then it will only be 1 address unless you generate one for every transaction.

[odolvlobo]

An extended public key could be used to generate an unlimited number of addresses, but there would still need to be some coordination between the sending wallet and the receiving wallet. You might as well provide a unique address for every customer. It is easy enough to print one on the receipt or on a screen.

[Tyr808]

A restaurant may have a QR code to pay them with bitcoin, but the restaurant still wants to keep privacy of its income. So can they have a QR code that generates a different bitcoin address for their wallet every time someone scans it?

I was thinking in the form of a BIP that will standardize wallets to recognize this special type of QR code and will randomly generate an address that belongs to the wallet of the restaurant, but without having their seed of course.

How do you think such a thing would be implemented?

Possible if the scanner's output combines the QR input with one or more other inputs (one of which could be the EPOCH time segment the scan has been made).

[RGBKey]

An extended public key could be used to generate an unlimited number of addresses, but there would still need to be some coordination between the sending wallet and the receiving wallet. You might as well provide a unique address for every customer. It is easy enough to print one on the receipt or on a screen.

This would work, but I don't think OP is looking for this answer because in this situation, all the customers would be able to see all of the addresses ever used with it, removing the privacy.

[Kallisteiros]

The best practice is to generate a different bitcoin address for each visitor in the restaurant, which would result in a different QR code each time. Firstly, reusing the same address twice is discouraged. And second, trying to distinguish users by amount they sent or by correlating the time they do it is a very unstable strategy. What if the payment gets delayed? What if you have more than one checkout point/waiter with the smartphone? Generating a separate address for each check solves all problems.

If it was not for a restaurant, but, let's say, a public display with the address to send donations, and you wanted to hide the total, you could change the address each time you receive a payment there.

And finally, what you propose can fully be done only in complete hell-bent on privacy blockchains like Monero. In Monero, you can display your address publicly, a sender can see their transaction confirmed, but they can never know how much XMR went into the same address from other senders, and, by extension, how much total you have in your account.

[embarrasstor]

The best practice is to generate a different bitcoin address for each visitor in the restaurant, which would result in a different QR code each time. Firstly, reusing the same address twice is discouraged. And second, trying to distinguish users by amount they sent or by correlating the time they do it is a very unstable strategy. What if the payment gets delayed? What if you have more than one checkout point/waiter with the smartphone? Generating a separate address for each check solves all problems.

If it was not for a restaurant, but, let's say, a public display with the address to send donations, and you wanted to hide the total, you could change the address each time you receive a payment there.

And finally, what you propose can fully be done only in complete hell-bent on privacy blockchains like Monero. In Monero, you can display your address publicly, a sender can see their transaction confirmed, but they can never know how much XMR went into the same address from other senders, and, by extension, how much total you have in your account.

Definitely agree. Note that although right now bitcoin is under public blockchain, the industry is promoting and concerning about the development of privacy coin. In the wechat payment system in China, our accounts can provide a new and different QR codes for new transactions. It is a good idea about generating different QR code to avoid duplicate transaction at the same time or cannot record correctly.

[d5000]

Isn't a "stealth address" or a "payment code" (BIP 47) exactly what the OP wants?

Here's a little article about payment codes.

However BIP47 seems to require an additional "notification transaction" (@RGBkey already mentioned "cost and time", although I think it should be possible to automate everything) so the fee would be doubled. It's one per customer, so it would be fine if you re-visit the store or restaurant every now and then, but not if it's an one-time payment.

I don't know if stealth addresses had this problem, too. And don't ask me about LN compatibility ...

[danda]

Possible if the scanner's output combines the QR input with one or more other inputs (one of which could be the EPOCH time segment the scan has been made).

interesting, can you expand on this idea? 

my musings:

this requires a new derivation scheme, does it not?  eg, one could not use a standard bip32 xpub for this purpose.  But supposing both receiver and payer's wallet support the derivation scheme based on (seed + timestamp) then I suppose that to find payments the receiver's wallets has to derive all possible keys in possible time ranges.  This seems a bit computationally expensive and begs the question of what resolution to use for timestamp (milliseconds, seconds, minutes, hours).   Too large and addresses may be re-used many times.  too small and the number of keys to check becomes huge.

or is there a better way?

[HCP]

A restaurant may have a QR code to pay them with bitcoin, but the restaurant still wants to keep privacy of its income. So can they have a QR code that generates a different bitcoin address for their wallet every time someone scans it?
How do you think such a thing would be implemented?

A QR code that actually linked to a URL for a website that then generated unique addresses or that redirected to a newly generated "bitcoin:" URI could work if you need a "static" QR code (ie. you were printing it on a poster or business card etc)

QR Code -> https://www.somedomain.com/generateNewAddress.php -> bitcoin:bc1newlygeneratedaddress?&message=Payment&label=MyStore

Refer here for Bitcoin URI: https://bitcore.io/api/lib/uri

[bob123]

A QR code that actually linked to a URL for a website that then generated unique addresses or that redirected to a newly generated "bitcoin:" URI could work if you need a "static" QR code (ie. you were printing it on a poster or business card etc)

QR Code -> https://www.somedomain.com/generateNewAddress.php -> bitcoin:bc1newlygeneratedaddress?&message=Payment&label=MyStore

But unfortunately this won't allow the QR code to be scanned with a mobile wallet app (like it is mostly done when paying via scanning QR codes).
This is quite a disadvantage regarding usability (imo).

For business cards, this probably is the cleanest solution. But for a restaurant with a QR code (at the door/windows, or wherever), i'd rather choose a screen displaying the QR code (which changes it after reach TX).

[Carlton Banks]

Isn't a "stealth address" or a "payment code" (BIP 47) exactly what the OP wants?

Here's a little article about payment codes.

However BIP47 seems to require an additional "notification transaction" (@RGBkey already mentioned "cost and time", although I think it should be possible to automate everything) so the fee would be doubled. It's one per customer, so it would be fine if you re-visit the store or restaurant every now and then, but not if it's an one-time payment.

Yeah, there's a few reasons BIP 47 didn't take off. Clever idea, but not really useful enough given the trade offs.


Couldn't this (a static payment identifier for face to face businesses) be done using a Lightning network node name? I think so. Much more appropriate for this use case in other ways too.

[RGBKey]

Isn't a "stealth address" or a "payment code" (BIP 47) exactly what the OP wants?

Here's a little article about payment codes.

However BIP47 seems to require an additional "notification transaction" (@RGBkey already mentioned "cost and time", although I think it should be possible to automate everything) so the fee would be doubled. It's one per customer, so it would be fine if you re-visit the store or restaurant every now and then, but not if it's an one-time payment.

Yeah, there's a few reasons BIP 47 didn't take off. Clever idea, but not really useful enough given the trade offs.


Couldn't this (a static payment identifier for face to face businesses) be done using a Lightning network node name? I think so. Much more appropriate for this use case in other ways too.

Isn't a "stealth address" or a "payment code" (BIP 47) exactly what the OP wants?

Here's a little article about payment codes.

However BIP47 seems to require an additional "notification transaction" (@RGBkey already mentioned "cost and time", although I think it should be possible to automate everything) so the fee would be doubled. It's one per customer, so it would be fine if you re-visit the store or restaurant every now and then, but not if it's an one-time payment.

I don't know if stealth addresses had this problem, too. And don't ask me about LN compatibility ...

Using the lightning network, you could generate new payment request QRs for each payment and keep privacy, but it would require users being able to use the LN.