Skip to content

回复:新手测试——有人想花 1 美元买一张图片吗? ​

原始发布页

打开来源页面
查看 1 个交叉存档

订单付款的建议方式:

  1. 商家拥有静态 IP,客户向该 IP 发送,并附带评论。
  2. 商家创建一个新的比特币地址,将其交给客户,客户向该地址发送。这将是网站软件的标准做法。

RSA 与 ECDSA:问题不在于可执行文件的大小,而在于数据的大小。我认为,如果区块链、比特币地址、磁盘空间和带宽需求都增大一个数量级,那将不切实际。此外,即使消息使用 RSA,用 ECDSA 完成整个比特币网络、仅为消息部分并行使用 RSA,仍然是合理的。在这种情况下,迄今实现的所有内容都将完全照旧实现。

我们可以晚得多再确定最佳做法。它可以使用独立的(也许是现有的)电子邮件或即时消息基础设施来传递消息;并且,与其使用 RSA,也许只需把消息的哈希放进交易中,以证明这笔交易对应消息中描述的订单。消息必须包含盐值,这样没人能通过暴力破解哈希来揭示短消息。

英文原文 ​

展开英文原文

The recommended ways to do a payment for an order:

  1. The merchant has a static IP, the customer sends to it with a comment.
  2. The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.

RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.

We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.

为历史保存,为中文读者整理。每篇档案均附来源与英文原文。