Account ID anchor complicates account reconstruction #1258
Replies: 3 comments 2 replies
-
|
Yes, I believe this captures the problem correctly.
Is this enforced somehow? For instance, could I execute a transaction of a new account with the reference block being in a different epoch than the anchor block? I thought it was but the "ideally" is confusing me.
Is brute-forcing the epoch until you find a matching Account Id on the chain a possibility? I guess the problem is still the same (you need external input to confirm), but maybe it's less annoying and a bit more standard-compatible than storing the anchor block separately.
Correct. I don't think you need all transactions, but at minimum you would have to know the nonce, storage state, account code and vault assets related to the latest state that was recorded on-chain. Worth noting that for a standard wallet this also implies knowing the account's secret key (since the public key is part of the storage layout), but this also applies for public accounts. |
Beta Was this translation helpful? Give feedback.
-
The client can choose the anchor freely. It is "ideal" to choose a recent anchor because the window for the attacker to compute a rainbow table with exactly that anchor is shorter than for, say, the genesis anchor. "Latest" implies the transaction kernel knowing what "latest" means and since the client also chooses the reference block, which is the only time reference the tx kernel has, it would be pointless to try to enforce this, I believe.
It is possible in theory, but I don't think it is a viable strategy. Even if you can narrow down the set of possible anchors, I think it would still take prohibitively long to find it. It is not a constant time either. The longer the chain gets, the longer it takes to find the ID. But yes, it would technically be better for standards compliance.
Agreed. The secret key can be derived from the mnemonic assuming a BIP-39 compatible wallet. But as Bobbin mentioned below, this is basically only for public accounts. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to list pros/cons of having the anchor block (the way I see them):
The last point is a fairly narrow use case - i.e., it is only for public accounts, which are not network accounts at the same time. It is useful and convenient, but assuming most accounts will be private in the future, it will have relatively little relevance. On the other hand, the highjacking attack is also pretty narrow and largely hypothetical at this point in time. Executing it would require tens of billions USD (if not more) with questionable benefit. It is also not retroactive - i.e., it cannot be applied to accounts which have already been recored on-chain. And by the time when it becomes relevant, we may have found a different way to address it (e.g., via more PoW or otherwise). So, my current thinking is that we get rid of the anchor block for ID creation. If/when it looks like it may become a real issue, we can re-introduce it - or come up with a different solution altogether. |
Beta Was this translation helpful? Give feedback.
-
|
If we remove the anchor, the layout of an ID essentially becomes: This increases the collision resistance of the hashed part from currently 52 (104 / 2) to 60 (120 / 2) bits, which is not much more. But I agree that the highjacking attack is fairly impractical because it is expensive and applies only to a narrow set of circumstances. I imagine users are typically not creating accounts and immediately sending tons of funds to it. The approach of sending a small amount to a new address (or account) first is classic and cautionary. Wallets can even recommend to send enough funds to cover the fees of the account-creating transaction, but not much more. With that in mind, it seems unlikely that an attacker would see a major opportunity in this. We may still need a solution for the frontrunning DoS attack, but I think we need to address this in a different way anyway. This would be practically solved if we can lift the account ID prefix uniqueness requirement, so that frontrunning would require a match on the entire 120 bits ID. |
Beta Was this translation helpful? Give feedback.
-
|
This is tracked in #1291 now, so closing this discussion. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The strength of the anchor block commitment is that it is an "external parameter" that cannot be predicted, and thus results in its salt nature that makes it hard for attackers to pre-compute rainbow tables of account ID seeds.
The exact flip side of this is that the anchor also prevents a client from deterministically reconstructing an account ID from just the
SEED. Ideally, the anchor is chosen as the latest available epoch block at account creation time by the client. Therefore the anchor block number cannot be derived from theSEED. Essentially, the user would have to store the tuple(SEED, anchor_block_number)for later reconstruction of the account.One question it raises is what the larger strategy is for account creation and the source of the seed. It seems like a good idea if we were able to integrate with existing standards like BIP-39 mnemonics that are supported by just about any blockchain (and hardware wallets, in particular). If we derive the account ID
SEEDfrom such a mnemonic, then the extra anchor block number would be an additional Miden-specific parameter that users would have to save somewhere, which results in bad UX.If we somehow don't plan to integrate with that and users have to store the
SEEDseparately from the mnemonic used for key derivation anyway, then storing the anchor block number as part of it would be straightforward.So I'm curious if we already have a strategy in mind for this, because that influences how we deal with the anchor block number.
My opinion is that it would be great if reconstructing (public*) accounts were possible only from a BIP-39 mnemonic, so we'd have to do something with the anchor. Essentially either 1) getting rid of it and using another strategy to strengthen the ID security (e.g. more PoW) or 2) somehow deriving the anchor from the mnemonic (which I can't see how it would be securely possible).
* For private accounts, the entire state is necessary anyway for reconstruction, right? Because even if we can restore the original state of an account (e.g. standard account with basic wallet + auth), if we have applied just a single transaction to that account, then its state in the chain will be different from the original one. And so, unless we have all those transactions, we can't reconstruct the latest state.
Please let me know if I have captured the problem correctly, @igamigo or @SantiagoPittella.
Beta Was this translation helpful? Give feedback.
All reactions