Hello folks at Rosen,
When a Guard missed an event's payment, it asks the other Guards which transaction paid it. I noticed two gaps in how it checks their answers.
1. The quorum doesn't compare answers. processSyncResponse counts answers with countBy. Without a key function, every PaymentTransaction object counts as the same key, "[object Object]" (paymentTransaction.ts). So the check passes once enough Guards have answered, whatever transaction they name, and the Guard takes the transaction from whichever answer completes the count.
2. An answer isn't tied to the chain. Each answer carries a transaction plus a separate transaction id, actualTxId. verifySynchronizationResponse checks that the transaction has the right payment order, but checks only actualTxId on chain, and never that the two match. An honest Guard always sends matching ones, but a faulty or compromised Guard can send a made-up transaction with the id of some other confirmed one.
Together: if such an answer is the one that completes the count, the Guard records a transaction that was never sent as the event's payment. It then shows that payment in its public status and can't take part in that event's reward, since it builds and checks the reward using the wrong payment id. The other Guards still pay the reward, so no funds are lost.
Keep up the Great Work,
Phroi
Hello folks at Rosen,
When a Guard missed an event's payment, it asks the other Guards which transaction paid it. I noticed two gaps in how it checks their answers.
1. The quorum doesn't compare answers.
processSyncResponsecounts answers withcountBy. Without a key function, everyPaymentTransactionobject counts as the same key,"[object Object]"(paymentTransaction.ts). So the check passes once enough Guards have answered, whatever transaction they name, and the Guard takes the transaction from whichever answer completes the count.2. An answer isn't tied to the chain. Each answer carries a transaction plus a separate transaction id,
actualTxId.verifySynchronizationResponsechecks that the transaction has the right payment order, but checks onlyactualTxIdon chain, and never that the two match. An honest Guard always sends matching ones, but a faulty or compromised Guard can send a made-up transaction with the id of some other confirmed one.Together: if such an answer is the one that completes the count, the Guard records a transaction that was never sent as the event's payment. It then shows that payment in its public status and can't take part in that event's reward, since it builds and checks the reward using the wrong payment id. The other Guards still pay the reward, so no funds are lost.
Keep up the Great Work,
Phroi