I'd want the near misses published, because three stops only show that the gate can say no. A look-alike that matches the first and last few characters is what address poisoning produces, and attackers grind vanity addresses to match more of them. So the line I'd look for in the log is the rule itself: does LOOKALIKE_RECIPIENT compare a fixed number of leading and trailing characters, or flag any address that shares a prefix or suffix with a known payee without matching it exactly? If it's a fixed count, a payee that matches one more character passes. I'd also want to know whether that check is plain code or the 4B model's score.
The other number I'd publish is the hold rate on legitimate payments: how many payments to new, real payees got held over a week of normal use. A gate that holds everything new looks safe on a two-testnet run and gets switched off the first time it blocks a real bill.
Great questions, Mike. The look-alike check is plain code, not the 4B model, and it uses minimums, not a fixed count: an address that isn’t a known payee but shares at least 3 characters at each end and at least 7 in total is a REJECT. Matching more characters still trips it, so grinding a longer vanity match makes it more obvious, not less. Only an exact match is the known payee. The boundary was probed in an independent audit of 0.18.0: 4+4, 3+4 and 4+3 are rejected; 3+3 and 2+6 aren’t called look-alikes, but are still held as a new payee. One honest gap: if you don’t configure known payees, the look-alike check is off.
On the hold rate, you’ve named the right number and I don’t have it yet. With known payees set, every first payment to a new payee is held by design, so the useful figure is how often real use involves new payees. That needs a week of real traffic, not two testnet runs. I’ll publish it when I have it.
I'd want the near misses published, because three stops only show that the gate can say no. A look-alike that matches the first and last few characters is what address poisoning produces, and attackers grind vanity addresses to match more of them. So the line I'd look for in the log is the rule itself: does LOOKALIKE_RECIPIENT compare a fixed number of leading and trailing characters, or flag any address that shares a prefix or suffix with a known payee without matching it exactly? If it's a fixed count, a payee that matches one more character passes. I'd also want to know whether that check is plain code or the 4B model's score.
The other number I'd publish is the hold rate on legitimate payments: how many payments to new, real payees got held over a week of normal use. A gate that holds everything new looks safe on a two-testnet run and gets switched off the first time it blocks a real bill.