本文的主题是隐身地址技术，最近因为暗黑钱包使用了这项技术而再次被提及。

我本来不打算用bitcoinj开发这个函数。不过，如果有人给bitcoinj的隐形地址写个补丁，我不介意加进去。

我想说的是：隐形地址技术的设计有问题。除此之外，我认为还有更好的方法可以达到同样的效果。

什么是隐形地址？

隐身地址解决隐私问题。

如果使用静态比特币地址收款，虽然省事，但可能会泄露你的隐私。因为寄件人可以在区块链找到这个地址的所有收款记录。

一个简单的解决办法就是用BIP32 HD？Wallet(分层确定性wallet):服务器不断用您自己选择的数据种子生成新地址。因为种子隐藏在服务器中，所以这些地址之间的关系是孤立的。但是这种方法有很多不便：

你得找一个有BIP32功能的服务器。只要你的数据种子泄露了，所有地址之间的关系就泄露了。更大的问题是和BIP70(支付协议)的签名方式冲突。如果你想用地址签名，你需要服务器获得你的签名权，这就降低了安全性。

为什么不直接将数据种子发送给发送方，让对方生成地址？因为收款人需要得到付款通知，这意味着收款人必须枚举所有可能的地址。如果收款人可以列举所有地址，那么寄件人也可以，这样对方还是可以得到你所有的收入信息。

所以，我们需要一个方法，让发送方可以在不知道私钥的情况下生成公钥，你可以计算出对应的私钥。同时，所有的交易不能有关联。这就是隐形地址的作用。

工作原理

Peter Todd的这篇文章详细解释了隐形地址的机制。当然，我们还需要提到，使用椭圆曲线Diffie-Hellman的想法是ByteCoin在2011年提出的。基本原理是发送方选择一个大的随机数。这个数通过一系列公式(公式中包含数据种子)计算得到一个新的公钥，其对应的私钥只能由收款方计算，与原始数据种子无关。

这一点看起来不错。不幸的是，这个方案的问题要追溯到秘密地址的初衷。先不说这个名字，只讨论问题的关键点——。如果我们要提取收到的钱，收款人需要一个大数据种子。这个种子可以公开，不会造成隐私泄露。目前，隐形地址的方案是将其添加到每一个有新输出的事务中。

第一个问题：隐形地址会拉伸区块链。第二个问题：隐形地址的交易看起来和其他交易不一样。

此标记交易发出后，收款人需要先找到它。通常，钱包通过扫描它生成的地址来收款。但在这种情况下，地址是全新的，标签是一个随机数。所以，如果你想找到寄到你隐形地址的钱，你需要尝试所有地址，看看是否有匹配的。这种模式很糟糕。目前有一些针对性的改进，但是这些改进涉及到P2P协议的修改，社区很难接受。一些修改是通过简单地对收款地址进行切片来实现的：收款人只检测收款地址的一部分。通过暴力计算，寄件人在这些地址中留下了自己的地址。

第三个问题：隐形地址与手机不匹配

当然，我说的“手机”是指任何使用CPU和电的设备。

隐身地址的问题其实是我们一直在努力摆脱的困境。该地址不能扩展，因为它不是向后兼容的。没有隐形地址功能的钱包软件会直接拒绝这些交易。好吧，是隐私重要，还是支付成功？我觉得现实中后者更重要。

第四个问题：隐形地址不向后兼容

最后，还是继承了按地址收付费的问题：

第五个问题：你不知道是谁付费给你的，为什么。

幸运的是，我们有更好的方案来解决上述问题。我打算长期遵循这个计划。

---

ECDH支付协议

