Fix operation id by using proper conceal

[dr-orlovsky]

This should be a solution for the https://github.com/RGB-WG/rgb-wallet/issues/36 issue. Please test it in your projects by adding

[patch.crates-io]
rgb-core = { git = "https://github.com/RGB-WG/rgb-core", branch = "fix/op-conceal" }

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)

[nicbus]

tried patching rgb-core (also updated rgb-core dependency in rgb-std to 0.10.1)

starting from scratch and trying to issue an RGB20 asset I get the following error:

thread 'main' panicked at 'current version of RGB Core doesn't support production of bulletproofs. The method leading to this panic must not be used for now.' , ~/.cargo/git/checkouts/rgb-core-545e07908459752c/c5e4b05/src/contract/fungible.rs:217:9

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):

rgb -n regtest -d data issue 4h3xkAmiRdQs2HwQmnFVqoj5DG3NhGkJRpNZXjNrJT2N RGB20 contract.yaml

I'm using patched versions of:

• rgb-core, as per this PR
• electrum-client, from https://github.com/RCasatta/rust-electrum-client branch bitcoin_0_30
• rgb-wallet + rgb-std, locally patched to set opret/tapret host (upcoming PR) and depend on rgb-core 0.10.1

[dr-orlovsky]

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 OpId was not completed BTW.

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.

[crisdut]

I tried reproduce the same tests I made here with this patch, but I receive the same error:

Error: absent information about bundle for operation 299dbb918982b15d302d20c988b6f2ad56279f988089a45a79cb44b5816e5951.
It may happen due to RGB library bug, or indicate internal inventory inconsistency and compromised inventory data storage.

[dr-orlovsky]

I have the solution, but it requires some work.

In client-side-validation we have two main encodings: strict (strict_encoding crate) and commitment (CommitEncode, CommitmentId and commit_encode::Strategy traits from commit_verify crate).

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 conceal is first called and than a new structure with concealed data is written to the hasher. It is required to make sure that the commitment id does't differ between revealed and concealed variants - and the reason of the original issue was the use of strict strategy instead of conceal-strict strategy.

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 commit_encode_derive crate. Hoping to complete the task by Monday.

[crisdut]

For now commit-encode uses one of two strategies: either strict encoding, just writing to the hasher, or conceal-strict, where a conceal is first called and than a new structure with concealed data is written to the hasher. It is required to make sure that the commitment id does't differ between revealed and concealed variants - and the reason of the original issue was the use of strict strategy instead of conceal-strict strategy.

Ok, sure. Thanks for explanation.

I will use a derivation macros for that, and for that need to create commit_encode_derive crate. Hoping to complete the task by Monday.

OK, Do you have anything I can help with?

[dr-orlovsky]

OK, Do you have anything I can help with?

Not at this moment :( But later of course with making sure everything works as planned.

[cryptoquick]

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. https://docs.rs/blake3/latest/blake3/fn.keyed_hash.html

Very clever to separate hashing from serialization, btw!

[dr-orlovsky]

It is not keyed or hashed per se. The keyed hashing is performed by CommitmentId calling CommitEncode which may use that strategy. CommitEncode works with any io::Write