I stumbled upon this old post from satoshi. he proposes that payment processors should have lots of nodes dispersed throughout the network to follow the propagation of inserted transactions until they are convinced that most nodes received the transaction and will include it in the next block. Then the payment processor can confirm any transaction in a magnitude of seconds.
wouldn’t it be nice when there was a decentralized solution for this in the peercoin network. i can imagine that with a kadmelia based hashtable, one could randomly select a node with the closest hash to the transactions hash. and this node is entitled to collect stats about the transaction and will decide when it propagated trough the network and notify anyone who requests this information.
very rough. i don’t know exactly how to collect stats. maybe this “randomly” selected node (given that the nodes hash and the transactions hash are random) can just notify all waiting nodes of the fact that it has received the transaction from the majority of its other peers. or just plain broadcasts some message as soon as it considers that given transaction valid.
it would be possible to implement such a protocol as separate service to be installed next to the peercoin node on a raspberry pie for instance. An overlay network of trust for the benefit of the peercoin blockchain.
That solution is already decentralized. Where do you see the centralization?. The “payment processor” interacts with the distributed Bitcoin network directly, there is no central point anywhere. There is no point in adding another layer of indirection (I.e: a DHT like Kademlia). There are already Bitcoin services that accept transactions with no confirmations on the premise that they will be eventually included in the block chain.
However, that a transaction has propagated through the network doesn’t makes it certain that it will be included in the blockchain, through the probabilities are high enough to accept it as a payment for low‐value transactions. A miner who generates a block before including the original transaction can intentionally include a conflicting transaction, so that the original (already propagated) transaction is never included, and so anyone who accepted it as payment will see his payment withdrawn (That is why one should wait for at least 1 confirmation for high‐value transactions, more confirmations are more secure but more inconvenient, it is a trade‐off with diminishing returns) and the one who paid can spend the money again (double spending). Bitundo is a mining pool that offers the service of attempting to undo unconfirmed transactions by including a conflicting transaction in the block chain; I’m intentionally not linking to them because I think that it will do more harm than good to the society, but its effect will be minimal in any case.
As far as I know, all of the above considerations apply to Peercoin as well and other block chain based cryptocurrencies (This is a specific case of the well known and studied “double‐spending attack scheme”).