On Mon, Apr 03, 2017 at 03:04:47PM +0300, George Kadianakis wrote:
Hey people,
thanks for the R&D here. I'm currently trying to balance the tradeoffs here and decide whether to go ahead and implement this feature.
My main worry is the extra complexity this brings to our address encoding/decoding process and to our speficication, as well as when explaining the scheme to people.
Other than that, this seems like a reasonable improvement for a weird phishing scenario. I'm calling it weird because I'm not sure how an attacker can profit from being able to provide two addresses that correspond to the same key, but I can probably come up with a few scenarios if I think about it. Furthermore, this solution assumes a sloppy victim that does a partial spot-check (if the victim verified the whole address this design would make no difference).
BTW, isn't this phishing threat also possible in bitcoin (which is also using a 4-byte checksum that can be bruteforced)? Have there been any attacks of this nature?
Anyhow my first intuition is to just do this, as it seems like an improvement and it's probably not a huge amount of work. It can probably be done pretty cleanly if we abstract away the whole AONT construction and the custom-ish base32 encoding/decoding. I'm just worrying about putting more stuff in our already overloaded development bucket.
Is there a name for this AONT construction btw?
As my student Nik noticed, this isn't *technically* an AONT, since diffusion only happens "to the left", but that's where we want to randomize things if any bit of the address changes.
But if we're down to just pubkey + checksum + *1 bit of version*, then I'm not totally sold on the point of the AONT, since there are exactly 0 bits that can be twiddled while not changing the pubkey. *Note*: this is assuming that if we ever change the version number, *then* we do an AONT or something so that version 0 and version 1 addresses that have the same pubkey end up looking totally different (at least at the left end).