Maybe I misunderstand the author’s goal, but using the “random number” from the payment amount and regularly checking wallet balance, just seem incredibly rudimentary compared to an actual payments system…
Yes. And using a "unique" number between 0 and 99 gives you an indication of how many transactions this system is designed to support. (Not many, it seems to me.)
The random number is just a temporarily solution. The ideal one would be to use the memo field with an unique random string which contains all kind of characters. With this option you would have infinite payments.
The number solution can be improved if you search in the database for "free" numbers. I set the maximum payment time to 12 minutes. In this case, you can offer 100 payments per 12 minutes. I should update the article with this information.
Yeah normally you’d create a new address to receive payments from each user. Addresses are essentially free so this is how everyone else figures out which user deposited money into their cryptocurrency wallet.
I did this in my first project. As I said, UTXO blockchains are intended to work like that. But with every address you create your daemon has to look for changes there. Your wallet file can grow like crazy if you don't built some spam protection in your system.
For blockchains with the balance model you actually use only one address. There are solutions for Stellar to provide an unique address but this is not implemented yet.
The memo tag/field is the way to go. But as I said, it isn't widely implemented.
Ehh how does Coinbase deal with this? They gave me a unique deposit address for Etherium which is account based (not UTXO) and IIRC they’ve never asked me to fill out a memo field for any currency.
If you do use the memo field, how do you deal with user error when they copy-paste the wrong number? Banks have humans guessing and correcting wire transfer instructions. Both you and the user will burn a transaction fee each way if you automatically refund unknown transactions.
It’s been a long time since I’ve messed with wallet APIs, but I’m pretty sure you’re using the wrong API. There should be some way to consume a stream of (row_id, transaction) tuples. That way you’re never polling every address. Instead you deal with relevant events that affect any of your addresses as they happen (which is not very often. A whole blockchain might do 15 transactions/second and you see ~0% of that)
It depends on the exchange provider. I use Kraken and they provide an unique address for every costumer. But I read some Exchanges require the memo field especially for Stellar addresses.
If you use a memo field and there is an error the order won't be found in the system. In this case, you can write a script which sends the funds back to the address - fees. In this case you don't lose money and you don't need humans to interact. A more difficult problem would be if sb. sends a wrong amount. Then you have to interact with the costumer.
Yes, you're right. Polling is bad but the easiest solution. The best one would be to listen to incoming transactions and take action if a new one comes in. I'm going to use this solution if I continue the project.
As I understood it you have an initial address when you create a wallet for example on a Litecoin core node.
All addresses you create after this initial address are deterministic depending on their position. It's like you add just a number to the first address. But they are all unique otherwise sb. would see these addresses belong to one wallet.
And because they are unique your daemon has to watch or compare incoming transactions with every address you created to monitor payments. I might be wrong, but otherwise how does it work?
> But with every address you create your daemon has to look for changes there.
On a Mimblewimble blockchain both sender and receiver need to sign for a transaction. So you could interact with the payer to construct a transaction which you as receiver sign last and then you can publish it yourself.
That also seems like an inefficient way to handle transactions. This is honestly surprisingly, I always assumed crypto had better payment solutions! After all, that’s what they all proclaim to be - not speculative gambling or scamming.
Ehh I guess you could ask users what addresses they are sending from or use the memo/credit-to field in the transaction as the article mentioned. The latter is how bank wire transfers work, but it’s inefficient for humans so nobody does that.
I’m not sure what you think is inefficient about spending microseconds generating a public/private key pair. This is done once per user. You then verify signatures to “accept” payments.
> 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.
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.
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?