Difference between revisions of "Fraudulent Deposit Address"
(Initial page creation) |
m (correct category) |
||
Line 12: | Line 12: | ||
If the OT client cannot get verification of a cached PaymentRequest id from at least m total members of the pool, it must not initiate a blockchain transaction. | If the OT client cannot get verification of a cached PaymentRequest id from at least m total members of the pool, it must not initiate a blockchain transaction. | ||
− | [[Category: Type | + | [[Category: Type 1 events (voting pools)]] |
Latest revision as of 11:31, 23 May 2014
Introduction
BIP70 was designed to make MITM attacks which change destination addresses detectable. The voting pool will rely on this protocol to protect against most forms of attack in the deposit process.
Procedure
PaymentRequests
associated with a voting pool have a special “open-transactions” pki_type
which allow complete client-side verification by the OT client.
The OT client must fully validate the PaymentRequest
included in a pendingBailment notice, and alert the user of an invalid notice, refusing to forward the request to a local Bitcoin wallet. It should then forward the invalid pendingBailment to the other transaction servers in the voting pool. When the other members verify that a transaction server has signed an invalid pendingBailment notice, they must mark the affected audit stream as “compromised”.
Once the source of the problem has been discovered and corrected, the operators of compromised servers can replace the invalid pendingBailment notice in the inbox with the correct one, and request a manual status promotion back to “clean.”
If the OT client cannot get verification of a cached PaymentRequest id from at least m total members of the pool, it must not initiate a blockchain transaction.