HIP-15: Address Checksum

[lbaird]

This is the page for discussing HIP-15, which addresses the request in issue #34.

[bugbytesinc]

While a bit of an edge case, have you considered including the network (mainnet, testnet, previewnet) as a part of the hash computation?

[lbaird]

That’s a good idea. The definition could be changed to include the ledger ID, once that has been implemented (as part of state proofs). Though it would mean we would have one set of hashes today, and then they would change when we implement ledger IDs. It’s worth thinking about.

[mehcode]

While a bit of an edge case, have you considered including the network (mainnet, testnet, previewnet) as a part of the hash computation?

I was a bit on the fence of this being a good idea until I read this comment by @bugbytesinc. This is an excellent idea. Not only do we have some protection against mistyped IDs but we also have protection against someone sending to an ID of the wrong network which is an unsolved problem in Ethereum (when you copy address from a test wallet there are numerous warning pop-ups that try to help).

---

Can I also suggest that we follow precedence in the gaming industry for identifiers and use 0.0.10#check as the format over 0.0.10(check). Its 1 less character to type and is used all over the place to disambiguate user identifiers (see Discord for a popular example).

[kenthejr]

@lbaird what do you think about @mehcode suggestion? If we can settle on format, I'd like to move this into a formal HIP review process.

[lbaird]

I think the 0.0.123(laujm) format is the least confusing possible for people who don't yet know we have a checksum. Because it's clear that the checksum is not part of the address, but is more like a comment on the address. Of course, any tool conforming with the above will still accept an inputof 0.0.123#laujm as valid. The parentheses are just the standard for how to display it.

At the moment, both Hedera and some outside parties are implementing the HIP as described above, with outputs using parentheses, and inputs accepting anything (parentheses or hash or anything else).

[mehcode]

I strongly disagree on that. Please specify that any other format but the one we're going with is considered illegal.

Allowing clients to display and format doesn't sound like it will scale well.

I'll concede on the format even though I'm pretty against how parentheses adds two symbols and the # adds one.

---

Most importantly, can we please include the network in the hash? I find this to be as critical or even more so than protecting against typos.

[lbaird]

The standard above does NOT say that clients can display in any format they want. It says they should display with parentheses. It also gives a regex that is lenient when parsing input. It follows the general principle of being strict for outputs, but lenient for inputs.

Note that there are two regexes given: one is the requirement for outputs and the other is the requirement for inputs, to follow that principle.

"Be conservative in what you send, be liberal in what you accept"

https://en.wikipedia.org/wiki/Robustness_principle

[kenthejr]

I'm reading two things we need to resolve before we settle on the HIP:

1. format for appending checksum
2. request to add network info

---

1. my recommendation would be to be highly opinionated in the format we recommend for input and output. The official SDKs will strictly implement those, but anyone can deviate (map their own format) however they want in the wild. I'm also a fan of fewer characters and a gamer, so {accountID}#{checksum} resonates with me. That would be my recommendation.
2. @mehcode I'm keen to see what you would recommend for network info.

[mehcode]

"Be conservative in what you send, be liberal in what you accept"

Please see the criticism section of the wikipedia link you shared. Most internet standards in the last decade or so have increasingly not been following this for several very real reasons:

• Flaws in implementations quickly become pseudo-standard and circulated as "well this is accepted here in client X?"

• From a user experience perspective it is very helpful to give clear and concise errors to an input stream, being liberal in what is accepted makes this unreasonable in practice which leads to very confusing error messages.

• From a performance perspective, being strict in what you accept leads to a significantly more performant implementation. Regular expressions require an entire embedded VM to utilize where as a straight-forward one-pass parse can handle a strict format.

• Most notably this resonates in JSON and is a strong reason why JSON is used in API implementations as opposed to its brother YAML that follows the robustness principle.

---

I'm keen to see what you would recommend for network info.

We have some kind of ID ( @lbaird mentioned a TBD "ledger ID" ) that is mixed in with the hash. My recommendation is to not wait on that to be defined and pick low constants to be mainnet and testnet. Other networks can always be different than those.

The checksum is a function of the ledger ID, so that the same address will have different checksums if it is on different ledgers. Cryptographically secure ledger IDs will be implemented as part of state proofs. But for now, the following three ledgers will each have a ledger ID consisting of a single byte:

@lbaird Thank you. I didn't realize this got added to the format. 💯

[bugbytesinc]

I like it, thanks for adding the network number, I've seen a few conversations in on discord where this feature would have prevented a human mistake.

Is the expectation that the SDKs offer direct support in their APIs when building requests or is it expected implementation will solely be at the user interface level? I gather this will not be included at the protobuf level initially?

[lbaird]

