A couple of months ago I have considered for a while to start something like the described BDPIC. In my opinion, it is only possible if you know the involved merchants very well. I did not want to have to whitelist merchants, so I decided not to attempt it.
The problem is this: Let's assume everyone can sign up for your BDPIC. If I'm an attacker, I set up a merchant account and can now pay myself through BDPIC any amount I want at a small fee. If there are limits in place, I just open multiple merchant accounts and bundle them.
With this setup, I can now attempt to double-spend until I succeed. The only conditions is, that the total amount of fees I have to pay is less than the payoff for a single successful double-spend. This will most likely be the case, unless you charge huge fees. Let's assume you charge 2% on all transactions (already on the expensive side, I would argue), then I as an attacker can try 50 times before it becomes unprofitable. I described one attack that can be performed here:
http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhbv1 . The attack described there can not be detected by monitoring the network and if you have 50 tries you need to have a little bit more than 2% of total hashing power to make it work.
Having 2% of the network would be in excess of 100 Ghash currently see
http://bitcoin.sipa.be/). That kind of hardware will set you back by at least $50,000 (if not closer to $100k). If you're talking about relatively small value transactions, you will need to pull off a lot of double spends to make it worthwhile. I think if you employed counter measures once a double spend is successfully executed, you could easily undermine the economics of such an attack. For in person transactions, where instant confirmation is most needed, the economics of such an attack are already not viable. For online transactions, counter measures could be as simple as resorting to full confirmations in the event of a successful double spend.
(btw, some on this thread have mentioned listening for conflicting transactions…but that's not actually how it would work…you would receive your transaction through the network and then you listen for additional nodes reporting that same transaction…what you want is a high percentage of nodes reporting your transaction…if they report your transaction, it means that they consider it to be valid (and would have discarded any conflicting transaction)…you'll want to place more weight on mining nodes if you can determine them since you'll want to see that there are miners working on putting your transaction into a block)
