docs: add Profanity/Split-Key safety narrative to README

README.md

@@ -13,6 +13,14 @@
 
 > **RTX 5090 measured performance:** **5.20–5.26 GH/s** effective address checks, **3.45 GH/s** raw point generation, and approximately **5.1 GiB** working GPU memory with the production configuration.
 
+## Why another vanity engine
+
+Archived Profanity (`johguse/profanity`) seeded its generator from a 32-bit RNG value ([CVE-2022-40769](https://nvd.nist.gov/vuln/detail/CVE-2022-40769)). After that disclosure in September 2022, Wintermute lost about $160 million when an administrative vanity EOA created with the tool was recovered. About $3.3 million was also drained from other Profanity-generated EOAs.
+
+1inch Profanity2 replaced that design with Split-Key: the GPU searches from a public secp256k1 point, returns an additive share, and the final private key is combined offline. Vaddro uses the same safety model, implemented as native CUDA/PTX rather than OpenCL, with multi-worker sharding and a verification chain. The seed private scalar is never copied to a GPU worker.
+
+Do not use archived Profanity. Do not send a private key to any worker or vanity seller. A Vaddro worker only needs the 128-hex public point. The project coffee address `0x00000000000003eb5045a0868cdb96a9926e2328` is a 13-leading-zero-nibble proof of work (thirteen `0` hex digits after `0x`, then `3eb…`).
+
 ## Why Vaddro
 
 | Capability | Implementation | Practical benefit |
@@ -271,7 +279,7 @@ General contact: yishan ([linyishan@gmail.com](mailto:linyishan@gmail.com)). For
 
 ## Buy me a coffee
 
-If Vaddro is useful to you, you can support its continued development through this EVM address:
+If Vaddro is useful to you, you can support its continued development through this EVM address. It has **13** leading hex zero nibbles after `0x` (`0000000000000` then `3eb…`):
 
 ~~~text
 0x00000000000003eb5045a0868cdb96a9926e2328

README_CN.md

@@ -9,10 +9,18 @@
 
 [English](README.md) · [简体中文](README_CN.md)
 
-**Vaddro（Vanity Address Online）**使用原生 CUDA/PTX 搜索定制 EVM 地址。它采用 Split-Key 工作流：Seed 私有标量始终留在离线端，联网 GPU Worker 基于对应的 secp256k1 公钥点搜索并返回经过验证的加法 Search Share，最终私钥只在离线环境中合并和校验。
+**Vaddro（Vanity Address Online）**使用原生 CUDA/PTX 搜索 EVM 靓号。它采用 Split-Key 工作流：Seed 私有标量始终留在离线端，联网 GPU Worker 基于对应的 secp256k1 公钥点搜索并返回经过验证的加法 Search Share，最终私钥只在离线环境中合并和校验。
 
 > **RTX 5090 实测性能：5.20–5.26 GH/s** 六变体有效地址检查、**3.45 GH/s** 原始点生成，生产参数下工作显存约 **5.1 GiB**。
 
+## 为什么还要做一个靓号引擎
+
+归档版 Profanity（`johguse/profanity`）用 32 位 RNG 种子生成私钥（[CVE-2022-40769](https://nvd.nist.gov/vuln/detail/CVE-2022-40769)）。该缺陷于 2022 年 9 月披露后，Wintermute 的一个由该工具生成的管理员靓号 EOA 被恢复，损失约 1.6 亿美元；另有约 330 万美元从其他 Profanity 生成的 EOA 被转走。
+
+1inch 的 Profanity2 用 Split-Key 替换了这一设计：GPU 从公开的 secp256k1 点搜索，返回加法 Share，最终私钥在离线端合并。Vaddro 采用同一安全模型，以原生 CUDA/PTX（而非 OpenCL）实现，并加入多 Worker 分片和验证链。Seed 私有标量不会被复制到 GPU Worker。
+
+不要使用归档版 Profanity。不要把私钥交给任何 Worker 或靓号代工。Vaddro Worker 只需要 128 位十六进制公钥点。项目咖啡地址 `0x00000000000003eb5045a0868cdb96a9926e2328` 是 13 个前导十六进制零的工作量证明（`0x` 之后为 `0000000000000`，然后是 `3eb…`）。
+
 ## 为什么选择 Vaddro
 
 | 能力 | 实现 | 实际价值 |
@@ -271,7 +279,7 @@ python3 combine.py \
 
 ## Buy me a coffee
 
-如果 Vaddro 对你有帮助，可以通过以下 EVM 地址支持项目持续开发：
+如果 Vaddro 对你有帮助，可以通过以下 EVM 地址支持项目持续开发。该地址在 `0x` 之后有 **13** 个前导十六进制零（`0000000000000` 然后是 `3eb…`）：
 
 ~~~text
 0x00000000000003eb5045a0868cdb96a9926e2328

SECURITY.md

@@ -24,7 +24,7 @@ combine.py
   -> final private key and independently verified EVM address
 ~~~
 
-Under the secp256k1 Elliptic Curve Discrete Logarithm assumption, the worker cannot recover the Seed private scalar from its public point. Split-Key does not protect a compromised offline machine, a leaked Seed or wallet, a malicious build, or an implementation flaw.
+Under the secp256k1 Elliptic Curve Discrete Logarithm assumption, the worker cannot recover the Seed private scalar from its public point. Split-Key does not protect a compromised offline machine, a leaked Seed or wallet, a malicious build, or an implementation flaw. This is the same Split-Key model that replaced archived Profanity after CVE-2022-40769 (32-bit RNG seed).
 
 CUDA startup self-tests, runtime canaries, host-side hit reconstruction, and `verify_result.py` detect computational errors. They do not replace release verification or independent offline validation.
 

SECURITY_CN.md

@@ -24,7 +24,7 @@ combine.py
   -> 最终私钥与独立验证的 EVM 地址
 ~~~
 
-在 secp256k1 椭圆曲线离散对数安全假设成立时，Worker 无法从公钥点恢复 Seed 私有标量。Split-Key 不能保护已被入侵的离线机、泄露的 Seed 或钱包、恶意构建以及实现缺陷。
+在 secp256k1 椭圆曲线离散对数安全假设成立时，Worker 无法从公钥点恢复 Seed 私有标量。Split-Key 不能保护已被入侵的离线机、泄露的 Seed 或钱包、恶意构建以及实现缺陷。该模型与 CVE-2022-40769（归档版 Profanity 的 32 位 RNG 种子）披露后用于替代该工具的 Split-Key 方案同类。
 
 CUDA 启动自检、运行时 canary、Host 命中重建和 `verify_result.py` 用于发现计算错误，但不能替代发布包校验和离线独立验证。