The expectation is that it would be used in SDKs, wallets, ledger explorers, etc. It wouldn’t be part of the HAPI protobuf transaction itself, but it would be part of the tools used to create and see the transactions.

…

________________________________ From: Jason Fabritz <notifications@github.com> Sent: Monday, January 18, 2021 1:56:59 PM To: hashgraph/hedera-improvement-proposal <hedera-improvement-proposal@noreply.github.com> Cc: Leemon Baird <lbairdgit@gmail.com>; Mention <mention@noreply.github.com> Subject: Re: [hashgraph/hedera-improvement-proposal] HIP-1 Address Checksum Format (#35) I like it, thanks for adding the network number, I've seen a few conversations in on discord where this feature would have prevented a human mistake. Is the expectation that the SDKs offer direct support in their APIs when building requests or is it expected implementation will solely be at the user interface level? I gather this will not be included at the protobuf level initially? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/hashgraph/hedera-improvement-proposal/issues/35#issuecomment-762444796>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABDBYW4ND76FCKCJPDICCFLS2SHAXANCNFSM4T2V3W2Q>.

[rhysied]

Hi all, I had a few questions:

1. I know the likelihood of a collision bearing similar properties is very small, and that the lower the length of the checksum the more user friendly it is - however, is there some significance around having 5 as a length? Would 6/7/8 allow a much greater number of accounts before a collision is reached? Or would using 3/4 be more user friendly while achieving similar results?

2. do you think this has the potential to add spam to the network if people decide to create accounts with vanity checksums? Given the checksums can be calculated in advance I could know that, for example, by spending $20 I can create an account with some special significance?

Also, as regards to the rest of the discussion, in general I agree with Mehcode that more stringent input requirements/formatting seems better, however as for the format of ({checksum}) vs #{checksum}, I have no real preference.

Cheers, Rhys

[lbaird]

The 5 characters should be sufficient to catch typos. Because adding a character, deleting a character, and swapping two adjacent characters is guaranteed to never cause a collision. Even adding or subtracting 2 or 3 or 4 characters is guaranteed to never cause a collision. So it seems unlikely that someone will accidentally mistype an address, and find that the resulting hash still matches. In addition, if you make up two random addresses, the chance of collision is much less than one in a million. So 5 characters should be sufficient for catching likely errors. It could be reduced to 3 or 4 characters, and probably still be OK. The number 5 was actually chosen because humans tend to remember 5 characters pretty easily, but 6 is harder. So it was the longest that is easy to remember. In the old days of cryptography, ciphertext was often written in groups of 5 digits for that reason. It would be good to hear from others about whether to be strict on inputs or not. If it’s generally felt that strict is better, then I’ll edit the proposal to have just the second regex without the first one. Not all of the criticisms listed on the wiki page apply in this case. But strict wouldn’t be terrible. If there is widespread concern about wasting a byte, then we might consider 0.0.123-laujm instead of either 0.0.123(laujm) or 0.0.123#laujm because it is visually less crowded to use the lighter dash. I’d be fine with switching to that.

[rblinton]

prefer strict input and 0.0.123-laujm format

[lbaird]

From the various people who have commented, it sounds like it should be strict input with 0.0.123-laujm format. If there are no objections, I will change both the text and the reference implementation to reflect both of those changes.

[bugbytesinc]

h = unsigned byte array containing the ledger ID followed by 6 zero bytes

It just occurred to me to ask, Is it important to know the network from the checksum just by looking at it?

I'm speculating not since it is trivial to compute a comparison value for all networks?

[rhysied]

I suppose the optimal thing for frontend applications to do would be to check any failures against the checksums for the account ID on different networks in case people are operating in the wrong context and throw a warning. Not sure how you would enforce that though, it would just have to be a recommendation I guess, unless you wanted to go further down the rabbit hole you could potentially have a compliance program which allows sites / apps to show a "hedera standards compliant (vX.X)" badge

…

________________________________ From: Jason Fabritz <notifications@github.com> Sent: Saturday, January 23, 2021 8:05:32 PM To: hashgraph/hedera-improvement-proposal <hedera-improvement-proposal@noreply.github.com> Cc: Rhys Davies <radman1990@hotmail.com>; Comment <comment@noreply.github.com> Subject: Re: [hashgraph/hedera-improvement-proposal] HIP-1 Address Checksum Format (#35) h = unsigned byte array containing the ledger ID followed by 6 zero bytes It just occurred to me to ask, Is it important to know the network from the checksum just by looking at it? I'm speculating not since it is trivial to compute a comparison value for all networks? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://github.com/hashgraph/hedera-improvement-proposal/issues/35#issuecomment-766171498>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJFWARBTNLIRR54Q2YCESVTS3MTYZANCNFSM4T2V3W2Q>.

[lbaird]

If a wallet application is designed to just work with mainnet, then it would be hard coded to use that ID for all checksums. If it’s designed to work with several networks, such as the 3 that are listed, then it would presumably give the user a pull down menu to choose one of those three. It could also have an option where the user can actually enter an arbitrary ledger ID. In the future, we will be using cryptographically-secure ledger IDs of 48 bytes (a SHA-384 hash). But for the moment we’re just using 1 byte (with a value of 0, 1, or 2).

[mehcode]

MyHbarWallet is going to add a network drop-down in the header and then it would require your checksum to match the ID and the selected network.

[lbaird]

The HIP-1 description has now been updated in all 4 places:

• text description
• Javascript zip
• Java zip
• linked example page

[kenthejr]

Let's get this converted to the new HIP format. We can continue to use this issue to discuss the HIP once the PR is submitted and reviewed.

[kenthejr]

Formally merged in as hip-15

[kenthejr]

FINAL CALL FOR COMMENT

This HIP is scheduled for progression to Final status if no other contributions are made by the community. If no issues are raised or pull requests made within the next 7 days, this HIP will be updated to Final status and this discussion thread will be closed.

[kenthejr]

This was reset 5 days ago with new comments and contributions. If no additional recommendations or corrections are made by May 13th, 2021, we will move to a final edit then progress the status to Final.

[vshall20]

I like the idea of having the checksum as 0.0.123#laujm vs 0.0.123(laujm) as it adds an extra effort on the user to add paranthesis vs just a # symbol. Feels like Discord usernames :)

Would also like to incorporate the network in the checksum to avoid using testnet id on mainnet, have been through this 😓

[kenthejr]

the format was settled as 0.0.123-laujm instead of 0.0.123(laujm). We had two competing alternatives: 0.0.x-chksm vs 0.0.x#chksm and the former was the winner previously.

Also, I believe the network is now included in the checksum. Agreed that this is important :)

[kenthejr]

New update from @lbaird in this PR: https://github.com/hashgraph/hedera-improvement-proposal/pull/84/files?short_path=7515287#diff-7515287cdc221b0bfef1d600175cd9ce0458360be51dab7f133f0a1a98048701

I'd love another set of eyes on it. It looks good to me.

Changes include:

• multiply by 1,000,003
• update front-matter format
• add files to assets/hip-15 folder

[coltsfanatic07]

Regex vets out and implementation of the ledger ID looks good. I like it.

[kenthejr]

Hedera Council Technical Committee has ratified this HIP

Once the FINAL CALL FOR COMMENT period has expired and no additional concerns have been raised, this HIP will move to its final state based on its type.

[Liebenfiels]

Can you update please what is current situation with this HIP as it has been a while.
Excellent news that Hashscan explorer displays now check sum for account IDs (Dr Baird HIP-15) that address and solves account ID mistype problems and gives user that secondary check, to ensure account typed is correct as aimed. There should be push now to update all wallet ecosystem and explorers with the same Dr Baird single standard, as quickly as possible including explanation what is for.

To me it could work as below how I understand it:

1. User A aiming to receive Hbar can provide sender person B a package (in form of text of screen shots assuming not all wallets will have QR code capabilities)
   account ID + check sum e.g. 0.0.1234-pikcw
2. User B (sender) sending funds to user A will type account ID 0.0.1234 only and wallet will then display also check sum for it.
3. User B before sending Hbar would check both account ID + check sum (with that provided by user A) to make sure typed account ID correctly as secondary check. Also can use website to generate check sum if needed.
   QR code- to make in human readable format as 0.0.1234-pikcw.

4. Wallet will read the QR after scanning it- then take just account ID from it 0.0.1234 and check if displayed check sum it has as wallet (hard coded) = check sum in QR code
   

If CORRECT- then input account ID for transaction
If WRONG- if check sum does not match to fail safe and not input account ID (corrupted QR code, where either account ID is wrong or check sum)

https://hashscan.io/#/mainnet/dashboard
Overall the proposed HIP-15 is very good even with very rare non-relevant for users collisions (“less than one in a million chance”) as user can type account ID (as most would do) and look on check sum in form of letters that is convenient format.
**Wallets and explores should implement it immediately.

I would boycott (not use) any explorer that does not display check sum for account IDs, later will do the same with wallets if they refuse to help ecosystem and follow single standard, to help community use the network securely without them sending Hbar to wrong accounts by making typos. Hashpack wallet said they will do it.

[P.S. I had some counter proposal (shared PowerPoint with concept), but not here on GitHub as was late already to make collision free check sum in form on hashing account ID format. I did collision test on hash generated from 3M accounts where even cryptographically broken MD5 (32-hexadecimal) is secure for what is proposed and collision free (for 3M tested) and don’t expect to find collision- generated 25M hashes but run out of computing power. That would also help to type/find account ID using that alternative way as unique hash output to each account ID and secure QR code as well. Any other hash function could be used SHA3-224 -but is longer].

**But the HIP-15 would do the job very well and having short format with letters only as check sum is very good concept as well and has to be implemented in ecosystem as soon as possible.

[lbaird]

A wallet should allow a user to enter an address with or without the checksum. If the user enters the checksum, the wallet should check it, and tell the user if it isn’t correct. It should always display account numbers with a checksum.

[Liebenfiels]

Thank you and as well for email with explanation of status- already approved by council while back (as Final status) of that HIP-15, hopefully will be soon implemented by whole ecosystem.
Once other explorers and wallets see that Hashscan displays- they should realize and follow with upgrade.

[WilliamJordan33]

Hello Everyone,

I am having trouble sending my HBAR from an exchange to my Ledger. I have downloaded the hashpack, made an account and created the wallet. There are two checksums; one with decimals and numbers and one with decimals numbers a dash and letters at the end. When I am connected to the Ledger to the Hedera App, I open it, I click receive on Ledger live and the address that comes up is only the first checksum without the digits at the end. There is no way to change either of the checksums on Ledger Live or hashpack but a support robot that I emailed from the hashpack website told me to delete the last checksum digits which is impossible. There is a warning at the bottom saying that, "Your Hedera address cannot be confirmed on your ledger device" I sent 2 HBAR from the exchange to the checksum, remembered to put the MEMO along with the address that was on Ledger Live and my hashpack account and nothing came through. I sent another 2 HBAR from the exchange and nothing went through as well. I am furious because this checksum is not making things more secure but it is putting my assets at risk. All of my other crypto currencies that did not add this extra layer of unnecessary "security" are safe and secure on my Ledger. Ledger is not really compatible with the checksum and my assets are now at risk. For the love of God can someone please help me?

Sincerely,

William Jordan

[coltsfanatic07]

It does seem there is an issue with the ledger implementation, presumably of the checksum, that is causing this issue to be reported. I can understand why anyone would be concerned by seeing said message. I know that Ledger is currently working through numerous updates for Hedera, or at least as I understand it.

If it were me, I would send a test HBAR transaction from the exchange, to my known Ledger Account ID without the checksum. As Ledger is behind with implementing checksum, I would guess there are limitations in numerous exchanges that are causing problems with attempting to use the checksum as well.

Don't forget that checksum is also completely optional for the user. Hedera processes transactions with our without.

On the flip side, if you attempt to send from Ledger, you can confirm your account ID when processing the transaction. I just quickly sent 5 HBAR to a Hashpack Wallet and sent 5 back to Ledger and everything mechanically works.

I would see about contacting Ledge support about the issue.

[WilliamJordan33]

Hello, I was on a Discord call with a hashpack worker all day today, we tried everything and we discovered that the problem is with Coinbase. I have 6 small transfers of HBAR from Coinbase to Ledger and they have been pending over the last couple of days. We both separately contacted Coinbase and they are working to solve the problem. I told them that they need to also contact Hedera and Ledger to ensure that their technologies are operating cooperatively. Funny how it is the centralized exchange with the issue. I will contact Ledger Support to notify them about this issue. I appreciate you taking the time to try and resolve the issue. Sincerely, William Jordan

…

On Sat, Feb 11, 2023 at 7:05 AM coltsfanatic07 ***@***.***> wrote: It does seem there is an issue with the ledger implementation, presumably of the checksum, that is causing this issue to be reported. I can understand why anyone would be concerned by seeing said message. I know that Ledger is currently working through numerous updates for Hedera, or at least as I understand it. If it were me, I would send a test HBAR transaction from the exchange, to my known Ledger Account ID without the checksum. As Ledger is behind with implementing checksum, I would guess there are limitations in numerous exchanges that are causing problems with attempting to use the checksum as well. Don't forget that checksum is also completely optional for the user. Hedera processes transactions with our without. On the flip side, if you attempt to send from Ledger, you can confirm your account ID when processing the transaction. I just quickly sent 5 HBAR to a Hashpack Wallet and sent 5 back to Ledger and everything mechanically works. I would see about contacting Ledge support about the issue. [image: image] <https://user-images.githubusercontent.com/20265949/218264871-fce816aa-9cd0-4da2-a38c-a6eded6adbea.png> [image: image] <https://user-images.githubusercontent.com/20265949/218265752-ac27ed2a-e261-423a-8cfe-1ce1eb9ff8d5.png> — Reply to this email directly, view it on GitHub <#47 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A52TLUJICWLAQQBZLAD4J2DWW6TDFANCNFSM4ZZPJISA> . You are receiving this because you commented.Message ID: <hashgraph/hedera-improvement-proposal/repo-discussions/47/comments/4943759 @github.com>