[ben165]

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.

[NavinF]

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)

[ben165]

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.

[Yeahsureok]

> But with every address you create your daemon has to look for changes there

How exactly do you think this differs from a single address getting updated? On a lite client this is nothing, on a full client nothing has changed.

There's a reason nearly every single solution involves an individual address tied to a single public key.

[ben165]

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?

[tromp]

> 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.