v15.1 - restore wallet with 4 new ways, booster shots for wallet security (with 6x6 auth codes), adjustable spend limits, and many others

1Wallet v15 release notes

This update provides substantially enhanced security, usability, and functionalities.

Major updates

1. Wallet address in authenticator: 1wallet address and creation time are now part of the authenticator account name.
   • Example: Movie Wood 21-12-24 16:27 [one1397exhkl6t55z2w5ff6z9np0pw6vmydhy8uzd0]
   • Only two random words are now used for the wallet's name.
   • The format is [word1] [word2] [YY-MM-DD HH:mm] [one1... address]. Time is local.
2. Restore 1wallet without exposing seed QR Code: 1wallets created since v15 can be recovered by providing 6 consecutive authenticator codes ("6x6 auth codes"), plus a recovery file. Using this method, the user must setup a new authenticator code in the process.
   • The recovery file contains no sensitive information and it can be safely stored anywhere, even publicly.
   • The recovery file is available for download at any time, but is only available for 1wallets created since v15.
3. Restore 1wallet without address: Restoring a 1wallet created since v15 no longer requires an address to be provided explicitly.
4. Restore 1wallet using local import/export: Local import and export processes (using .1wallet files) are redesigned to make cross-device synchronization easy and seamless.
5. Restore 1wallet using JSON export: 1wallet can be restored using JSON exports produced by 1wallet batch restoration tool (see Technical Notes below)
6. Adjustable spending limit 1wallets created since v15 can increase or decrease its spending limit, without requiring the user to create a new wallet. Depending on the amount, the operation may require a simple 6-digit auth code, or 6x6 auth codes.
   • Spending limit can be increased to up-to 2x the current limit plus 1.0 ONE, per spending limit interval (1 day by default)
   • Spending limit can be decreased to any amount (including 0 ONE) at any time (no time restriction)
   • Spending limit can be restored to the wallet's all-time-high limit, with 6x6 auth codes. (no time restriction)
   • Example: a wallet starts with 1000 ONE limit per day. The user then increases its limit to 2001 ONE (using simple 6-digit auth code). The user then decides to lower the limit to 100 ONE (again using simple 6-digit auth code). Now, if the user wants to increase its limit to 200 ONE, it must uses 6x6 auth codes, because the user has to wait for a day to increase the limit using simple 6-digit code. But if the user waits for a day, he can again change the limit to 200 ONE using simple 6-digit code. However, if he wants to change the limit back to 1000 ONE or 2001 ONE, he would need to use 6x6 auth codes.
7. Verifiable 1wallet contract: 1wallet is now verifiable through a smart contract function
   • External services may use this to verify whether an address is a 1wallet or not
   • Users and apps could use this to check the on-chain code integrity of their 1wallet.
8. More secure renewal: Renewing 1wallet created since v15 requires 6 consecutive authenticator codes (36 digits in total).
   • The user may optionally setup a new authenticator code after renewal.
9. Unlock v15 features with renewal: 1wallets created before v15 are deemed "created since v15" if the 1wallet is renewed after v15.
   • Only normal 6-digit code is required if it is the first time the 1wallet is renewed after v15.
10. Promptly displayed spending limit: Spending limits and remaining limits are now promptly displayed on wallet home screen.
11. Promptly displayed errors: When an operation fails, errors are promptly displayed as notifications. The user will not be misinformed with a simple "Done" message (indicating success) as they were in v14 or before.
12. Fast transactions: Substantial improvements were made in relayer and client contract calls. Transactions are now executed a lot faster.

Technical notes

1. Batch restoration tool: A batch 1wallet restoration tool (based on command line) is available at https://github.com/polymorpher/1wallet-qr-parser, designed for people who have too many authenticator accounts to manually deselect non-1wallet accounts.
   • Please use this tool offline to avoid security risks and hacks, and delete all generated images and QR codes promptly after the use.
