SN-10215 附来源、原文与上下文。
你好，中本聪：
Hello Satoshi,
希望你一切都好。最近我一直在想，比特币怎样能帮助应对互联网滥用行为，很想听听你的看法。
I hope this mail finds you well. Recently I've been thinking about how BitCoin can help handle internet abuse and would appreciate your thoughts.
我的‘本职工作’是在 Google 的反滥用团队。我们大量使用电话验证，来控制从我们网络发出的垃圾信息。Facebook 和 Craigslist 也这么做。电话验证效果不错，因为大多数人至少能使用一两个电话号码，却很少能使用更多。不过，它也有明显的缺点：对我们来说成本高、不稳定，有些人不喜欢它对隐私的影响，而且有些垃圾信息的利润足够高，值得购买大量 SIM 卡。
My "day job" is on the Google abuse team. We make extensive use of phone verification to control outbound spam from our network. Facebook and Craigslist do the same. Phone verification works well because phone numbers are something most people have access to at least one or two of, but rarely more. Yet it has significant downsides - it's expensive (for us), flaky, some people don't like the privacy implications, and some spam is profitable enough that buying lots of SIM cards is worth it.
如果能用比特币为一个账户提供抵押，就很理想了。抵押的数量可以帮助系统决定对你的行为设定什么限制，例如能发送多少邮件，同时保持匿名和隐私。但该怎样实现呢？
It would be ideal if BitCoins could be put up as collateral against an account. The amount put up would help determine the limits the system placed on your behavior (eg how much mail you can send), in an anonymous and private way. But how to implement this?
永久销毁币很容易，只要把唯一的输出设为 <pubkey> OP_FALSE。这样，你就可以用那个密钥签署服务器提供的某个质询，证明你确实销毁了那些币。一个密钥只能用于一个账户，因此垃圾信息发送者不能简单地提供巨额抵押，再转卖用这个密钥生成的签名。如果发现账户被用于滥用行为，就像现在一样封禁它，那些币也就‘没了’。
Burning coins forever is easy, just set the only output to be <pubkey> OP_FALSE. Now you can sign some server-provided challenge with that key and prove you did indeed burn those coins. A key would only be usable with one account so spammers cannot simply put up a huge collateral and then resell signatures generated with that key. If the account was found to be abused it'd be terminated like today, and the coins would be "gone".
不过，人们确实会加入或离开这些大型网络。要是退出 Google、自己运行邮件服务就会失去那些币，这个想法就不那么吸引人了。如果币能被锁定一段时间，在时间 X 之前无法花费，而币的所有者想延后时又可以不断把 X 往后推，否则这些币最终就恢复可花费状态，那会很理想。要验证你的 Google 账户，你可以拿出一定数量的币（比如 10 枚），设置成 6 个月内无法花费。
But people do come and go from these big networks and the thought of losing the coins if you quit Google to run your own mail is unappealing. It would be ideal if coins could be locked up for a period of time such that they cannot be spent until time X, where X can be constantly pushed into the future if the owner desires it but otherwise the coins eventually become spendable again. To verify your Google account, you would take some amount of coins (say 10) and set it up so you cannot spend them for 6 months.
脚本语言里没有时间的概念。OP_BLOCKNUMBER 被排除了，因为重组有可能让整条交易链失效。但 OP_DAY 可行吗？我在想一种操作码，它返回区块头中的时间戳，不过会四舍五入到最近的一天，以处理区块链里自然存在的时钟偏差。
The script language has no concept of time. OP_BLOCKNUMBER was ruled out because re-orgs could potentially invalidate entire chains of transactions. But is an OP_DAY feasible? I'm thinking of an opcode that returns the timestamp from the block header, but rounded to the nearest day to handle the natural clock drift seen in the block chain.
如果这能行，就很容易构造一笔交易，把币锁定到某一天之后。要更新交易，让到期时间不断后移，就比较困难。一种简单直接的办法，是要求用户提供 2 倍的币，在第一笔交易即将到期、恢复可花费时，创建第二笔交易。这样总有至少一笔到期时间足够远的交易可以充当抵押。不过，这不太优雅。更好的办法，是引入一条新规则，允许一笔交易在期限到来之前连接到这样的输出，只要这笔交易的输出仍然是同样形式、带有期限的输出。不过，它的通用性又不如脚本语言，所以也有些不够优雅。
If it could work then a TX that ties up coins until past a certain day is easy to construct. Updating it so the deadline is constantly moving is harder. A simple brute force solution is to require the user to put up 2x the coins such that at the point the first tx is about to expire and become spendable again, the second tx is created. In this way you always have at least one tx of sufficiently distant deadline to act as collateral. But this is inelegant. A better way would be to introduce a new rule allowing a tx to connect to such an output before the deadline has passed, as long as the output of that tx is once again a deadlined output of the same form. However this is less general than the scripting language so is also somewhat inelegant.
你怎么看？
What do you think?
如果脚本语言不是无状态的，如果它可以访问任何会变化、或在不同节点之间有所不同的外部信息，攻击者就可以利用它让链分叉。唯一的例外是：它在某个时间之前始终为假，在那之后永久为真；这一点通过 nLockTime 实现。
If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime.
既然 Google 是受信任的，用户不能向 Google 支付一笔象征性的押金，然后在关闭账户时，由 Google 把钱退还给他们吗？
Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?
不过，回答你的问题：是的，可以不依靠信任来做到：
To answer your question though, yes it can be done without using trust:
用户发出的 Tx 1 付款到一个脚本，花费它需要 Google 和用户双方的签名。
Tx 1 from User pays to a script that requires the signature of both Google and User to spend.
Tx 2（合约）花费 Tx 1，把钱支付给用户。nLockTime 是释放资金的时间。
Tx 2 (the contract) spends Tx 1 and pays it to User. nLockTime is the time to release the money.
步骤：
Steps:
按照这些步骤，用户在广播 Tx 1 之前，手中就已经有了 Google 签署的那一半 Tx 2，因此可以确定，自己签名付出资金时，同意的是什么条件。
With these steps, the user already has Google's signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to.
这是安全签署合约的一般模式。先准备 Tx 2，让各方知道自己把钱投入的是什么。广播 Tx 1，以锁定资金，并将其指定给 Tx 2。换句话说，各方把自己的钱放入一个由全体一致同意控制的资金池；但在此之前，大家已经签署了对资金默认处理方式的协议，或者已经为多个可选方案作了部分签名，其中一方只需加上最后一个签名就能完成。
This is the general pattern for safely signing contracts. Tx 2 is prepared first so the parties know what they're paying into. Tx 1 is broadcast to lock up the money and assign it to Tx 2. In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature.
只要相互同意，各方始终可以编写另一个版本的 Tx 2，立即释放资金。
By mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately.
