Bounding the time to detect double spends

We can bound the time to detect double spends T by having recipients default to cashing winning tickets on-chain immediately after receiving them. The downside of this approach is that recipients lose flexibility in deciding when to cash winning tickets.

If recipients are running full nodes they can also watch the transaction mempool for broadcasted winning tickets which allows recipients to obtain information faster than simply waiting to see a transaction confirm on-chain. One idea that might be worth exploring in a subsequent iteration is to use a separate gossip network for the recipient set that is used for broadcasting winning tickets instead of relying on the Ethereum network for broadcasts which might be useful for giving recipients more flexibility in deciding when to cash winning tickets. For the time being an initial implementation can use the simple default of cashing winning tickets immediately.

The issue mentions no files, tests, or entry points. Begin by locating the existing payment and winning-ticket implementation, then determine how immediate on-chain cashing should be integrated and how its detection-time behavior can be tested.