When a taker order fills against several maker orders, the server sends the taker a single match request containing all of those matches, and the taker replies with one acknowledgement array holding one entry per match, each carrying the taker's per-match swap address.
processMatchAcks handles that array in a loop. For each entry it verifies the signature and address and then, still inside the same loop, writes the result into the shared match: it stores takerSwapAddr, sets Sigs.TakerMatch, and once both sides' addresses are present it sets counterPartyAddrsSent = true, queues the counterparty-address notification, and resets the match timer. The notifications themselves are only sent later, after the loop, once the batch has been persisted.
The problem is that a bad entry aborts the loop after earlier entries have already been written. If the taker sends valid addresses for the first matches and an empty address for a later one, the loop reaches the empty entry, responds with missing per-match swap address, and returns before it persists anything or runs the notification step. The earlier matches are left with counterPartyAddrsSent = true even though nothing was sent, and with the taker's address stored in memory even though the maker was never told it.
Those makers now can't act: a maker needs the counterparty's address to build its swap contract, and it never received it.
As a result, the malicious taker receives a reputation penalty of -4, and each of the makers also get a penalty of -4 (despite acting honestly)
When a taker order fills against several maker orders, the server sends the taker a single
matchrequest containing all of those matches, and the taker replies with one acknowledgement array holding one entry per match, each carrying the taker's per-match swap address.processMatchAckshandles that array in a loop. For each entry it verifies the signature and address and then, still inside the same loop, writes the result into the shared match: it storestakerSwapAddr, setsSigs.TakerMatch, and once both sides' addresses are present it setscounterPartyAddrsSent = true, queues the counterparty-address notification, and resets the match timer. The notifications themselves are only sent later, after the loop, once the batch has been persisted.The problem is that a bad entry aborts the loop after earlier entries have already been written. If the taker sends valid addresses for the first matches and an empty address for a later one, the loop reaches the empty entry, responds with
missing per-match swap address, and returns before it persists anything or runs the notification step. The earlier matches are left withcounterPartyAddrsSent = trueeven though nothing was sent, and with the taker's address stored in memory even though the maker was never told it.Those makers now can't act: a maker needs the counterparty's address to build its swap contract, and it never received it.
As a result, the malicious taker receives a reputation penalty of -4, and each of the makers also get a penalty of -4 (despite acting honestly)