我经常讲[bip 70](https://github . com/bit coin/bips/blob/master/bip-0070 . mediawiki)，因为它解决了很多问题。而且，它还可以在隐形地址领域发挥作用。

BIP 70支付请求消息包含输出列表(就像地址列表一样)。我们可以这样扩展输出：

message output {可选uint 64 amount=1[默认=0]；可选字节script=2；可选布尔accept _ ecdh=3；}

我们在第三个域中标记它：接受椭圆曲线Diffie-Hellman (ECDH)事务。老钱包不知道这个域，会直接忽略。忽略后，将与传统的公钥支付相同。虽然这种方式没有隐私保护，但是还是可以收钱的。如果你需要隐私，又反正不要钱，可以在协议中加入强制不兼容。

然后，我们在支付消息中添加一个新的重复ecdh_nonce字段。每个nonce字段(大随机数)匹配事务中的输出：

消息支付{可选字节merchant _ data=1；重复字节事务=2；重复输出退款_ to=3；可选字符串memo=4；重复字节ecdh _ nonces=5；}

升级后的wallet将不使用输出，直接使用新的派生密钥。

如果这个支付协议得到支持，前面提到的所有问题都会一下子解决。此外，在您被允许加入消息后，nonce与区块链隔离，您可以将交易直接发送给收款人。这样既避免了扫描区块链的资源浪费，又不需要对P2P协议进行很大的改进。

当然也带来了一个新的问题。

---

让人与人之间的交易变得可行

大多数人可能不知道，中本聪自己也认为支付协议非常重要，他已经写在比特币0.1(比特币的最早版本)中了。通过填写收款人的IP地址来实现。实际上，比特币地址只是一个备份计划，以便您在不在线时可以收钱。

这个支付协议没有存活下来的原因之一是早期没有商家接受比特币，所以交易都是人对人的，很难保证对方永远在线。而且，用IP地址汇款是个馊主意。但是，支付协议的想法本身是非常合理的。

BIP 70对商人很友好。然而，由于许多功蓑衣网小编2022能要么依赖于BIP 70，要么要求商家始终在线，我们需要首先解决数据传输的问题。使用区块链存储临时数据时，要考虑其成本高、效率低的问题。——已经有人开始抱怨传输区块链占用的带宽，往里面塞完全不影响一致性的数据是愚蠢的。当然，如果区块链是交换数据的唯一途径，这可能是值得的，但事实并非如此。

除了区块链，我们还需要建立另一个基础设施：一个简单的存储转发网络。秘密地址的最初提议使用Bitmessage来实现这一点。但是Bitmessage有一些设计上的问题，不适合这个。那么这个存储转发服务器需要做什么呢？

接收PaymentRequest信息，并在服务器上加载特定的URL以使HTTP(S)可访问。使用此URL接受来自钱包的支付过帐请求并存储它。将此消息返回创建付款申请URL的钱包，然后删除此消息。

听起来像电子邮件系统或即时消息系统，但它就是这样一个系统。不可见地址的原始提案指出：与比特币网络隔离的额外网络不能用作存储转发服务器，因为它降低了整个系统的可靠性。但事实上，人们每天都在依赖大量这样的服务，就像依赖比特币网络一样。如果我们滥用比特币节点作为存储转发服务，就会导致疯狂的资源消耗。 我认为我们可以用更好的工具来完成这项任务。

这样的系统应该是什么样子的？这有点像电子邮件，人们明确地选择一个由服务器和他们的钱包创建的帐户，或者轮询新的支付，或者挂起一个GET response服务。这个“账号”通过特定的URL接受钱包的“POST”请求，然后输入用户名和密码后提取一个GET。一旦支付消息被下载，钱包负责广播交易，然后将消息发送给用户。人们只需要选择有在线能力的服务，而不需要更多的信任。由于另一个BIP70扩展，消息可以被加密，这样服务器就无法获取信息内容(ECDH再次被使用)。

你亲自调查哪个服务器7*24小时维护不太现实。你可以让电脑来做这个。我们将这些服务器连接到一个类似Tor的P2P网络。Tor网络更加集中蓑衣网小编2022化：它牺牲了一些去中心化的特性，使其工作更加高效。Tor网络通过一个“带宽调度中心”评估某个节点的在线时间和在线能力，需要提供一个可信的节点能力评估值。钱包也可以运行类似的评估服务器来通知每个钱包哪个服务器更可靠。通过这种方式，钱包可以通过提供匿名账户来租用其BIP 70支付链接。

如果浏览器可以直接解析随机的网址，显示一个简单的网页，网页会显示一个比特币地址二维码和一个“支付”按钮，就像Bitpay和比特币基地已经提供的功能一样。这样更方便。

从长远来看，钱包联合品牌可以向存储节点提出请求，对其进行评估并自行编写研究报告，无需依赖第三方的监督。当然这样会消耗电池，但是晚上充电的时候可以。然后，如果你的钱包可以连接到你朋友的钱包，你就可以分享这个报告。这就变成了一个完全去中心化的网络，节点之间相互信任。

一旦实现以上功能，就可以定义更多的BIP70扩展，比如在支付请求中添加姓名、昵称、照片、联系方式等，会非常有用。人们可以将他们的钱包通讯录以文件的形式上传到社区维护的黄页服务器上，这样在进行支付时，看起来就像对方在线一样。当然，这种方式不需要ECDH和隐形地址，因为钱包每次收款后总是可以上传一个新的收款码，但它简化了很多事情，避免了钱包不在线时可能出现的重复支付。

我刚才说的整个基础架构可以分为不同的层次，成熟的程序员可以一步步实现。如果你对这个实验项目感兴趣，请联系我：mike@plan99.net

名词定义：

BIP:比特币改进提案的简称，意为“比特币改进建议”。www.8btc.com/-32:分级确定性钱包参考：https://github . com/bit coin/bips/Blob/master/bip-0032 . mediawiki 3358 -- Wallets-Advantages-flaw http://SourceForge . net/p/bit coin/蓑衣网小编2022mailman/message/31813471/BIP-70:支付协议参考：https://github.com/bitcoin/bips/Blob/master/bip-0070 . mediawiki

-

原文：https://medium.com/@octskyward/ECDH-IN-THE-Payment-Protocol-cb2f