Hello Folks,
I’m new to this working group. I’m looking at ICRC standards as the next part of the 221Bravo App build gets closer. One quick question - is there a plan to have a method for finding the last transaction (tip of chain)?
This would be really handy for what I’m trying to do and I imagine other would find it useful too.
Many Thanks,
Nathan.
EDIT - Ignore this just spotted the log_length info in the returned transactions.
Is there any best practice on how “small” subaccount ids are padded, on the left or on the right? Regardless of whether the small subaccount id represents an integer or a short blob, where is it best to place the padding with 0-bytes?
Subaccounts are left padded up to the nearest 4-bit boundary.
So you mean if I want to create a subaccount that corresponds to a principal and the principal is 29 bytes then the canonical way (according to a written or unwritten standard) would be to have 3 zero-bytes followed by the 29 principal bytes?
There is one unfortunate thing about this choice. If you ever wanted to recover the principal from the subaccount id then it is not uniquely possible because the principal itself can start with a zero byte. If the padding was on the right then it would be possible because principals never end in a zero byte (currently they can only end in 01-04).
bit, not byte.
I don’t really follow your argument… It doesn’t matter how many leading 0s you have does it?
I mean left padded vs right padded. Not talking about the 4bit boundary.
Right padding is an injective operation because principal never ends in a 0 byte.
Left padding is not injective because principal can start with a zero byte.
It would greatly surprise me if principals can contain leading zeros, i.e. 00000101100100000010b !== 0101100100000010b.
@mariop @dieter.sommer @roman-kashitsyn
Not IC-generated ones. But all self-authenticating principals start with a hash according to Internet Computer Content Validation Bootstrap which can start with a 0.
To clarify: I am not worried about collisions but about invertibility of the padding operation.
And when we compare those principals they’re different? Or is it just that the textual representation of one of them not canonical?
The two that you have written are different.
There is no problem for the textual representation. It encodes the additional zeros and comes out as a different string.
Judging from the specification it shouldn’t be a problem because
Hdenotes SHA-224
so we could deduce the number of leading zeros if the last byte is 0x02 or 0x03 (provided that the canister knows it’s a principal, which it should almost always do). It may be a problem only if it’s a 0x7f principal but I’m not sure how much that is being used. But even then the IC interface spec doesn’t specify the blob comparison operator.
Most canisters injecting principals into subaccounts use one byte for the actual length and pad with zeros on the right. The textual representation for such an approach is not optimal, but I don’t think it’s a big deal.
Canisters that want to shorten the textual representation could use the mirror approach:
Subaccount = [pad zeros][principal bytes][length byte].
Is there really precedence for doing it that way? In particular with using the length byte?
If they pad on the right then length byte wouldn’t be necessary. My preferred solution now, taking into account the textual encoding as well, would be to use a length byte (as prefix) and pad on the left.
The slides, recording, and minutes of the WG Meeting of March 21 are available:
Slides
Recording
Minutes
We are skipping the WG meeting today April 4, 2023, due to multiple people, including myself, being on vacation.
Hi everyone, I’m currently going through the token standard pains, and I can tell you that DIP721 was the simplest solution for me so far, until I found out that the community was moving away from it.
Now i’m trying to switch to EXT and its really convoluted. I get the expandable idea, but theres so much there that I can’t tell what is necessary. Even now with discovering ICRC I see there are already multiple versions.
I think it would help if there was a State of the Dapp like app that the community could upvote on to display the overall consensus. There’s no sense in using the term standard when there are multiple “standards”.
This sounds like a misunderstanding. Different ICRC standards are not necessarily replacing previous ones. The basic ICRC-1 lends itself to be expanded by also supporting ICRC-2, but that doesn’t mean that ICRC-1 will make sense to combine with ICRC-345
Yes, you’re right. I’ve been searching for answers regarding EXT and other NFT token standards, and because of the lack of answers I ended up here ^_^.
Dear community! See here for an issue where we need help from the community. Would be great if we could get more input and opinions from the community on this issue, otherwise the WG needs to decide on its own.
Dear working group members!
Here is the proposed agenda and draft slides for the ledger and tokenization WG meeting on Tuesday, April 18, 2023. See the working group calendars (Google Calendar, calendar browser link) for details and dial-in information.
Agenda
Talk to you tomorrow!