-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support identifying potentially errorneous characters #95
Comments
From the text of BIP-0173:
I would support including some position information in one of the enum variants. This feature might necessitate a new API function that decodes with detection, since it seems to be a more intense operation than simple checksum validation. |
Indeed, that's why I wrote "identify", not "correct" :) And yes, position information should be in error variant. I wonder if feature flag is enough. |
@Kixunil I think we should have a separate function call for identifying errors. Locating errors is very costly -- on the order of 20-50x as expensive as verifying a checksum for a normal sized address, I"d estimate. So we can't modify the normal checksum API to return this, even with a feature gate. Then as for locating vs correcting errors .... I think it'd be fine to also put the corrections into the error variant, and just document in the API that users should not use these values to do automatic corrections, and probably they should just ignore them entirely and just use the locations. |
OK, that makes sense for this library. But what about I wouldn't include corrections at all. Seems like a noise. At least until someone asks for them. |
For Though I wouldn't mind if |
Yeah, also we would only calculate them on errors, which should be cold path in vast majority of applications. |
Yeah, that's a good point -- the first step of error locating is doing the normal verification anyway, and we know immediately whether there is even any point in doing the heavy computations. |
The checksum algorithm has error detection that can identify which characters were actually wrong (with some probability). It'd be great to support this in the library.
The text was updated successfully, but these errors were encountered: