Retrieving all the funds from BIP32 derived wallets

Question

An ecommerce site is using BIP32 wallets for receiving order payments from a tree of child keys where each leaf node is unique to one purchase transaction.

Is it common for the site to immediately send the received coins to its superwallet (master node) upon X confirmations? If so, how would you go about sending all the coins in the entire tree of child keys (which can be tons of nodes depending on the number of transactions) to the super wallet?

And how would u know when a payment is sent to one of the derived addresses?

Let's assume the case with a derivation path of m/k'/0/i, where m is the master node, ever user has a k node and i is his i'th purchase transaction.

Answer 1

Is it common for the site to immediately send the received coins to its superwallet (master node) upon X confirmations?

Aggregating your assets coming from tons of transactions into a single address is not necessary, but it's not that uncommon. It can be practical if the volume of addresses holding some coins becomes unmanageable (the exact number depends on your wallet software, system resources, etc.).

If this happens, you can simply send those coins in a big transaction with multiple inputs (in order to save on tx fees) to an address managed by your "master node".

And how would u know when a payment is sent to one of the derived addresses?

The same way as you knew before. You can keep watching the address after you've transfered the funds to you master address. If needed, you can make another aggregation transaction later again.

Answer 2

Is it common for the site to immediately send the received coins to its superwallet (master node) upon X confirmations?

No. Not at all and would normally be considered very bad practice as in bitcoin you don't spend from addresses but from transactions, so "accumulating" in one address doesn't really work. Sending from that address would again have to reference all the forwarded transactions. (There are special cases like green address in its original implementation but no, that's a thing of the past.)

And how would u know when a payment is sent to one of the derived addresses?

You watch the bitcoin network? Either through proxies or with a full node. Check out the insight.bitpay.com API.

Let's assume the case with a derivation path of m/k'/0/i, where m is the master node, ever user has a k node and i is his i'th purchase transaction.

I would strongly advise to hold that logic in the server, only.

eCommerce sounds like one central server, so there is really no big need to fan out too much in the HD wallet structure. You should also look into BIP44 on transaction discovery.

Your business logic has to keep track what purpose an address has but if that website never has to send refunds, it would typically only have an extended public key. Now if it receives to

m / 44' / 0' / i' / 0 / j

any bip44 compatible wallet would find and be able to spend the funds if you provided it with at least the xpriv key for

m / 44' / 0' / i' / 0

but typically

m / 44' / 0' / i'

One minor thing you have to keep track of, is the gap between addresses that don't receive a payment. If your server observes a gap of more than 20, you would have to help your wallet to find those funds if it's strictly bip44 which would only bridge gaps up to 20. If your last transaction is to index 1220 and you don't see transactions to 1255 and 1257, you could send a satoshi to 1239 and your wallet would find the rest.