If funds are transferred to the xorurl of a Wallet or a SafeKey (ie this is equivalent to a bitcoin address) then it’s important this value is not erroneous and should contain a checksum.
The <cid> part of the xorurl (see rfc-0053 specification), ie the bold part in safe://hnyyyywzzm5s…ucy9e, is 61 characters and could use an ethereum style checksum by capitalizing characters that match any 1 bits in the first 61 bits of the xorname? Not sure the exact best way to derive the checksum but this seems like a simple way.
This would help prevent perceptions such as this: “seriously? there’s no checksum? you typo one character wrong and your ether is lost forever? Damn… TIL Ethereum has a massive design oversight”
In theory this could apply to all xorurls, not just wallets and safekeys.
We have the opportunity to include hemming codes such that there is ECC rather than just checksum.
But if SAFE wants to present itself as “better than the rest” then this would be a simple addition to the code by including it in the class and it be automatic.
Another advantage is that addressing sites by XOR address allow for mistakes and yet still get the right page and if too many mistakes it can report the error. Would be really hard to to not catch errors even if the ECC cannot fix the error
This sounds fine for fetching data but for wallets and transfers it should probably not try to automatically fix the error even though it usually can. Bip173 says:
Use of an incorrect but valid input can cause funds to be lost irrecoverably. Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.
Sounds a little too conservative from a ux perspective but I can appreciate that if there’s a problem it’s really up to the user to correct it, not the software (which would then be liable for the correction which may be valid-but-incorrect).
A broken checksum may be a) a typo which needs fixing or b) a completely incorrect address that is unfortunately almost valid and needs to be requested again. The software can’t know if a) or b) is the correct way to fix the problem.
Overall ECC seems very useful (hence bech32 being developed for bitcoin!) but I figured some pedantry on the topic may be of interest!!
Maybe in the wallet it highlights that address is in error and optionally suggest the correct address if ECC can fix it. Then the user can reenter the correct address or accept the correction
EDIT: anyhow that is a UI consideration whether it just rejects or offers ECC corrected address. But yes definitely need for the user to correct or perhaps accept ecc correction if it is offered at all
Yes, I spent a little bit of time at some point trying to implement a first version of it but didn’t have much time, but I agree it’ll be better to have a checksum for all xorurls. I wouldn’t be much in favor of the auto-correction for users as it can be used for phishing??
The problem with this has been that not all wallets/exchange implement it. It is optional since it isn’t baked into the protocol and is just a UX level thing.
Interesting point. It could be baked into the API level for handling wallet addresses - seems like a good approach for the API to require a sumchecked address and validate it before proceeding.
By “not all” is the implication that there is some friction for adoption (without any specific measure), or is it closer to “less than half” or something that would introduce significant friction to adoption of SAFE coin support on exchanges? I wonder if exchanges are naturally drifting in the direction of supporting it, and if we can expect that condition to loosen over time.
And there’s always the possibility that, depending on SAFE’s success, could it push exchanges to be amenable to adopting the required tooling to deal with non-optional checksums, etc. Of course, what comes first is up for debate, because if adoption is slowed by something like required tooling for checksums, then SAFE wouldn’t see the success required to drive exchanges to adopt the tooling. A sort of chicken and egg scenario…
Some concrete numbers would be useful I think. From a quick search, it seems the idea of “some exchanges don’t support checksums” comes up a lot, but I can’t find any hard answer or analysis on it. My initial guess is it’s not enough that it would seriously hamper SAFE
I also don’t have any data beyond what I’d gather with
From a UX angle, it is pretty bad though. Unless you do some background research on the particular product you’re using, you couldn’t even be confident that such a backstop was in place. You only find out when you mess up an address in a transfer (and you may not like what you find!)
bech32 and segwit are good examples of what to expect, ie adoption of upgraded formats is slow. I don’t know of a single site that uses the error-correction feature of bech32, but then, I haven’t used any bitcoin services with bech32 enabled so maybe they are out there and I just don’t know of them?! If checksum is built in to SAFE from the start then of course everyone will have it, but whether they check and enforce the checksum, well, that’s hard to say.
I think the best bet is for the API to only generate addresses with checksum and only accept with checksum. It then becomes more work to avoid using it.
I would also imagine the API should do the check and report an invalid checksum error, we could also have a force flag if it’s really required for transitioning/upgrading phases of checksum compatibility/incompatibility…?..
