原文 medium.com/swlh/taking…
回到2009年，比特币允许 IP 到 IP 的信息交换。在2009年钱包还停留在原型阶段，而且由于开发者们没能理解比特币，它的很多最好的功能都被关闭了。
上周，我就比特币如何应用在智能卡上进行了讨论，带防火墙的id模型能够保护隐私。这周，我将展示如何使用web服务器安全地接受比特币支付，以及如何在进行法币或者其它token交易的同时保证隐私。

这是比特币的点对点的部分，不是挖矿，这也是Core开发者们移除的东西之一。

2009年，系统还没完成。一些可能的功能需要测试，2009年的客户端留下了很多悬念，只能算是一个原型。
要解决这些问题，首先我们要清楚一点：节点和钱包是分开的。节点是矿工，而钱包是用户使用的，而且具有 P2P 交易功能。在本文中，我会解释：基于ECDSA的网络证书，SSL/TLS服务器证书，这些让你安全地上网冲浪的东西，能够成为一个商业支付系统的基础——这个系统能保证安全和隐私，这也是建立在单个地址只被支付一次的基础上。
换句话说，不重钥。
转账有两种方式。收款人在线的话，输入他的 IP 就能连上，获取一个新的公钥，然后发送交易。收款人不在线的话，可以发送到他的比特币地址，那是他的公钥的哈希，事先给到你。在下次连接上，并得到交易所在的区块的时候，他就可以收到。缺点就是没有发送备注信息，而且由于地址重用，隐私性会受损。但对于无法同时在线，或者是接收者没有网络连接的情况，这还是一个有用的替代方案。
证书是可以在 S/MIME 和 HTTPS 中使用的东西。
如果我们使用和CA注册证书相关联的密钥，就不能在保留隐私的同时创建商人收款的公共记录。
举个例子，Alice 是一个消费者，Bob是一个网络商人，他的网站 HTTS://www.bob.com 是有ECDSA证书的。
Alice 有 Bob 的 主密钥。密钥不是用于收发比特币的，它可以用来创建一个身份密钥（可以用在智能卡上）。这样的密钥我们称为P(Alice)。
Bob的网站的主密钥是 P(Bob)。（使用 S-MIME 可以很简单地将这套机制用在 email 上，留给大家思考）。
Alice 有一些 coin（UTXO索引），它们和 P(Alice) 毫无关系，也就是 P(Alice) 和她的基础密钥没有任何联系。我们称其为 P(A-1-i)，i 代表所用过的 coin。
Alice 可以使用下面这个文档里描述的流程来创建一个通用密码（s1)：
DETERMINING A COMMON SECRET FOR THE SECURE EXCHANGE OF INFORMATION AND HIERARCHICAL, DETERMINISTIC CRYPTOGRAPHIC KEYS
这套机制的其中一种用例：Alice在Bob的网上商店进行支付。双方可以计算出一个共用密码。为了更安全，Alice可以使用她们共享的 web-session ID，发票号码，或者任何别的东西。可以使用于一个基于 HMAC 的值来获得更多的安全和隐私，但为了便于理解，在这里我会使用简单的哈希。
Alice和Bob都可以计算出S的值，它和双方在网上使用的密钥有关。Alice有一个用于身份认证的密钥，这与她的支付没有公开的联系，但能够保证与Bob通信的安全。
Alice通过一笔比特币交易发送一个加密的信息。这个交易完全可以用于离线或在线的情况。如果Bob在线，他可以保留来自Alice的 nonce 作为网络检查的一部分。
如果Bob不在线，而且他的网站很简单，那么他可以使用区块链来记录支付信息并检查它。
Alice发送给一笔交易到 P(Bob)。这个地址Bob不会去使用，所以这个支付是小额的；如果没有粉尘限制，只发一聪也是可以的。Alice只是发送了关于支付的信息给 P(Bob)地址，Bob不会动用里面的资金。可以这样说，只有当证书被标记为过期的时候，Bob才会花费这个地址（与P(Bob)公钥相关联）里的钱。这个流程类似于分布式的 “revocation list”，Bob掌控他自己的密钥。而且，如果Bob的密钥和证书被攻击了，粉尘交易被黑客给花费了，这就是一个自动的警报。Bob可以在这个账户里放一些钱，好让黑客认为这是一个使用中的合法地址（例如2000美元），如果这个账户被黑了，那么它就会警告Bob的用户们。
Bob可以使用一个 subkey 来让账户更加隐私——请看专利中的这幅图：
Bob甚至可以有一个流程，让发票号码和某个 subkey 相关。
Alice向一个和 P(Bob) 相关联的地址发送信息——在脚本里，或者是OP_RETURN里附加一个加密后的值（使用例如AES的加密算法）。使用之前的方法，Bob可以计算出S。发送给Bob的一聪（加上手续费）交易里，包含了让Bob知道Alice从哪里发起支付所需的所有信息。Bob使用对称密码（S）来解密消息中的数据：
- Encrypt(S)[M]
M是 Alice 要给到 Bob 的信息。
- Decrypt(S)[M]
Bob现在可以从密钥中派生出一个密钥地址：
— P(Bob-Paid) = P(Bob) + HMAC(M ~S)xG
— 消息密码是 P(Shard Message) = HMAC(M ~S)xG
新密码 HMAC(M ~S) 只有Bob和Alice知道。
Alice可以证明她已经支付给了Bob。Bob可以找到Alice发送的钱，并且验证交易。
同时，没有任何第三方可以确定Alice用于支付的地址——P(A-1-i)到Bob的P(Bob-Paid)。
Bob在区块链上有着 P(Bob) 的记录，以及它收到的所有支付地址的完整账目。这些记录可以联系到发票，订单等等，让Bob能够构造一个无人可删除，增添，或操控的，完整的关于所有交易的账目，这个方法满足了Bob在法律上所需的所有审计问题，而且他还可以有一个分离地址，用于向政府发送 VAT 和其它消费税。换句话说，Bob不需要经历昂贵的审计，就可以立刻交税。
Token 和 比特币
使用例如 Tokenized 或者 nChain专利中的任意一种协议，Alice 和 Bob 可以交易 token化的法币。这意味着Alice在英国可以使用由某个银行发行的 GBP token 来支付 Bob。这种token可以使用上面的流程被发送，使得 Alice 和 Bob 可以安全地以他们本地货币的形式发送数字货币，同时以比特币作为交易的“管道”。
Metanet 链接
即使Bob运行的是一个离线网站——没有后端数据库——密钥P(Bob)所收到的记录也可以作为一种不可变的数据存储。
Alice 加密发送给 Bob 的消息，可以是完整的订单。
这可以使用现有的 EDI 消息类型来完成。而且比 EDI 更安全，可靠，私密。
更好的是，记录是不可变的。没有审计欺诈的空间。你可以撤销交易，但是需要把资金发回其来源。
Bob 可以持有一系列的分级地址，它们记录了订单的每个环节——从账单和支付到送货和收货。如果 Bob 拥有每位客户的 sub-master key（见上文 Fig.9 的专利），他也可以构造另外一个 subkey，只有他自己，客户以及审计税收的机构会知道，这使得他能保持完全的隐私，别的客户和供应商不会知道他到底做了多少交易。除此之外，他还可以通过构造支付流程，来分隔内部员工，让他们只知道和自己部门相关的信息。
只要CA相关的key没有被动过，账目就可以被发送到旧的地址。一个 sub-CA key 可以和账目年份相关联，并在每个纳税周期被调用。你可以关闭这个证书，收集所有粉尘支付，同时，合上书本准备迎接新一年的账目。
EDI 是一种现有的商业编码格式。
下图是 ASNI 和 EDIFACT 消息的格式：
在我们的系统中，我们使用密钥以“群消息”的形式为消息中的数据进行加密。不再需要一个“交换信息”。在比特币里，我们消除了对中间人的需要。
新的商业模式是所有的记录都不可变，不会丢失，而且允许 Alice 和 Bob 进行私密交易。
而且，使用比特币交易的 EDI 工具就像现有的 EDI 工具一样简单。
即使是嵌入在比特币交易内，加密的EDI XML格式仍然可以被简单地解析并显示或者是打印在发票或订单上：
在现有的EDI世界中，客户是根据字符或者文档的数量来付费的。而且有许多供应商设置了最低收费长度，从128到512个字符。结果就是如果你发送了12个有12字符的文档，你将被按照最高5120字节来收费，即使只发送了144个字符。
对于有着大量小额交易的商家，这会造成大量的支出。
这些在比特币里不是问题。
尽管 NACCS EDI 规定的最大消息体积是 500,000 bytes，实际上这个EDI和其它相关的消息通常是 150 bytes。
只需要几分之一美分就能够发送一笔不可变的，私密的，可靠的发票，附带账目系统；相比花费2到3美元在某些EDI方案上，或者是 0.20美元发送一笔简单的 Visa 交易… 是时候重新思考你的商业活动了。
在这个模型里，没有比特币的地址会被多次使用，支付和发票是被私密地链接在一起——如果 ID 不需要放在用户的证书内，甚至可以使用假名。