Tag inclusion

[ivanlele]

Project

compiler

Describe the feature

We are currently drafting a Simplicity metadata registry concept.

We need to somehow include metadata information in CMR. The need for this arises from the potential for an adversary: a malicious party can submit forged metadata to the registry and verify CMR with it. The solution is to include the metadata during compilation.

I propose a compilation option that includes a 32-byte tag with the main node as the compiled node, e.g., comp(main_node, tag). By default, the compilation result will be just the main node if no tag is provided.

The existence of such a tag can serve other purposes, such as:

• Domain separation
• Protocol binding
• Source provenance (git commit, for example)
• Version binding

Currently, a workaround is to create a constant in source files, but it is not programmable enough; for example, if a framework (Simplex, etc) includes this tag dynamically, it would need to modify the constant each time, and it will be a bit intrusive, but if we have a compilation option, then the framework can utilize this instead of cheap hacks.

[stringhandler]

I might be missing something here, but if the wallet can find the correct CMR with the metadata, could it just find it without it? My concern with adding metadata directly into the CMR is that every transaction would then need to include it so the simplicity program matches the control block

[ivanlele]

I might be missing something here, but if the wallet can find the correct CMR with the metadata, could it just find it without it? My concern with adding metadata directly into the CMR is that every transaction would then need to include it so the simplicity program matches the control block

It’s more of a wiseverse; the wallet needs a way to find Metadata via CMR.

Yeah, I fear there is no way around it: this tag must be included in the transaction for the program to execute. But this option still will be optional; by default, things will stay as they are now.

[apoelstra]

In what situation would the wallet have a CMR but nothing else?

[apoelstra]

IOW, the on-chain CMR is already useless to a wallet because

• it is invisible until the contract has been spent
• includes fixed values for all parameters and therefore won't appear in any registry
• does not commit to contract state, which may also be relevant to the wallet

So there's no reason to attempt to put other stuff in there which isn't even useful to the blockchain.

[stringhandler]

I think allowing a way to generate arbitrary "correct" CMRs with metadata actually will make forging real contracts easier

[apoelstra]

If we actually want a commitment, we may want to move metadata into the "canonical CMR" #293

But I don't think this is necessary. Ultimately, the metadata and the (canonical) CMR will wind up in the registry together. Merging the the metadata into the CMR won't accomplish much other than giving the illusion that the CMR is "self-validating", which could lead to fraud as @stringhandler says.

[Arvolear]

Let me try to explain the problem differently:

Upon interaction with a dapp, a wallet will receive the full flattened source code of the SimplicityHL contract as described in the ELIP here. The dapp will also pass the metadata for the wallet to verify its legitimacy against the registry. The wallet will produce a contract_id (ccmr + metadata), query the registry, and verify the publisher (partner/audited/etc).

If the metadata is not committed to the source, anyone who has access to the source code can upload fake metadata to the registry first (before a developer), and claim the 1-to-1 ccmr -> metadata mapping. Essentially, forging the rendering for this contract forever.

[Arvolear]

If we actually want a commitment, we may want to move metadata into the "canonical CMR".

We don't really need onchain commitment, rather a way to produce a unique contract_id that can't be "front run". And this commitment may not even be the metadata itself, a big random number will also suffice.

[stringhandler]

It seems like the only problem here is the race to register it in the registry, which can be solved with disputes. Any developer who creates a dapp and releases it, will not have any wallets be able to utilize it. What's more, a fake company can possibly register against the existing CMR, but cannot alter it to inject any bad code.

There is a small chance that they can publish an update, but that is a whole other problem entirely.

[Arvolear]

Since the wallet will only know a contract_id (not a developer/organization like on crates/npm) to fetch the metadata from the registry, front-running may potentially be a huge problem. Open source projects may be vulnerable, and fixing the potential vulnerability on the design stage is much better than relying on the fact that something won't happen.

[stringhandler]

Say I have a program:

fn main() {
    jet::bip_0340_verify((param::ALICE_PUBLIC_KEY, jet::sig_all_hash()), witness::ALICE_SIGNATURE)
}

This currently has a CMR of 1abc423d746ee0fff5bb8ad259bec3b89d319f08a425d6b8092e9c1c5ec7d465 (Assume for the example that the CMR is the canonical CMR/contract id).

What exactly is the attack you are describing? Someone else registers their metadata on the registry, and then?

---

Assuming there is some advanced attack. Can you write out how the CMR should be changed. I don't think there is a real problem here, but I also think the solution proposed in the issue is flawed. Please use this example so I can see what you intend the wallet to have?

[Arvolear]

The only thing that the wallet has is the contract_id. If someone acquires the source code and publishes malicious metadata to the registry first, the legit developer will have to modify the code (which may already be audited) to produce a different contract_id to disambiguate.

Let's say the metadata for a particular contract should say "Give x LBTC, receive y USDT". However, a malicious one may be "Claim y USDT as an aridrop". There is no way for the wallet to tell them apart.

I propose to construct a contract_id like that: tweak(ccmr, <random_number>) and use it as a unique identifier under which the metadata will be uploaded. It doesn't have to be onchain. Then a web app will have to provide the wallet not only the source code, but also this random number for it to construct the contract_id and fetch the correct metadata from the registry.

P.S.

If the web app is hijacked, there is no secure way to prevent malicious metadata provision in both cases. However, with the random number approach at least we can prevent the front-running issue.

[stringhandler]

What stops an attacker from publishing a different random number with the faked metadata? It also seems like you could just have a random registration number on the registry website to allow multiple registrations.

When you say tweak, does that appear in the transaction at all?

[Arvolear]

Nothing is stopping an attacker from doing that. However, a legit front end will use its own legit random number.

We can have a registration, but the registry endpoint for the wallet will look like this: GET /metadata/<contract_id> NO AUTH. See that there is no "publisher" identification there.

When I say tweak, I mostly mean hash. It's an offchain action.