[yunohn]

> memo/credit-to field in the transaction as the article mentioned.

I assume there should be an API to prefill this, making it easier for humans. Could literally just be the unique order ID or a hash thereof.

> I guess you could ask users what addresses they are sending

Why would you need to ask? Isn’t there a captive payment portal API, like with popular wallets eg Metamask?

> I’m not sure what you think is inefficient about spending microseconds generating a public/private key pair.

The problem is not in generation. Firstly, it pollutes the blockchain with single use addresses, though I guess maybe people don’t care. But AFAIK, the website would need to pay fees on a per-wallet-transaction basis when cashing out right? Payments need to pay fees anyway, but cashing out from a single wallet would be cheaper than this mess.

[NavinF]

> Isn’t there a captive payment portal API

probably? Normally you’d just say “send $5 to xyz” and the user copy-pastes the number and address to their wallet. It’s like sending a wire transfer.

> Firstly, it pollutes the blockchain with single use addresses

UTXO blockchains like Bitcoin were designed with the assumption that each address will only be used for 1 transaction for privacy reasons. There are no per-address fees to cash out. The fees sorta scale with how many UTXOs (incoming transactions) you’re combining to form an outgoing transaction.

[yunohn]

Yep, I understood that. My point is cashing out 500 payments from single use wallets leads to 500x the transaction fees versus 1 main wallet, right. The customers would anyway pay the incoming fees, but outgoing gets expensive esp for smaller txes. Why is this optimal for a store?