-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Extend the case-sensitive checksum to ICAPs #70
Comments
Some sources state that IBANs are case-insensitive (and many opensource tools implement them accordingly), yet this registry on SWIFT ( https://www.swift.com/sites/default/files/resources/swift_standards_ibanregistry.pdf ) suggest it might not be? This should be answered before considering a case-sensitive scheme. |
There are some noteworthy points here:http://www.boards.ie/vbulletin/showthread.php?t=2057209257
Still, given what is stated in that forum, it seems like many interfaces will convert lowercase to uppercase in the banking system. One could make the case-validator ignore IBANs with all upper case characters to prevent problems with legacy bankingsoftware converting it. Though, I don't think this will be a real problem. |
Some test results:
|
makes a lot of sense. shouldn't be too hard to put into web3.js... |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Chia Blockchain CAIP-2 specification
Abstract
Extend the Yet another cool checksum address encoding #55 to ICAP addresses
Rationale
The ICAP format has both a Direct and Basic format, which only differs by one character in length; this is risky, given the weak checksum of only 6.6 bits (two digits: 00-99). There are real risks that someone might add a character by mistake and accidentally create a valid but unintended ICAP. Similar issue was raised here
IBANs are by specifications case insensitive, making it backwards compatible to alter the case for the purpose of checksums.
Implementation
Applying the Yet another checksum to the ICAP Direct and Basic. The case-change should only be applied to the "address" section of the ICAP, not the 4 first characters. In effect, the final ICAP will look like this:
Basic (34 chars):
XE7338O073kYGtWWzN0f2Wz0R8Px5ZPpZs
Direct (35 chars):
XE73038O073kYGtWwZN0f2Wz0R8pX5ZpPzS
Note: The change in case above is only for illustration, I haven't really calculated the real checksum. That should be trivial if people find this EIP useful.
The problems that this page raises, that an user enters one extra character without changing the checksum, is in this proposal almost reduced to zero.
The number of checksum bits increases from 6.5 bits to 6.5 + 30(26/36) ~ 28 bit => 1/268 million*
The text was updated successfully, but these errors were encountered: