On Telegram, Vladislav Gelfer of BEAM fame,
announced his creation of a Multi-sig RFC for Grin [1].
Let the commenting begin!
6 Likes
Should we comment here?
I don to see any comment button or field when I go to the proposal. Or are special rights needed for that?
1 Like
Here are my first thoughts and questions about this proposal:
Regarding the “Moniker”. If I understand you correctly it is something akin to a unique user ID.
Would it not be logical to include the slatepack address in the hash input to force uniqueness?
E.g.
hash("actor-"|"Anynomous"|"_grin1testjvsvwm3nrh7ueas8vanjs0tmvymetskf5qwl7cjmkqy7lm0sy0wmcs")?
Some questions about the part on new actors
Unlike initial actors, that can generate/restore an arbitrary secret key, new actor’s key is uniquely defined by its moniker.
I am still trying to understand this part.
I assume that the share for new users is different because the shared secret is already fixed at this point, meaning you can only derive a share and not predefined one unless you would create a new MultiSig wallet with new shared secret. If so, we need to allow the user to backup this share in the form of a new wallet file and a mnemonic, or add the encrypted share as an extra field to an existing wallet. Since Grin wallets store sthe raw entropy and not seed_bytes (hashed mnemonic) this should not be an issue since you can derive the mnemonic form the share). However, the process might be a bit different since you need an existing wallet to start the creation of this extra share 
Regarding the use of a Coin number.
I assume this refers to something like the index number in BIP44 HD wallet derivation, or even its full derivation path? If so, should the full coin number be XORed in the range proof? Just pondering about security here since you do want the publick key to allow Actors in the MultiSig to scan for outputs, yet you want the coin number to be only decryptable to MultiSig Actors and not everyone who has a rewind hash. Is there a way to store the coin number in the range proof only decryptable for the MultiSig Actors?
I searched if this is possible to encrypt such information while keeping it small enough to XOR in the range proof. Threshold ElGamal would result in to big an output 256 bytes, Lumo (AI) suggested “What you can do is combine a tiny symmetric cipher (AES‑GCM, ChaCha20‑Poly1305, etc.) with a threshold public‑key layer. The public‑key part protects a short symmetric key (16‑32 bytes), while the bulk of the data stays encrypted with the lightweight symmetric algorithm. The final transmitted blob is therefore only a few dozen bytes larger than the original payload.” - That is just AI output, I do not know if this would be secure enough or if there would be an alternative approach. The main point for me is that the coin number should always be recoverable, even if all key-holders have to recover their wallet from their mnemonic.
The proposal states
Each new coin number should not be completely random.
Does this also mean that the coin number should also always contain a random generated part? To me it sounds like the coin-number should be a concatenation of the outputs hd wallet path or index number (deterministic) with some random number should suffice. In this way it should be impossible to ever use the same coin number twice.
1 Like
-
Regarding inclusion of the slatepack address in for uniqueness - that’s an option.
Perhaps the slatepack address should even replace the moniker: it’s not only a unique ID of the user, it also (as I understand) includes the communication instructions.Most importantly: the user ID is converted into a scalar that uniquely defines the secret key ID (technically - the x-coordinate of the polynome with secret coefficients).
It’s important to make sure there’s no feasible way to craft a user ID that is transformed to a known key ID (in particular, key ID of a coin).
Hence no matter what the user ID/moniker is, it should be hashes with some prefix (like “actor-”) to separate it from coin keys (which use “coin-” prefix). -
Regarding the coin number.
I think there’s a confuse here. The so-called “coin number” is NOT secret, it’s not the blinding factor, and there’s no need to encrypt/decrypt it. You may allow anyone with the “view key” (or whatever it’s called in grin) not only to identify your coins, but also recover its value and the coin number.
Moreover, once the coin number and the value are recovered, each actor can also individually derive its pubkey (i.e. G * blinding_factor). This is good to filter-out false positives.The whole scheme works like this: (coin_number, value) → x_coin → blinding_factor
The “view key” is used to derive randoms for the bulletproof, the (coin_number, value) are XOR-ed and then recovered. Together they should be much less than 256 bits, which leaves many leading zeroes as a trigger for coin recovery.
But - the blinding factor is different. The randomness that protects it (tau1, tau2) is derived by each actor individually, and not possible to reproduce by any key.
-
“Each new coin number should not be completely random.”
I meant, coin numbers should be somewhat like auto-increment integers. Like 1, 2, 200, etc.
If the last coin number used was, let’s say, 200, there’s no reason you’ll be asked to sign a transaction where being-spent coin number is a huge number, this can be a sign that someone tries to manipulate coin numbers to get the desired delta blinding factor.But I’m not sure such precautions are really needed. When the polynome degree is high (i.e. ~10 and up) this seems like a really hard problem. Maybe it’s already infeasible for degree=1, I’m not sure.
BTW, the polynome degree can be raised artificially. In the RFC it’s assumed that each actor gets 1 share, hence M actors define M points of the polynome, means its degree is M-1.
But there can be more shares. For example, each initial validator can generate several private keys, means more points for the polynome → higher degree.
It’s also a nice exotic feature: each actor can have different number of shares, means it will have a different weight in the quorum.In short - this can be worked around. Polynome degree can be raised, such that even theoretical threat of Wagner-like attack will not be practically possible.
2 Likes