Before implementing batch-sending to dispensers, it would be wise to analyze the benefits, costs, risks and alternatives.
Here’s the github issue : Just 1st dispenser dispenses when batch-sending sats to multiple dispensers · Issue #1148 · CounterpartyXCP/counterparty-lib · GitHub
My understanding is far from perfect. Would be nice to have others chime and correct me wherever I’m wrong.
- the current first-output only rule may appear as a bug for end-users.
- batching-sending makes it faster and cheaper to buy from multiple dispensers
- opens up for possibly (after more upgrades) to buy XCP and make an issuance all at once? (how exactly would this work?)
- New table in CP DB
- Need to check every output of every bitcoin transaction transaction against open dispensers. I would like to see if this noticeably slows down parsing of blocks.
- Will this influence tx types where the first output is the recipient? This applies to classic send (hardly used) and issuance (first output is new owner).
- Change output can trigger a dispense. Is it possible to buy from own address?
To my Compressed XCP Transactions proposal (not formal CIP yet) I’ve added a rule where outputs meant for dispensers are specified in the Counterparty batch sequence. This makes a logical way of having a chain of xcp instructions all within one btc tx, eg.
- Buy 0.5 XCP from dispenser
- Issue MYASSET
- Sell MYASSET on the DEX