...
- The easiest address to implement is exposing the full public key
- For security might prefer to expose a subset of the public key. If we use the first half of the bytes as the address, the probability of two accounts sharing an address is astronomically small (1 in 1024).
- Also for security we can use the RsDSA25519 key exchange algorithm which doesn't expose the public key at the cost of performance.
- For maximum compatibility with Substrate, we should choose the SS58 format.
...
It is assumed that changing the alias of an account requires knowledge of primary and secondary keys, so gaining control of the alias is equivalent to gaining full control of the account. Security measures largely overlap, which includes account archival (freezing).
Most While a lot of attention is paid to software security in Ethereum, most attacks on the Ethereum chain happen as a result of social engineering and user error.
For example, one attack vector we can So we should protect against is account aliases that are sufficiently similar, but not identical in terms of name resolution. Compare:
...
the strings look identical, but have different UTF-8 representation: the а and е, characters are taken from the Cyrillic code page, and the two accounts have different on-chain representations. It would
A potential solution would be to warn the user whenever they send funds to a new address, which crosses a (dynamically computed) Levenstein distance threshold from the known recipients. We need to have a low false-positive rate, so that users are not tempted to turn off the annoying notification.
Using a new custom instruction: MigrateAccount<Account, Account>
...
Key collision is not a factor: It is astronomically unlikely that two ed2559 keys coincide. Specifically, it's 1 in 2256 or 1 in 1077. The probability of no two keys coinciding given that the ed25519 algorithm works as advertised is 10-69 (due to the birthday paradox) exp[-10-69 ], if there are 108 or one hundred million accounts on the same network. Even assuming that the number of historical accounts is larger, it is practically impossible to generate the same key twice.
...
- the account that wishes to de-archive another account must retain the private key corresponding to the archived account. If the key is lost the account is archived permanently. Only the owner of the primary key can request archival.
- Before or during archival another account may be optionally nominated as a successor. If such an account exists, de-archival requires knowledge of both (primary) private keys. Losing either one locks the account permanently.
- After archival, smartcontracts involving the archived account fail with an error message. After de-archival smartcontracts resume operation as normal. Triggers .
- It's possible to remove smartcontracts from an archived account. It's not possible to add any.
- In case 3.c, a thief gains nothing from archiving an account with a pre-nominated successor. Financial gain can still be extracted from deleting accounts (blackmail).
For point 3 to work, triggers must be given facilities to accumulate information about previously failed execution attempts (e.g. special metadata). This is necessary, because archival can be used to avoid smart-contract-based payments. In principle, this would allow people to purposefully archive their accounts after benefiting from a specific arrangement (e.g. default on their loan payments
...
). There is no blanket solution to this, however. It's
...
all up to the specific case where default occurred. For example:
- Defaulting on a loan happens outside of blockchain contexts. It is the responsibility of the loan provider to handle default.
- Recurring payments for recurring services may automatically cancel the smartcontract after a set number of failed payments.
- If the user archives the account tactically, so as to avoid specific payments it is the responsibility of the smartcontract to exchange resources atomically.
Transaction rollback
After archival, all pending transactions submitted from an archived account, but not executed at the time of archival are frozen: removed from the queue and added to a special section in the Archived account. When the archival is reversed the transactions are remembered, but not automatically re-submitted. Which transactions are to be re-submitted is chosen by the user after de-archival.
...
We can freeze the transactions that are still in the pipeline and submitted from a potentially compromised and archived account and that is in line both with what banks can offer, and relatively easy to implement.
In a blockchain setting, services like Kirobo offer the option to reverse unclaimed transactions only. Claimed transactions cannot be reversed unless both parties agree to a transfer (which in case of a malicious actor is unlikely). Kirobo also uses a weak password system that is prone to user error. Reverting already committed transactions is not something that even banks do, so the utility of first-party support on Iroha networks is dubious.
Changes to the Client API
...