Signing in TON page #865
Signing in TON page #865
Conversation
|
/review |
|
Thanks for the updates to the signing techniques docs. A couple of high‑severity items need changes to meet the safety and style‑guide requirements. Findings (2)High (2)[HIGH] Unsafe inline mnemonic example and non-compliant placeholder/ellipsisDescription: Suggestion: // Read from environment; do not inline secrets
const mnemonic = (process.env.MNEMONIC ?? 'MNEMONIC_WORDS').split(' ');[HIGH] Safety callout for mnemonics is missing required elementsDescription: Suggestion: --- a/techniques/signing.mdx
+++ b/techniques/signing.mdx
@@
-<Aside
- type="danger"
->
- **Protect your mnemonic:** Anyone with access to your mnemonic can control your wallet and all funds. Store it securely (password manager, hardware wallet, encrypted storage). Never commit it to version control.
-</Aside>
+<Aside type="danger" title="Keys at risk">
+ Risk: Anyone with your mnemonic can control your wallets and funds.
+
+ Scope: Affects every wallet derived from this mnemonic (testnet and mainnet).
+
+ Mitigation/rollback: Store mnemonics in an encrypted manager or hardware wallet; never paste into logs or code. If exposed, generate a new mnemonic and move funds to new addresses.
+
+ Environment (safer first): Use testnet mnemonics for development; avoid mainnet keys in examples and tests.
+</Aside> |
|
can we add link to it page in wallets: how it works? |
of course we can |
| This guide focuses on Ed25519, the standard for TON. | ||
| </Aside> | ||
|
|
||
| ### What gets signed |
There was a problem hiding this comment.
maybe rename it?
seems like full pipeline, not what gets signed
|
|
||
| ## Message structure for signing | ||
|
|
||
| When designing a signed message, you choose how to organize the signed data — the message fields that will be hashed and verified. The key question: is the signed data a **slice** (part of a cell) or a **cell** (separate cell)? This affects gas consumption during signature verification. |
There was a problem hiding this comment.
it's depends on data size too, may be here add examples?
| **Trade-off:**\ | ||
| This approach adds one extra cell to the message, slightly increasing the forward fee. However, the gas savings (\~500 gas) outweigh the forward fee increase. | ||
|
|
||
| ### TVM v12 improvement |
There was a problem hiding this comment.
do we really need it? I guess before update It's not valid, and after update we can rename it like "possible improve"
| npm install @ton/core @ton/crypto | ||
| ``` | ||
|
|
||
| ### Step 1: Generate or load a mnemonic |
There was a problem hiding this comment.
can we create issue for open-source project, including this file? May be helpful
| import { beginCell } from '@ton/core'; | ||
|
|
||
| // Build signed data (example: wallet message) | ||
| const seqno = 5; |
There was a problem hiding this comment.
add description how to get seqno, or just get it in code
|
|
||
| 1. User signs a message off-chain (includes replay protection data and transfer details) | ||
| 1. User sends external message to blockchain | ||
| 1. Wallet contract verifies the signature |
There was a problem hiding this comment.
it's not about check signing, idk do we really need it here
|
|
||
| **Gas analysis:** | ||
|
|
||
| After loading the signature, the remaining data is a **slice**. To verify the signature, the contract needs to hash this slice. In TVM, the method for hashing a slice is `slice_hash()`, which costs 526 gas. |
3 participants
Closes #49