Chaining unconfirmed raw transactions

Question

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.

Answer 1

How do I check and design a transaction so that I can send 3 BTC to User 2?

You reference the 5 BTC unconfirmed UTXO for your next transaction and pay 3 BTCs to User 2 and 2 BTC back to yourself.

Can I chain unconfirmed transactions?

Yes, you can.

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?

Yes, there is a possibility. The latter transaction will not be discarded, it will be in another node's orphan tx set so as long as that limit has not been met. So there's also the possibility that some node's orphan tx set is full and your orphan tx will get rejected outright.

Tx1 (unconfirmed, accepted) <- Tx2 (unconfirmed, not yet visible) <- Tx3 (unconfirmed, accepted && orphaned)

The above transaction chain is a valid chain of unconfirmed transaction.

Finally, is there a better way to do this?

Not quite. The recipient can use CPFP to bump the fees, so the transaction fee that pays for the entire transaction chain becomes greater. That increases the probability of immediate confirmation. Otherwise, you as the payer can use RBF to bump the fees.

For an outgoing bitcoin account that only makes payments to users, what would be the best practice?

Only pay from confirmed transactions, otherwise pay sufficient transaction fees which results in probable immediate confirmation. You as the payer would still have the opportunity to bump the fees with RBF to provide better user experience. Or you may insist your users to use CPFP to accelerate their receipts.

Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?

Exchanges don't really care about the speed at which recipient receives their fees, they usually pay a decent transaction fee so that you'd receive your transaction in "due course".