玩币族移动版

　　由于比特币分叉慢慢步入主流，人们常常忘记它仍处于测试阶段。每天都有新的源代码融入开发库，他们曾使之成为最成功的分布式价值储存和不易变更的记录。更新版本开始有了细微变化，比如说语法和文档更新，主要优化了比特币的部分功能。

　　可以将主要的发展规划称为BIPS，或者也可以说是改进建议。BIPS提出，通过修改代码库来改变比特币的运行方式。BIPS共识是由开发人员批准、测试单元，并探索可能出现的边缘效应。

　　有时当提出实施P2SH这类方案的时候，就需要权衡利弊从而挑选最佳选项。一方面，让用户接受新式比特币BIPS是个长期过程，但是随着开源项目的发展，最好让所有程序员进行严格测试，寻求建立安全稳定的代码库，以此为用户规避潜在风险。

　　BIPS经常会出现在开发人员的讨论话题或Github中。这类讨论激发了Peter Todd，让他很长一段时间思考如何致力于比特币核心和相关项目的研发，他现在正在努力编纂他的提案BIP 65，名为OP_CHECKLOCKTIMEVERIFY。这个提案还添加了一个附属的操作码，在比特币的脚本语言中是一个函数或指令。

　　多重签名地址等功能的示例操作码是由矿工提出的，以一种可编程的办法使其得到稳定性。这个想法源自nLockTime的局限性，这个交易参数限定用最少的时间，在一个区块交易完成之前，必须通过 Unix Time或blockheight。BIP65的这种功能也被运用于一种名叫维尔币的山寨币中，因为彼得·托德担任他们的顾问兼首席科学家。

　　BIP65将允许用户在指定时期内进行交易，在blockheight或unix时间，同时还会添加额外的参数，比如说一种带有秘钥签名的特定组合。BIP65有许多应用案例，其中包括托管、非交互式限时退款、双重钱包、小额支付渠道、以及矿工的贡献，为那些想深入了解技术和代码示例的人提供了更多信息。

　　和nLockTime相似，BIP65的提案将允许用户在限定时期内使用资金，但更具灵活性。比如说，可以通过输出指令的多重签名托管方式使用BIP65，在发放资金时需要明确指出时间和秘钥组合。举个例子来说，假设父母双方给孩子10枚比特币，将其发送到一个带有3重签名的多重签名地址。父母各自持有一个单独秘钥，孩子持有一个秘钥。为了使资金便于支配，那么父母双方都必须签署协议。

　　其他的两种组合方式(孩子随妈妈或者孩子随爸爸)都无法使用这笔资金。但是，随着时间的流逝，比如说一年之后，孩子只需父母单方秘钥就可以使用这笔资金。但BIP65附带保护条款，在特定情况下无需父母双方的许可，比如说在遇到灾难的时候，只有父母单方签署也可以发放这些资金。

　　直接把新功能添加到比特币代码库是一个漫长的过程，因为需要得到开发人员的同意，会收到社区反馈，在实施之前必须通过关键测试。许多改进需要花费时间，有些还需要硬叉。

　　阅读硬叉列表是件有趣的事，可以看到如果开发人员不在意硬叉的麻烦和风险，他们会有所改变。某天，我们可能会看到一个更好的硬叉，不过要等到BIP65的功能被应用于一个软叉当中，并被大多数矿工接受。

　　在主要的比特币提议背后也有细微差别。幸运的是，我们有机会能采访到Peter Todd，让我们了解BIP65的更多知识，以及它如何使比特币得到优化。

　　Gavin Knight:最初，你为何会有建立CHECKLOCKTIMEVERIFY的想法？

　　Peter Todd: 有趣的是，在还没使用过nLockTime的时候，总有人会问你感觉如何，但这确实是你所期望的一种限时交易方式，实际工作又有些不同。

　　GK:你认为这种功能应该如何被运用？

　　PT:简单举例，就像锁定一个孩子的大学基金，直到他们年满18岁，实际上真正令人激动的是经济协议背后的应用。微支付渠道就是一个很好的例子。

　　引人注意的是星型模型：如果 Alice、Bob和Charlie都有一个共享枢纽的微支付渠道，他们之间就可以不断汇钱。这样就极大地增加了比特币的可伸缩性。

　　CHECKLOCKTIMEVERIFY微支付渠道的工作方式是，发送方首先发送一笔预付定金到一个由发送和接受方共同管理的地址。然后每笔支付都是以半签署的方式发送给接收方，每次签署的资金会越来越多。

　　最近的交易会被标记，CHECKLOCKTIMEVERIFY常用于确保交易过程，如果接收方消失，那么只需发送方解锁，取回那些资金。还有一种预签退款交易，如果他们觉得缺乏稳定性， CHECKLOCKTIMEVERIFY会让协议变得更简单、健壮。

　　GK:你能否描述下BIP开发商的共识过程？

　　PT:就拿近期P2SH/OP_EVAL/OP_ CHECKHASHVERIFY软叉来说，可以看到两个团队的三种竞争协议，如何让多重签名以及其他应用变得更可行，每种应用方案各有利弊。

　　还有一个重要问题就是，最终没人在软叉上写明带有新功能的实例应用;这种网络应用程序更新大概花费了两年时间才出现。当这些应用程序被发现带有P2SH局限性，再另寻解决方案。

　　我们希望看到有人在使用CHECKLOCKTIMEVERIFY的过程中写下演示，它的使用方式最简单。

　　GK:软叉有什么潜在风险吗？

　　PT:功能上可能有漏洞，但这是在五行代码的审查中实现的，所以风险相当小。较大的风险在于矿工，在升级之后，那些未升级的矿工有时可能会创建出无效的区块，失去那些区块收益。但是，Bitcoin Core会有所保护。