Difference between revisions of "Minority loss of consensus"

From Open Transactions
Jump to navigation Jump to search
m (Add category)
m (Fix category)
Line 11: Line 11:
 
After 106 confirmations have elapsed, and the responsible [[Transaction Server (voting pools)|transaction server]] has not created the appropriate [[completedBailment]] notice for the user, the rest of the pool will add the notice to the server’s [[Auditing (voting pools)|audit inbox]] and place the server in a [[Auditing (voting pools)|degraded audit state]].
 
After 106 confirmations have elapsed, and the responsible [[Transaction Server (voting pools)|transaction server]] has not created the appropriate [[completedBailment]] notice for the user, the rest of the pool will add the notice to the server’s [[Auditing (voting pools)|audit inbox]] and place the server in a [[Auditing (voting pools)|degraded audit state]].
  
[[Category:Type 2 events]]
+
[[Category:Category:Type 2 events (voting pools)]]

Revision as of 14:25, 23 May 2014

Introduction

A minority loss of consensus exists any time where between 1 and m-n servers have failed to take an action they should have taken.

The general process for resolving the situation is for the majority audit servers to sign the appropriate message which the diverged server(s) has failed to sign and place them in the server's inbox, and place the effected server(s) in a degraded audit state until they correct the issue.

Non-credited Deposit

A customer deposits bitcoins into the pool via an address provided as part of a valid PaymentRequest, but the responsible transaction server fails to credit the appropriate nym after the deposit is fully confirmed.

After 106 confirmations have elapsed, and the responsible transaction server has not created the appropriate completedBailment notice for the user, the rest of the pool will add the notice to the server’s audit inbox and place the server in a degraded audit state.