托管钱包和非托管钱包是两个东西。okx 钱包本质是 web3 产品

贴一个无常损失计算：
https://www.btcfans.com/zh-cn/tools/impermanent_loss

token 是去中心化的 要做你直接上就行

把币给到合约 然后就能治理了

先谢老板

昨天发了邮件，是 daer 开头的 outlook 邮箱。至今还没收到回信。希望能确认一下

naive ui 最喜欢的是文档 读着很有趣 用例也详实

顺便也问问。我之前是一直用 conda ，没遇到啥问题。前端时间想试试切换到 poetry ，结果发现 poetry 把 conda 的环境配置给拦截了。不知道有没有朋友解决过类似的问题。有没有办法让 conda 和 poetry 一起用

我现在静态页面基本全上 vercel 了，不要太好用

传统的密码（或者说口令，password ）不够安全的原因在于通常来讲口令的熵是不足的（也就是不够长），采用暴力搜索的方式总能破解，因此常常会选择类似 scrypt 或者 pbkdf2 这些算法来给暴力搜索加上一个非常大的常数倍数因子，来增加穷举的难度。

而现代密码学工具的可靠性来源密钥的保密性。按照目前的习惯，破解的量级在 2^128 这个级别是认为是安全的。而符合助记词约定的最短的助记词也足够了。

看了白皮书感觉没有特别特殊的，当你有了一个熵足够高的密钥之后一切都很没啥了，就是端到端加密那套

openai translator

之前一直用
https://github.com/Yidadaa/ChatGPT-Next-Web

检索具体是在干什么？半小时才 3 万字我怀疑算法本身有很多优化空间

插眼，和楼主的预算和需求比较接近

@Daiwf 是的。这也和我所接触到的情况一致。

SM2 的问题。SM2 就只是换了个曲线参数？基本正确。但曲线参数是可能安插后门的。NIST 提供了一些曲线，但并没有全部给出选择的依据。当然 SM2 与 NIST 提供的其他曲线参数目前都是国际认可的标准，这也意味着目前没人能找到这些参数的后门，后门是否存在是一个无法证明也无法证伪的问题。
这就涉及到一个信任问题：你的项目是信任 NIST 制定的曲线参数，或是国内制定的曲线参数呢？就国内企业的视角而言（只讨论安全性），这个问题应该是偏向 SM2 的。至少从国家层面选出新参数是必要的。（题外话，如果二者都不相信可以试着选择 edwards25519 ，很多区块链项目选择的就是这条曲线。https://en.wikipedia.org/wiki/Curve25519 ）

GM 的强制使用问题。首先等保三级以上单位是必须要使用国密的。此外目前密码法正在做这件事：“法律、行政法规和国家有关规定要求使用商用密码进行保护的关键信息基础设施，其运营者应当使用商用密码进行保护，自行或者委托商用密码检测机构开展商用密码应用安全性评估”。具体会如何实施就无从知晓了。

目前国密的生态确实很糟糕，使用国密的成本比使用其他算法的成本高出太多。像国内比较知名的 GmSSL 项目，我之前在配置时也是感觉很痛苦。这个问卷一定程度上也是想直接地询问实际的项目开发者的想法

VDF

睡眠唤不醒我之前也经常遇到。现在的解决办法是禁止自动睡眠，只启用休眠，体验好不少。
只允许休眠的情况下唤醒是没问题的，但睡眠有时候会有睡死的问题

另外服务器相关的方案不太清楚开销是否能承受（项目要跑大量应用），直觉上讲优先级可能比较低