I'm currently working on a system that provides payouts to users from a bitcoin address as they 'burn' other assets on the site (think something like ShapeShift, where you pay someone BTC to get some other cryptocoin, and you pay this coin back to get BTC).
I'm using public apis to build and send raw transactions using bitcoinjs. However, I have the issue that I sometimes need to wait for previous transactions to confirm before I can send more out. This will often involve bitcoins that will - no matter the result of the confirmation - be mine.
Here's an example. I have 10 BTC, and I have posted a tx to User 1, sending him 5 BTC and 5 BTC back to myself. Now I am sure that I have 5 BTC in my account (regardless of whether the tx confirms) - but this isn't easy to confirm for me, especially when multiple such txs get chained and a lot more inputs and outputs get involved. How do I check and design a transaction so that I can send 3 BTC to User 2?
Can I chain unconfirmed transactions? I understand this would be dangerous if any of the transactions failed (insufficient fee, corrupt data, etc). Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?
Finally, is there a better way to do this? For an outgoing bitcoin account that only makes payments to users, what would be the best practice? Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?
I understand there is a similar question here, but it does not discuss transaction ordering, and my concern is primarily about setting up an outgoing Payment system by which I can send multiple outgoing transactions per block as payouts.