About Grimm. Part 2.

• My first post about Grimm project
• Response from Grimm people

This is my 2nd post about Grimm. Hopefully it will be the last one.

I’m not going to argue about the rights and wrongs, ethics, or wage holy wars (I’m too old for this). I have nothing to add to my previous post on those subjects.

Instead I will now focus on tech stuff: the code, comments and remarks by Grimm people. So that the level of competence of those “MW developers” would be clear for everyone.

Assetchains

Confidential Assetchains is 100% XGM implementation, not even mentioned in ANY beam document or source code. Confidential Assetchains developing by Grimm from scratch (initial commit4d2c7ea1fa93f597cc874e91cf5d54c10088131a).

This is what I was looking for. According to the code, in contrast to what they say, their implementation is clearly based on our cryptographic code and design.

• Same Design: unrestricted emission by everyone, AssetID as a public key, from which the appropriate NUMS generator is derived
• Asset emission control via TxKernel::m_AssetEmission signed by the asset private key (by its owner). This is where it’s broken! (more about this later)
• Modified bulletproof (rangeproof) for CA.

Those are essential components of the CA support, and they are fully developed by Beam and taken as-is.

As I can see, Grimm devs implemented support for this in the wallet: added AsserID to TXO management structure (with is then used in inputs/outputs generation), and added asset control transactions (obviously based on our examples).

I can give them credit for doing this considerable (yet straightforward) piece of work. But, as I mentioned, there’s essentially no new cryptography in their code.

Is this enough to call it “100% XGM implementation?” I let you, dear reader, to decide for yourself.

What’s wrong with this design?

In my previous post I said it has “vulnerabilities”. Now I’ll rephrase, to make it 100% clear. It is insecure.

Not reviewed well enough back then, not intended to be used in production. Now, after we resumed working on it, we know: it is totally insecure. Broken.

We know at least 2 feasible attacks, by which an attacker can emit someone else’s asset to itself (reminder: according to the design only owner is allowed to emit/burn its asset).

One of the attacks is straightforward and very practical. Although I believe right now Grimm has no real-world usage for this (i.e. it’s just a PR gimmick in my opinion), I will not disclose the details publicly until I get their permission.

The second attack is more sophisticated, and, in some sense, not limited to CA only, but is rather an inherent threat in MW, if not taken care of. Prior to disclosing it we’ll discuss it with all MW projects. Important to note that this problem is only related to Confidential Assets and not to the regular coins.

Grimm devs about (what they believed to be ) vulnerability in Beam code

… And it’s not true) Everyone can enable your “assets” on YOUR (BEAM) mainnet, just by commenting this two strings in file core/block_crypt.cpp:

…

We can go even further and comment the following lines:

…

Giving ANY user a malicious ability to create uncapped tokens supply on Beam mainnet.
In Beam implementation, this would mean vulnerability if they have working assets.

This is just hilarious. Looks like those guys don’t understand the very basics. So I’ll clarify (for them).

If you cheat in your source code by commenting-out some code lines, then indeed you may create a block that violates the agreed consensus rules.

But would it be accepted by the network? … drums rolling … Of course not.

In a trustless network each block is verified by each node. If the rules are violated, then the block will not pass the validation by the majority of nodes running stock code, will be rejected, and you will be banned.

So committing to a set of rules in configuration (a.k.a. Rules signature) and then acting against them — this is just a stupid thing to do, this does not make any sense.

The reason we use this signature in the protocol is to detect incompatibilities at an early stage. That is, it’s just a graceful way to say good bye, instead of polluting each other. This is how we achieve isolation for different blockchain configuration. By no means it is supposed to be a “proof” of compliance to those rules!

What else to add?

The response from Grimm people only reinforced my opinion, which I expressed in my previous post. These are simple facts:

• No new cryptography
• Using piece of code not currently maintained by us, without understanding it, or at least asking us about it
• Ridiculous technical comments, demonstrating their incompetence in the subject

Are those MW developers/researchers? The net result of their work to the moment is a rebranding, plus a PR gimmick based on a broken implementation of the scheme they don’t fully understand.