As far we know, some payment processors and users accepts 0/unconfirmed transactions. But this solution is not secure, because it’s possible to create two transactions with the same inputs, but different outputs.

http://eprint.iacr.org/2012/248.pdf

Attacker is able to send a first transaction directly to victim, and then broadcast a second transaction over the network. This couldn’t be prevented using the proof-of-work design, but it’s possible to fight with such manipulations through using an extension for our proof-of-stake system, and we even don’t need a chain fork to implement this.

Block candidates submission concept

This would allow user to check that his unconfirmed transaction is accepted into the specific stakeholder’s memory pool.

It doesn’t provide guarantee of fast confirmation, but it makes a double spending of 0/unconfirmed transactions much harder. It will be required to use some stake in order to perform such type of double spend attack.

How this could work?

1. We have a blockchain, so we can get a full list of stakeholders with suitable inputs weight (i.e. users who are able to generate proof-of-stake blocks and allowed to submit the block candidates);
2. We can check a signature of received block candidate;
3. As a result, we have a proof that specific stakeholder has a declared list of transactions in the own memory pool. Or seen those transactions, at least.

How is this supposed to work?

Stakeholder will be allowed to send proof-of-stake candidates over the network. Candidate is required to satisfy a difficulty, which would be set separately from the main chain. And then there are few different approaches could be used to handle this.

• Block candidates map;
• Temporary pseuso-chain for block candidates;

Maybe we’ll think about implementing this in the future version…

https://bitcointalk.org/index.php?topic=143221.msg4413148#msg4413148