-
-
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
Fix operation id by using proper conceal #153
Conversation
tried patching starting from scratch and trying to issue an RGB20 asset I get the following error:
not sure if something needs to change on how the asset is issued, the command I'm using is ("data" and "contract.yaml" are just placeholders here):
I'm using patched versions of:
|
Previously we were panicing earlier; this commit implements most of the conceal logic and panics at the last stage.
9a0cdc4
to
0646d7d
Compare
Sorry for not checking that. The reason of the problem that conceal procedure, now called during the id computing, has to construct bulletproofs, which are not supported yet. This was the actual reason why the I have made a workaround for that, but now it seems I have some issues with computing pedersen commitments. Working on that and will write once the full solution will be ready. |
I tried reproduce the same tests I made here with this patch, but I receive the same error:
|
I have the solution, but it requires some work. In client-side-validation we have two main encodings: strict ( The difference is that strict encodes data for persistence, and commitment just to hasher, producing hashes/commitments to the data. For now commit-encode uses one of two strategies: either strict encoding, just writing to the hasher, or conceal-strict, where a However, the new panic you've got is the fact that it is impossible to fully conceal fungible state since we do not have bulletproofs yet (which are required for the conceal procedure). So I have to abandon conceal-strict strategy and do a proper commitment encoding for all concealable data which do not rely on conceal procedure (since for instance we must not commit to bulletproofs, thus no need to produce them here, unlike a normal conceal). This means quite a lot of code to write (second encoding for most of RGB consensus data). I will use a derivation macros for that, and for that need to create |
Ok, sure. Thanks for explanation.
OK, Do you have anything I can help with? |
Not at this moment :( But later of course with making sure everything works as planned. |
BTW, @dr-orlovsky, the conceal-strict strategy sounds like a keyed hash. Blake3 has support for this built-in. It is seeded by 128 bits, however. Very clever to separate hashing from serialization, btw! |
It is not keyed or hashed per se. The keyed hashing is performed by |
9631798
to
f58cbfb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything seems to work, I only have two observations:
1- Just missing the addition of an attribute in one of tests. Please, see my comment.
2- I found a minor bug when the transfer and the invoice were generated from a single Stock/Inventory (as if it were a self-payment). But I will open another issue because this bug has no direct relation with this PR.
This should be a solution for the RGB-WG/rgb-std#36 issue. Please test it in your projects by adding
to your workspace-level
Cargo.toml
files(of course you need to start with new stash and issuing new contracts, otherwise it won't work)