updated release note

Author: polymorpher

wiki/updates/v15.md

@@ -4,60 +4,65 @@ This update provides substantially enhanced security, usability, and functionali
 
 ### Major updates
 
-1. 1wallet address and creation time are now part of the authenticator account name.
+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. 1wallets created since v15 can be recovered by providing 6 consecutive authenticator codes, plus a recovery file. Using this method, a new authenticator must be setup afterwards.
+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. Restoring a 1wallet created since v15 no longer requires an address to be provided explicitly.
-4. 1wallets created since v15 can increase the spending limit, by at most 100% of the current limit per day
-    - If the user set custom spending limit and spending interval, the custom interval will be used in lieu of "per day"
-    - Spending limit can also be lowered (to 0 at minimum)
-    - Spending limit can be restored to historical max, but it would require 6 consecutive authenticator codes (36 digits in total).
-5. 1wallet is now verifiable through a smart contract function
+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](https://github.com/polymorpher/1wallet-qr-parser) (see Technical Notes below)
+4. **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.
+5. **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.
-6. Renewing the life of a 1wallet created since v15 requires 6 consecutive authenticator codes (36 digits in total).
+6. **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.
-7. 1wallets created before v15 are deemed "created since v15" if the 1wallet is renewed after v15. 
+7. **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. 
-8. Transactions are now executed a lot faster.
+8. **Promptly displayed spending limit**: Spending limits and remaining limits are now promptly displayed on wallet home screen.
+9. **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.
+10. **Fast transactions**: Substantial improvements were made in relayer and client contract calls. Transactions are now executed a lot faster.
 
 ### Technical notes
 
-1. A mass 1wallet restoration helper CLI tool is released at https://github.com/polymorpher/1wallet-qr-parser, designed for people who have too many authenticator accounts to manually deselect non-1wallet accounts.
+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. 1wallet addresses are now predictable upfront (following EIP-1014 CREATE2 standard) and its code integrity is now verifiable.
+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. An ECDSA public key is generated using the authenticator seed as the private key. 
+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. 1wallet operations are now divided into normal operations and sensitive operations. Sensitive operations require 6 consecutive authenticator codes to authorize.
+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" 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)
+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. 1wallets created since v15 generate 7 OTP merkle trees instead of 1 (as before v15). 
+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. Three operations are considered sensitive at this time
+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 add many new parameters for `/create` API calls (to create new 1wallets) for v15 compatibility
-    - Apps wish to continue to create v14 1wallet may add `X-MAJOR-VERSION` header to the REST call with a value of `14`, or add `majorVersion` as a body parameter.
-    - Apps' existing 1wallets based on older versions (including v14) can continue to rely on endpoints such as `/commit` and `/reveal` without any change, provided that they use 1wallet core library (Javascript) for REST requests, or already use appropriate headers (`X-MAJOR-VERSION` and `X-MINOR-VERSION`) or body parameters (`majorVersion` and `minorVersion`) if they use custom implementations.
+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 `v14.relayer.1wallet.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)