2. Predictable address: 1wallet addresses are now predictable upfront (following EIP-1014 CREATE2 standard) and its code integrity is now verifiable.
   • The address depends on only the current version and the authenticator seed.
   • Several factory smart contracts are made available, responsible for creating and verifying 1wallets.
   • The bytecode of 1wallet can also be retrieved from those smart contracts.
3. Public key / seed as private key: An ECDSA public key is generated using the authenticator seed as the private key.
   • Thus, authenticator seed is now randomly generated for 32 bytes, instead of 20 bytes.
   • The public key is stored on the 1wallet smart contract as an identifier key, which is used for code integrity verification and various other purposes.
   • The private key may used in the future for special purpose operations (e.g. operate the wallet after expiry time)
4. Enhanced security: 1wallet operations are now divided into normal operations and sensitive operations. Sensitive operations require 6 consecutive authenticator codes to authorize.
   • The concept of "core" and "recovery core" are introduced and documented on 1wallet smart contract. They are responsible for verifying normal and sensitive operations, respsectively.
   • Each core or recovery core contains security parameters which authenticator codes will be verified against.
5. "Core" parameters: "Core" is used for verifying EOTPs resulted from a regular 6-digit authenticator code input. "Recovery Core" is used for verifying EOTPs resulted from 6 consecutive authenticator codes (36-digits)
   • "Core" and "Recovery Core" can be accumulated (e.g. by recovery via 6 consecutive authenticator codes, or by extending life).
   • For any EOTP input, it will be verified against all cores of the same type accumulated so far, and the EOTP is considered correct as long as it matches one core.
   • Cores cannot be removed as of now, but their setup time can be viewable so the user can check whether a new core is added unknowningly to the user.
6. More Merkle trees: 1wallets created since v15 generate 7 OTP merkle trees instead of 1 (as before v15).
   • The 6 new OTP merkle trees are for recovery purposes.
   • Each OTP merkle tree corresponds to a "core" as mentioned earlier.
7. Sensitive operations: Three operations are considered sensitive at this time
   • Adding a new core (used in "Renew" and "Restore"), because if it is the attacker who did it, they would gain prolonged access to the wallet
   • Adjusting spending limit to be more than 2x of the current limit (but no more than historical maximum of the 1wallet), because an attacker could potentially steal a large sum of money after adjusting the limit, even if the user intended to freeze the 1wallet (by setting limit to 0).
   • Permanently forward assets beyond spending limit to another 1wallet (used in "Upgrade" feature), but without an recovery address. This is because normally only assets up to spending limit would be forwarded, and the remaining amount needs to be approved by using the recovery address to send 0.1 ONE to the 1wallet. Without an recovery address, the operation becomes very sensitive since the user could potentially lose all their assets if it is the attacker who executed the operation.

Backward compatibility

1. 1wallet web client (1wallet.crazy.one) and relayer will be fully compatible with older verions of 1wallet.
2. Apps relying on 1wallet relayer must decide which version they want to use, and (1) either add the new parameters required for /create API calls (to create new 1wallets) for v15 compatibility, or (2) switch endpoints to a v14 URL.
   • Apps wish to continue to create v14 1wallet must use a new endpoint at v14relayer.onewallet.hiddenstate.xyz.
   • Apps whose existing 1wallets are based on older versions (including v14) can continue to rely on v15 endpoints such as /commit and /reveal without any change, provided that (1) they use 1wallet core library (Javascript) for REST requests, or (2) already use appropriate headers (X-MAJOR-VERSION and X-MINOR-VERSION) or body parameters (majorVersion and minorVersion) if they use custom implementations.

Next updates (minor versions)

In the minor updates of this major version (v15), we will add integration with built-in authenticator provided since iOS 15, macOS Monterey, and Safari 15. We will also add email/password as an option to the user, for cross-device (even cross-app) wallet synchronization, email alerts, recovery-file storage, and more. We will also provide storage services (for recovery files) and potentially 1-click synchronization with iCloud, Google Drive, and Dropbox.