Topic: Collaboration between pools could make accepting 0-confirmation transaction safe - page 2. (Read 2368 times)

A pool must check if there is any conflicting transaction already present and if true then refuse to sign the multi-signature transaction.

It may still work even if hundreds of pools and miners are required to sign the transaction. The limiting factors are size of the transaction and subsequent transaction fee, complexity of maintaining trust relationships between participating pools and heavy miners, turnaround time to get transaction signed by all participants.

Nice, didn't see that!

I'm not too worried about double spends; the time frame you have to run away with your product, the loops you have to jump through and the small amounts people will only accept with 0 confs... just not worth it.

I pay you normally without using this system, then use the pool-signed txn to pay myself in a doublespend.  It would make attacks very reliable.

Besides, if your idea is predicated on large centralized pools I wouldn't count on it remaining viable. They're bad for the decentralization of bitcoin and present single points of failure. With the rise of asic mining making miners with single GPUs insignificant I expect to see mining move towards decentralized pooling techniques like p2pool, or the eligius memorypool mode.

Alright, consider next scenario:
A buyer wants to execute bitcoin transaction and have a product released couple seconds after pressing Ok. A seller constructs multi-signature transaction that has to be signed by buyer and several major pools, so there would be more then 50% of hashing power behind that transaction.
By signing the transaction a pool gives it's trustworthy word that in case everyone else listed would sign the transaction then there will be a version of blockchain where this transaction has predetermined number of confirmations, e.g. 6. The transaction should also include small fee to every pool, so it would worth for an operator to establish relationships with other pools to ensure that everyone follows the rules, although the total fee suppose to be lower then 0.75%-0.4% fee of ZipConf.

This targets to remove the threat of Finney attack, which can't be detected just by listening to Bitcoin network for a conflicting transaction. To execute the attack an attacker has to have longer blockchain for a short period of time, but hides it until a malicious transaction executed and only then broadcasts the blockchain making the transaction orphan.

Cons: this gives power to the pools to arbitrary reject a valid block and continue to mine on shorter blockchain, would it be possible to abuse it despite that the whole process is transparent?