Verifying bitcoin payments manually, how to determine concrete payment payment

[VictorBTC]

Hi,

I am a developing a simple bitcoin payment gateway leveraging Electrum servers for checking balance of generated addresses.

Initially I had the following idea.

1. A customer makes an order
2. A new bitcoin address generated from a BIP32 wallet
3. The generated address is assigned to the order id
4. As far as we have amount of the order, we periodically checking whether funds were received to the generated address
5. In case funds are received and a transaction is confirmed order is marked as paid

But as I have explored, most of available wallets have limited generated receive addresses. But in case of the flow above I need to generate a new address for each new order.

Generally that is not a problem from the math perspective, but this will introduce some problems when I need to spend money from the wallet or just calculate total balance, because there could be thousands of addresses.

We can generate some limited amount of addresses for instance 20 and then randomly select from this list.
However in that case I don't know how to validate payments. There are a lot of problems that I may encounter in that case.
For instance, when several orders with the same total price are made.

Please suggest a solution for that problem ?

I would be grateful for any help

[1714156201]

1714156201

[1714156201]

1714156201

[1714156201]

1714156201

[1714156201]

1714156201

[1714156201]

1714156201

[1714156201]

1714156201

[Evil-Knievel]

Why don't you just use something more simple like that:

1. Pick a master private key d
2. Assuming each order of yours has a unique order id x, generate a bitcoin address from a derived private key:  d_order = d + SHA256d( x | d ) for each order
3. Each order has a deterministic deposit address, and the derived private key can be always recovered from your master private key and the order ID. No need to "assign" or "pregenerate" anything.

[VictorBTC]

Thank you so much, but this won't solve the main problem.

I don't want to generate a thousands of new addresses for each order.
I want to reuse some pool of addresses for different orders.

For instance in case of 20 addresses I can have a chance to have several pending payments for a single address.
How to solve this problem and verify that a concrete order was paid?

[TryNinja]

May I know why do you want to limit yourself to 20 addresses?

[odolvlobo]

Perhaps you could split the process into two.

The first process generates private keys and tracks new orders. Assuming that the keys are generated deterministically, it would have no problem tracking millions of addresses.

When the first process detects that an order is paid, it hands the private key to the second process, which maintains the wallet. This way the wallet only tracks the keys with funds.

[bitmover]

The most common and better solution is use one address for each client/order

It's more organized and simple. You will never run out of addresses, don't worry about that. So there is no need to use a limited number of addresses

[buwaytress]

I'm also curious to understand why you would want to limit the number of addresses generated for a user? You might also consider that some users would avoid buying more than once (or use multiple accounts) if they see that there's a fixed deposit address. Bitcoin addresses were always meant to be single-use and a considerable number of Bitcoin users still adhere to that recommendation.

Assuming the reason for that can't be circumvented, perhaps you also only assign the transaction ID to the order ID? Ie. Once the tx is broadcast, its ID is linked to the order, so presumably, each new order is only linked to tx ID, not address.

[VictorBTC]

Thank you for answers, so generally it is fine to generate a new address for a new order.

The only one limitation I see here that not all wallets support checking balance and operating fund for a wallet that has a lot of derived addresses.

However i always can do this by myself iterating over generated addresses manually and collecting funds, am I right ?

[bob123]

The only one limitation I see here that not all wallets support checking balance and operating fund for a wallet that has a lot of derived addresses.

Actually every (proper) wallet does that.
They check each address one-by-one (increasing a 'counter' when deriving keys) and stop when they have found X addresses without a transactions (X = address gap limit; can be set in settings).

However i always can do this by myself iterating over generated addresses manually and collecting funds, am I right ?

Of course.
You can always do it yourself. And you can always use a wallet to do it for you (electrum does that pretty nicely, gap limit can be adjusted easily and consecutive checking for balances works flawlessely).


You won't have any disadvantage when using a new address for each customer/order. In fact you will keep the privacy of your customers and you will somehow 'hide' the total amount of money/transactions you received.

[Kallisteiros]

Iterating over thousands of addresses, querying them over the network one by one, is very inefficient and slow. Here's what you can do instead:

• Wait for a new block to be discovered and download it
• Iterate over all transactions in the block and leave only the transactions with the destination address matching one generated by you (this is not really slow since you're doing this locally and querying against the local database)
• Perform necessary additional verifications (like tx amount >= order amount) and mark the order as paid

You can greatly simplify the process by running your own Bitcoin Core node because Bitcoin Core software does all that automatically for you, with added bonuses like automatic address generation, specifying what level of confidence (number of confirmations) you need for the software to notify you of the new incoming transaction etc. It will also help with any withdrawals, calculating the total balance and combining the inputs from all the addresses to create an output transaction. Running the node in pruning mode (with -prune flag) will save you much space.