56 关于只使用哈希记录的另一种区块链
本章讨论了一个中本聪认为有趣的建议。该建议建立在给区块链提供更少的信息，目的是提供更高程度的隐私。
并非建议
Reb发表，2010年8月10日，上午05:45:45
一些人可能已经注意到了，比特币让我困扰的一件事就是整个交易的历史是完全公开的。我完全理解这种简化所带来的巨大好处，而且可以让每个人都能轻易证明比特币的有效性。
所以这篇文章不是为改变比特币而提出的建议。而是关于什么可行、什么不可行而提出的问题。
总的问题是区块列表是否可以/已经以一种不在表中存储完整交易的方式实现？具体来说，“也许”有可能在区块列表中仅存储输入、输出项的哈希。这些项在区块列表中像现在这样加盖时间戳（公证）。
主要的区别在于存储完整交易是由比特币接收者来负责。也许他还得存储以前的X次交易以查询历史。
然后，当他想把比特币转给下一个人时，可以创建一个与现在完全一样的交易，只是需要额外提交该交易的前序交易以供验证。输入项的每条前序交易也要像区块列表中现存交易一样进行哈希和验证。将输入项哈希后在区块列表中标记为尚未使用。然后该交易会被验证为当前已完成。
如果所有验证都正确，新增的输入输出项的哈希值将被添加到区块中。交易的输入项就不能再使用了，并将新输出项的哈希值标记为未使用。
一旦节点完成了区块（指赢得了哈希竞赛），就会将区块中的哈希以及相关的交易和附加的前序交易广播到其他节点以进行确认和接纳。
这里有个粗略的例子：
{block-9
hash-a, hash-b, hash-c, hash-x
}
{block-12
hash-a, hash-y, hash-c, hash-d
}
{block-17
hash-b, hash-d, hash-e, hash-z, hash-f
}
{Transaction
{in-points: hash-x, hash-y, hash-z}
{address, signature and other transactions stuff}
{out-points: hash-payed, hash-change
}
{generating-block
hash-x, hash-y, hash-z, hash-payed, hash-change
}
因此，如果输入输出项的哈希值在区块列表中出现两次，那就是已经用过了 。如果只存在一次，那就还未用过。
所以在block-17之后：
a、b、c和d已用过。 e、f、x、y、z未用过。
该交易使用了x、y和z，而且创建了hash-payed和hash-change，因此交易是有 效的。
在generating-block后：
a、b、c、d、x、y和z已用过。
e、f、payed、change未用过。
目标：
目标是提供与现有系统完全相同的安全性，但是避免创建每笔交易的公开图谱，这样太容易找到交易之间的相互关系了。在这种情况下，甚至哈希都不必在区块中进行关联。区块中的所有哈希可以简单地按升序排列。
实际上，我想创造真正的金币。我可以把我的金币给您，但是没人知道。您可以把金币再给下一个人，并证明它们是纯金币，因为您有这些金币的谱系，并且谱系中每一代都在公共记录中公证过。
问题：
中本聪演示了通过默克尔树结构从区块列表中移除交易，而不会危及安全性 。我想我真正的问题是：
“最早什么时候可以移除这些交易？”
您可能会争辩说，无论如何节点都可以记住所有的交易（网络永远不会忘记）。但是如果您对协议进行结构化，让新节点只接收区块列表的哈希，它们就只能从这一刻开始记住。这（也许）会增加一些额外的隐私。
各位有什么看法吗？其中有没有明显的方法会导致欺诈和暴富？
回复：并非建议
Insti发表，2010年8月10日，上午09:34:14
在您的体系中，从区块链拿不到交易信息，我必须要监控每笔交易（反正我都能看到），并且记录到自己的秘密服务器。
您这是通过制造谜团加强安全啊。
回复：并非建议
Reb发表，2010年8月10日，下午02:09:36
引自：Insti，2010年8月10日，上午09:34:14
您这是通过制造谜团加强安全啊。
我已经提到过这点了。我并不指望让货币更安全。只希望该体系与现行体系并驾齐驱。
然而，众所周知，隐私谜团有价值。您的邻居或联邦调查局可能整天都在监视您的一举一动。但也可能没有。如果碰巧被“关注了”，那么他们肯定会开始盯着您，并且从那一刻开始。
但是体系最想要的额外法定权力似乎是：“让我检查每个人的记录！ ”（通话记录、通信塔、邮件往来、facebook连接、信用卡/借记卡交易、谷歌搜索历史、 浏览器访问历史等。）其他体系则是“通过权力获得安全”。比特币体系没有这个权力。
顺便提一下，我也不想把每笔交易都广播到每个节点。但这个话题不在这里讨论。
再提一下，大多数的数字公证服务就是这么做的。您发给公证员一份哈希签名的文档，由公证机构永久保存下来。然后他们创建一条与比特币相似的哈希链。定期在报纸或其他的线下刊物中公布当前的哈希链值。
您没有必要将私人文档/交易发送给公证员来加盖时间戳以及备案。公证员只是出具以下证明，即该时刻存在与此哈希值匹配的某物。
回复：并非建议
Insti发表，2010年8月10 日，下午03:06:16
引自：Reb，2010年8月10日，下午02:22:09
再提一下，大多数的数字公证服务就是这么做的。您发给公证员一份哈希签 名的文档，由公证机构永久保存下来。然后他们创建一条与比特币相似的哈希链 。定期在报纸或其他的线下刊物中公布当前的哈希链值。
您没有必要将私人文档/交易发送给公证员来加盖时间戳以及备案。公证员只是出具以下证明，即该时刻存在与此哈希值匹配的某物。
您也不必向公证员证明账户中有X枚比特币。
不过我最近在看零知识证明相关的资料（http://en.wikipedia.org/wiki/Zero-knowledge_proof)，如果您可以用这方面的技术证明账户中有X枚比特币，而不透露其他信息，这可能就是您要找的东西。
我只是担心您想做的在理论上不可行。
回复：并非建议
Reb发表，2010年8月10日，下午05:29:44
引自：Insti，2010年8月10日，下午03:06:16
不过我最近在看零知识证明相关的资料（http://en.wikipedia.org/wiki/Zero-knowledge_proof)
很有意思的提议，值得重新看下！谢谢。有一段时间没有考虑过这些了。
回复：并非建议
中本聪发表，2010年8月11日，上午12:14:22
这是一个非常有意思的话题。如果找到解决方案，可能会出现一个更好、更容易、更方便的比特币版本实现。
原本比特币可能只是一连串签名。有了时间戳服务，旧的签名在超过回溯需要时是可以抛弃的，或者单独保存比特币或只保存面值。对包含所有交易的全局知识的需要是为了检查双重消费的情况。
问题在于如何证明不存在另外一笔花销？似乎节点必须知道所有的交易才能 验证。如果节点只知道输入项和输出项的哈希值，就不能对签名进行检查，以了解是否存在之前用过的输出项。您对此有何看法？
在本方案中很难想出如何应用零知识证明。
我们试图证明某些事情不存在，似乎就需要知道全部信息，然后检查其中并不包含。
回复：并非建议
Reb发表，2010年8月11日，上午04:58:50
中本聪：我知道您了解我写的第一部分，但我希望别人也能看懂，并希望您能纠正我可能存在的误解。
我正在看当前默克尔树（Merkle tree）的实现，尝试找出何时可以删除交易而不丢失安全性。
在交易图的术语中，交易表示节点。交易图的边缘节点由交易的输入项表示 ，该输入项用区块哈希->交易哈希-> 输出项这样的结构指向前序交易。
因此，对于有效的交易，其中的每个输入项必须显示出既存在前序交易对应的输出项，又没有前序交易的输入项引用了该输出项。因此，对于每个输出项， 都由零或一个输入项引用。零个表示未使用，一个表示已用过。
这也意味着，除非两个输出项都已支付，否则该交易不能从区块列表中剔除 。否则比特币就会消失。
然而，只要您确信第二个交易所在的区块一直都在，就可以删除所有双向绑定的交易。（最早的删除可能性。）
然而，当删除交易并以树的哈希值取而代之时，区块列表中呈现出的交易图结构就丢失了。实际上，所有未从区块列表中删除的交易具有未使用的值，原因也就在于交易还没删除。但已不再能由前序交易证明自身的有效性，因为那部分图已从区块链中剔除。
这让我思考，如果根本不把完整的交易放到交易图中，是否可证明交易的有效性？
引自：中本聪，2010年8月11曰，上午12:14:22
问题在于如何证明不存在另外一笔花销？似乎节点必须知道所有的交易才能验证。如果节点只知道输入项和输出项的哈希值，就不能对签名进行检查，以了 解是否存在之前用过的输出项。您对此有何看法？
关键是将交易信息作为输出项哈希值的一部分。因此，用两个输出项的哈希值来表示一笔交易，就取代了单独创建的交易哈希值。（我最初考虑使用输入项/ 交易/输出项的哈希结构，但现在看来没有必要了。）
只有交易验证者需要知道记录在案的输出项哈希值关联到哪个比特币地址。 该地址来自于前序交易，并作为当前交易的输入项一并提交上来了。将前序交易和输出项计算哈希值后，如果该哈希值在区块列表中出现且仅出现过一次，那么就可以断定该输出项有效并且未被用过。
当然，当前交易必须由前序交易地址所对应的密钥签名。如果当前交易经过验证有效，则生成两个新的输出项哈希值，并插入到当前的区块。把输入项哈希值包含在当前的区块，也就标明它们被使用了。（如果哈希值存在两次，就表明被用过了。）如果要将交易表示为一个整体单元（以及现行版本可以看到的交易 图），可以将输入项的哈希值和输出项的哈希值放在同一组。然而，这并非为证明有效性所必需。
引自：中本聪，2010年8月11曰，上午12:14:22
我们试图证明某些事情不存在，似乎就需要知道全部信息，然后检查其中并不包含。
在这种情况下，我们要证明只存在一个匹配的哈希值，而不是两个。这确实需要包含全部信息的节点来证明。
我认为禁止双重消费的力度与现行版本相同。
=====警告！=====
不过，必须要考虑节点故意添加随机的“取消哈希值”所带来的危害。在这种情况下，捣乱节点不能获得比特币的使用权，因为它没有用于生成有效的、未使用过的输出项哈希值所需要的签名。但是，真正的所有者也不能使用这些比特币了。因为该输入项已经被认为用过。
这意味着新体系的验证条件与现行版本完全相同。接纳和创建自己的区块之前，所有的验证节点必须检查并验证所有出现在该区块中的交易。
如果区块中含有的哈希值并非由有效交易所表示，那么该区块必须被拒绝。 这与现行体系完全一致，即如果存在无效交易，则必须拒绝该区块。
我本来希望能弱化将所有交易传给所有验证者的条件，但是我不知道如何在没有可信任代理的情况下做到。
这里产生了一个有趣的特性，即简化了验证过程。节点需要做的全部事情就是一次性地解析区块列表。在分析每个哈希值时，只需要在哈希集中查一下就可以了。如果在哈希集中没有找到，就把哈希值加进去。如果找到了，就从中删除该哈希值。当完成区块列表分析时，就会得到有效的、未使用的输出项的最小集 。甚至可以将整个集合放入内存。（至少放一段时间！）
引自：中本聪，2010年8月11曰，上午12:14:22
在本方案中很难想出如何应用零知识证明。
我也觉得很难！有兴趣再读一遍！
本希望能产生一些深入的见解，让节点能有办法证明它们“一直遵循”区块的生成规则，每个节点不必拥有全部交易就可以进行双重检查。
没能做到。
回复：并非建议
中本聪发表，2010年8月11日，下午09:07:59
还在仔细思考这个想法……
网络唯一的工作就是判断输出项的支付是否为第一次。
如果愿意让客户端保存自有资金的历史，那么有些信息可能就不需要存储在网络上了，例如：
•金额。
•一笔交易中输入项和输出项之间的关联关系。
网络会跟踪一组独立的输出项。并不知道这些输出项属于哪些交易或金额。 客户端能够发现一个输出项是否已使用，并能提交相应的输入项来标明它已使用 。网络保存了输出项和证明它已使用的第一个有效输入项。
输入项为其关联的下一个加盐输出项用哈希值签名，这样如果知道加入的盐是什么，就可以私下里显示出为某个特定输出项所做的签名，但是公开地，网络并不知道到底是哪个输出项。
我认为客户端必须保存整段历史，追溯到最初生成的比特币。发起支付的人 也必须把这部分数据发给收款人，同时还要与网络进行通信，以标记输出项已使 用，并检查这是否是第一次支付。也许数据可以作为电子邮件附件来完成传输。
客户端必须保留整段历史降低了隐私性。处理大量资金的人仍然能看到大量 的交易历史。由于这种大面积回溯，他们最终也许会看到大部分的历史。可以设 定追溯的面值限制，但是处理大量资金的企业可能最终还是会看到大量的历史。
回复：并非建议
Reb发表，2010年8月12日，上午01:10:19
引自：中本聪，2010年8月11曰，下午09:07:59
还在仔细思考这个想法……
这个想法有一点烧脑，是吧？
事实证明，可注销公证的概念很好地普及了。
例如，这个体系并不局限于比特币交易。由于被签名的合同在体系外保存， 有额外的验证/公证规则，所以很容易实现像借据/凭单等交易。
如果有人给您5美元，您可以给他一张5美元的借据。将借据哈希公证后放入区块的哈希列表中。当您还钱时，可以让他们为借据签名确认。然后让公证员再插入一条借据哈希注销本次借款。确保没有人可以再拿回同一张借据，再次要求您还款。
引自：中本聪，2010年8月11曰，下午09:07:59
我认为客户端必须保存整段历史，追溯到最初生成的比特币。客户端必须保留整段历史降低了隐私性。
我一开始这也是这么想的。但后来我用其他方式说服了自己。
对验证者以及验证过程到底有多大信任确实很关键。可以顺着每笔交易追溯资金的来源直至比特币的生成，人们喜欢这种贴心的感觉。然而这并不是必需的 。
如果对区块创建期间的交易验证过程有信心（大于50%的CPU认可）。确信前序区块不会改变，那么只要检查相关的输出项是否还未被支付。即使交易本身存储在外部，并且前序交易根本没存储，安全特性还是保留在区块列表和程序中。您自己已经证明了使用默克尔树删除旧交易后能保持一致性。
引自：中本聪，2010年8月11曰，下午09:07:59
处理大量资金的人仍然能看到大量的交易历史。由于这种大面积回溯，他们也许最终会看到大部分历史。可以通过设定追溯的面值限流，但是处理大量资金的企业最终可能还是会看到大量的历史。
隐私的确直接与可观测性相关。如果有一个像货币兑换者这样的第三方，能把大量的输出项关联起来。但如果摆脱了每枚比特币都必须追溯到产生点的想法，观察的范围就可以更小一些。
一枚比特币有效仅是因为整个过程不会将无效币包括进来，适应这个观念的过程确实很奇怪。但事实上，这正是比特币生成的工作机制。这类交易没有输入，但是每个人都裁决该输出项一定是有效的，否则的话它就根本不会出现在区块中。
回复：并非建议
中本聪发表，2010年8月12日，上午02:46:56
引自：Reb, 2010年8月12日，上午01:10:19 引自：中本聪，2010年8月11日，下午09:07:59
我认为客户端必须保存整段历史，追溯到最初产生的比特币。客户端必须保 留整段历史，这降低了隐私性。
我一开始这也是这么想的。但后来我说服了自己。
您又回去讨论现有的比特币体系了吗？
在我所描述的假想体系中谈到，如果网络不知道交易金额和历史，那么就不能对交易进行验证和担保，所以客户端必须保存整段历史。
如果刚刚进入网络，那么有两种方法来说服客户端的交易历史有效：
1. 向其展示整段历史，一直回溯到最初生成的比特币。
2. 向其展示一段回溯到非常深区块的历史，然后相信如果有那么多节点都说当时的历史正确，那么这笔交易肯定有效。
但是，如果网络不知道交易的金额和历史就无法操作第二种方法，我不这么认为。
回复：并非建议
Reb发表，2010年8月12日，上午04:25:51
引自：中本聪，2010年8月12日，上午02:46:56 引自：Reb，2010年8月12日，上午01:10:19
我一开始这也是这么想的。但后来我说服了自己。
您又回去讨论现有的比特币体系了吗？
是的，我是在讨论这个假想体系。
按照我提出的体系，每次区块生成时，每个验证节点必须验证交易并确认区块中的哈希值，然后决定接纳或拒绝该区块。实际上，现行体系也在进行相同的工作，外加输出项哈希检查。由于其他验证者都在竞争生成区块，所以他们已经有了（至少大部分）交易。
与现行体系一样，如果未通过交易验证（以及匹配输出项的哈希值），其他节点将拒绝该区块。如果该区块得不到50%以上计算能力的接纳，就无法生成区块列表。
因此，在区块列表中出现的哈希值，至少有50%的验证者看到并验证了所包含的交易和输出项哈希值。
因此，（除非发生哈希碰撞）如果有人提交了一条前序交易与未支付的输出项相匹配，该交易一定有效。
前序交易的前序交易也一定有效，否则前序交易会被拒绝，依此类推。
如果不是这样的话，就必须假定有一段时间区块没有任何输出项哈希值通过有效性验证。但在CPU竞争机制下发生这样的事令人难以置信。
引自：中本聪，2010年8月12日上午02:46:56
如果客户端刚刚进入网络，说服其交易历史有效的方法有两种：
1) 向其展示整段历史，一直回溯到最初生成的比特币。
2) 向其展示一段回溯到非常深的区块历史，然后相信如果有那么多节点都 说当时的历史正确，那么这笔交易肯定有效。
如果客户端最近加入网络，它得假定之前的验证者遵守了规则，并且所有预先存在的区块都是有效的。（没有人会加入一个知名的腐败网络。）
当然，在现行体系下，如果不清除交易，那么新节点可以验证先前所有区块的自我一致性。但仍然无法证明绝对正确。僵尸网络可能接管了网络，并清除了一些交易，留下“新的真相”和不开心的用户。相当于上述第一种情况）。
现行体系下，如果交易由默克尔树清除，那么就属于上述第二种情况。新加 入者必须相信该过程。不必担心任何信息缺失。每个人必须假定交易有效。
特别之处在于，如果您对比特币的竞争验证过程有信心（我们确实有！）， 那么真的不需要像第二种情况中提到的“回溯到非常深的区块”。有人在另一组讨论中谈到，客户端拒绝对两个小时以前的区块进行任何更改。因此可以完全信任深度超过12的所有区块[1]。
因此，如果一笔交易处于未支付状态，并且深达12个区块，就可以清除它的所有前序交易。留着这些前序交易让人心里舒服，但没有额外的验证效果。我们必须依赖这一点：根本无办法退回并改变方向。
在此之后，每个后续区块假定所有的前序区块都真实有效。否则就会有分叉而不是后续区块。因此，对前序区块输出项进行验证了的交易，如果那些输出项存在并且未使用，那么必须认定交易有效。如果认定了其有效性，那么必须认定其前序交易也有效，即便已经清除掉。
本提案中，同样的事情也是正确的。
如果一个交易的前序输出项的哈希值未被使用且深达12个区块，那么该交易绝对没有使用过。这是铁一般的事实。检查其前序没有意义。可以结束交易验证，取消输入项哈希值，并创建新的输出项哈希值。
有意思的是，如果一个交易的前序输出项未使用且深度不到12个区块，那就是相对未使用。奇怪的是，检查其前序仍然没有必要。唯一可以改变前序项有效性的是区块链分支切换到一条更长的链。如果验证中交易的前序被交换出去了， 那么这笔交易也必然会被交换出去。
这就是个庸俗的时间机器电影情节。有人穿越到过去杀掉了我的祖辈。所以我不存在了！
总而言之，在现行的和提议的两个系统中，验证者唯一要做的就是验证前序输出项的存在且未使用（对当前的区块链来说）。这个过程保证了所有其他交易保持相对或绝对有效。
剩下的就都是些安慰剂。
-附言-
我知道写得太啰嗦，但我累得不想编辑了。
回复：并非建议
中本聪发表，2010年8月13日，下午07:28:47
我还没有领会您的想法。是否隐含了一些来自公共网络的信息？优势在哪里 ？
如果至少50%以上的节点验证了交易的有效性，那么足以丟弃旧的交易，所有人都能看到所有的交易并可以记录下来。
公开节点能看到交易的金额吗？能看到这笔钱来自于哪个前序交易吗？如果能看到，那么它们就掌握所有的信息。如果看不到，那么它们就无法验证这笔钱来自于哪个有效来源，所以不能用它们生成的链来验证。
是把比特币地址隐藏了吗？是这样吗？如果是，那我现在可能明白了。 密码学可以提供一种“密钥盲化”的方法。我做了一些研究，非常晦涩，但也许有一些东西用得上。可能与“群签名”有关。
下面这篇文章里大致提到了一些：
http://www.users.zetnet.co.uk/hopwood/crypto/rh/
我们需要的是生成公钥的额外盲变种密钥的方法。盲变种密钥具有与源公钥相同的属性，例如私钥可以为这些盲变种密钥生成签名。其他人无法判断这些盲密钥是否与根密钥相关，或者其他的盲密钥是否来自于同一个根密钥。这些都是盲化特性。简而言之，盲化就是x=(x*large—random—int)mod m。
向比特币地址支付时，每次使用一个新产生的盲密钥。
然后需要能用它签名，这样就无法知道两个签名来自于同一个私钥。我不确定一直用不同的盲密钥进行签名是否就会得到这种特性。我想如果不行就得用群签名了。使用群签名可以在签名之后不让人知道是谁签的。
举个例子，比如必须下令进行一次不太受欢迎的军事攻击，但是没人愿意作为下令者成为历史的罪人。如果10位领袖都有私钥，其中一位签署了命令而你并不知道具体是谁签的。
回复：并非建议
Reb发表，2010年8月13日，下午09:48:56
我将分两个部分来回答这个问题。
引自：中本聪，2010年8月13曰，下午07:28:47
我还没有领会您的想法。
这是我的错，因为我不想一次提出过多的主张。也不想同时引入太多新“特性 ”来分析。
我心里的目标是逐步限制交易可见性的范围。从时间和空间维度。时间意味着特定时刻运行的节点。空间意味着少于当时运行的所有节点。最佳情况下，交易只由发送者和接收者所知。那么所有的证据都会消失。
我给您一张10美元的钞票，然后就此别过。只要在那一刻没人注意到我给您那张钞票，就无法通过检查那张钞票发现这件事。
引自：中本聪，2010年8月13曰，下午07:28:47
是否隐含了一些来自公共网络的信息？优势在哪里？
如果至少50%以上的节点验证了交易的有效性，那么足以丟弃旧的交易，所有人都能看到所有的交易并可以记录下来。
我最初希望所有交易只在相关方之间进行验证。实际上，生成区块的节点只会记录被告知的哈希值。
然而，最后一刻我意识到由于没有对哈希值签名或以其他方式验证，所以可以轻易伪造“取消上一个输出项的哈希值”。虽然不能窃取他人的比特币，但是可以使比特币失效。
我领会到有三种可能的方法来解决这个讨厌的细节。
1. 让所有的验证者查看这些交易，最小化保存的内容。
2. 提出某种方法来最小化需要查看所有交易的验证者数量。
3. 为每个新的输出项创建一次性密钥对来为哈希值签名。（最后一分钟的记 录。）
因为同时引入的变量较少，所以最初我写下了第一种情况。我希望确定只记录哈希值不是明显的错误。
我试图量化可以获得的隐私。最坏的情况下只获得最小量（所有人都会保存所有信息），但是在名义上还是相当大，大多数人不保存自己用不上的信息。
因此，这个改进的好处是任何新的威胁只能观察到它们加入后发生的交易。 无法回溯，除非它们能找到从加入起就记录所有信息的早期使用者，并说服他们共享信息。这就是最小保护，但至少您的前任因此不会在周围窥探了。
然而，可以巧妙地使用分布式哈希表（DHT）来最小化空间。还有一些细节尚未解决，但是您可以把它想象成将区块列表分割成1024个相同的小区块列表， 每个小区块列表有10个冗余的验证节点。而不是具有10000个冗余的验证节点的单个区块列表。每个随机选取的节点集负责哈希空间的一部分。
与其保证需要50%的计算能力去伪造些什么，不如把目标定为达到100°%的共识和完整地广播链校验及区块。因此，在分布式哈希表周期性重组基础上，任何新节点都可以验证链是否始终保持100%的一致性。（类似于每天在报纸上刊登10 24个校验。）
这限制了攻击者的可见性，他所能知道的可以取消的哈希值变少。（只能看到1/1024的交易。）这把他提交伪造的取消请求的时间窗口限制在控制100%交易验证者的时间范围。
因此，有可能通过限制部分可见性以获得部分隐私性。这也伴随着一些潜在的风险。
所以我要将激发最佳想法的荣誉归功于您。太赞了！我最初放弃了给输出项哈希值签名的想法，因为看起来太像现在的比特币地址。我假设签名中需要的公钥会关联太多信息。
然而，如果使用一次性公钥为输出项哈希值和当前区块编号的组合签名。那么当输出项哈希值首次创建时采用公钥进行记录。当使用该输出项时，哈希由一个不同但相关的签名进行验证，该签名也是由相同的密钥签署的。
我认为这完全解决了这个问题。不存在其他的关联，因为区块列表输出项哈希值的两个单独实例必须关联。再增加一个一次性公钥标识不会带来什么麻烦。
为了简化“当前区块编号”问题，提交者可以提交接下来的3到4个区块编号的签名。验证者只会将合适的记录在区块里。
向区块列表中增加的位数确实比我期望的多。我认为最优方案是只存一个哈希值。
具有以下属性的最小加密结构是什么？也许应该考虑这一点，而非哈希和完 整签名。
1. 我给您一些看起来很随意的东西。
2. 我给您一些看似与您的#1相关，但是与其他人的#1无关的的东西。
3. 没人能从#1中找到您的#2。
举个例子：
1. 我给您Z，其中Z=X*Y，X和Y都是大素数。
2. 我给您数组（X，Y）
3. 没人能对Z进行因式分解得出X和Y。
这种情况下，当发送线下交易时，发送者会为每个输入项封装（X，Y）。
接收者会为新的输出项私下创建新的（X，Y）。
接收者广播每个输入项的（X，Y）以取消它们。广播每个输出项的Z以创建它们。
这样行吗？还是太幼稚了？
回复：并非建议
Reb发表，2010年8月13日，下午10:20:50
引自：中本聪，2010年8月13日下午07:28:47
密码学可以提供一种“密钥盲化”的方法。我做了一些研究，非常晦涩，但 是也许有一些东西用得上。可能与“群签名”有关。
下面这篇文章里大致提到了一些： http://www.users.zetnet.co.uk/hopwood/crypto/rh/
我们需要的是生成公钥的额外盲变种密钥的方法。盲变种密钥具有与源公钥 相同的属性，例如私钥可以为这些盲变种密钥生成签名。其他人无法判断这些盲密钥是否与根密钥相关，或者其他的盲密钥是否来自于同一个根密钥。这些都是 盲化特性。简而言之，盲化就是x=(x*large—random—int)mod m。
向比特币地址支付时，每次使用一个新产生的盲密钥。
然后需要能用它签名，这样就无法知道两个签名来自于同一个私钥。我不确 定一直用不同的盲密钥进行签名是否就会得到这种特性。我想如果不行就得用群签名了。使用群签名可以在签名之后不让人知道是谁签的。
举个例子，比如要下令进行一次不太受欢迎的军事攻击，但是没人愿意作为下令者成为历史的罪人。如果10位领袖都有私钥，其中一位签署了命令而你并不知道具体是谁签的。
这个主意真酷。我明白你想用它干什么了。我想了好几遍才把思路捋清楚。 我是对的，您建议使用一次性盲密钥对输出项的哈希值进行签名。
盲公钥相当于交易中比特币地址的公钥。如果说比特币地址的公钥私钥对是 P/p，那么盲公钥就是P1，P2，P3，…，Pn。其中每个都可以验证私钥（p）签名 。
所以在创建过程中，当提交输出项的哈希值进行验证时，看起来就像是由P1 签署的。然而，当接收者取消该输出项时，则会以P2或P1以外的其他密钥签名（ 因为P1已经被公开记录）。两个签名的结果都一致，但是公钥会更换。这就意味着只有公用私钥的拥有者才能生成签名。 天才！
[1]比特币一般情况下每小时生成6个区块。一译者注