在10月底，BCH Boys与Bitcoin SV开发团队的史蒂夫·施德斯（Steve Shadders）和丹尼尔·康诺力（Daniel Connolly）进行了视频专访。他们还就此制作了访谈记录。请见下方的访谈全文。
在采访了Bitcoin SV团队的史蒂夫·施德斯（Steve Shadders）与丹尼尔·康诺力（Daniel Connolly）后，我们投入了大量的工作将全部访谈整理成了文字。这次专访中，两人分享了极为丰富的信息。在我们看来，这些信息对于企业与矿工十分重要，因此我们认为有必要把访谈用文字记录下来。为了避免有所偏颇，全文几乎完全从采访视频转录整理而来，其中仅仅为了便于阅读进行了几处修改。如果您认为有必要纠正任何内容，请与我们联系。每个问题均采用粗体，此外每个问题和回答都标出了相应的时间。您可以点击下方链接观看视频：
专访全文：
—————————————————————————————————-
康纳（Connor）：02:19.68,0:02:45.10
感谢丹尼尔和史蒂夫能接受今天的采访。除了来自nChain的史蒂夫·施德斯与丹尼尔·康诺力之外，还有“中本聪愿景”（Satoshi’s Vision）客户端的高级开发人员。丹尼尔、史蒂夫，在我们正式开始前，你们两个人是否可以介绍一下自己——说说你们是谁还有你们是如何起步的？
史蒂夫：0,0:02:38.83,0:03:30.61
我叫史蒂夫·施德斯，在nChain任工程解决方案总监。特别对于Bitcoin SV项目，我是该项目的技术总监。也就是说，和丹尼尔相比，我的一线工作较少，但是会负责大量联络矿工的工作，也就是整个项目的铺垫工作。
丹尼尔：
大家好，我叫丹尼尔，是Bitcoin SV的首席开发工程师。随着我们开发团队不断壮大，我本人实际上并不需要经常要写代码，而是将更多的精力放在组织团队以及安排工作上。
康纳：03:23.07,0:04:15.98
很好，那么让我们来看一看大家提出了什么问题——我们在Reddit上发帖邀请人们参加讨论并且提出自己的问题。我们会尽可能讨论大家提出的所有问题，同时也会去掉一些重复的问题，所以我们会逐一回答这些问题。我们自己也添加了一些问题，如果可以的话，我们会尽量回答大多数问题。那么，最一开始我们想要问的是：众所周知，比特币现金已经诞生一年多了。比特别本身已经有十年的历史，但是在过去一年多的时间里，对于你们与多个开发团队合作来说，这个过程是怎样的，并且，为什么如今拥有“中本聪愿景”客户端如此重要？
史蒂夫：0:04:17.66,0:06:03.46
没错，我们与各个开发团队沟通已经有一段时间了——从去年十一月起，各个实施步骤的比特币现金开发者每两周就会进行一次会议讨论。我本人从今年一、二月间开始参加这些会议，丹尼尔也在几个月后加入进来。我们与所有这些团队进行沟通，我想，你也知道，问题和质疑肯定是不可避免的。众所周知，存在很多分歧，但是我期望不远的将来能有一天共识问题都能得到解决，到了那个时候，各个不同的开发团队之间就没有那么多理由持不同意见了。他们也许会对那些非共识性的问题抱有不同意见，但是这并不是世界末日，因为Bitcoin Unlimited仍然可以自由地在Bitcoin Unlimited后端按自己的想法去实现，而Bitcoin SV也可以自由地在自己的后端做自己想做的事情。如果他们能在非共识层面上可以互通，那就太好了。如果不能互通，也不是什么大问题，两者之间显然会有沟通桥梁，因此，是的，我认为这种有大量截然不同想法个性组合的复杂情况在未来会变得越来越少。
科瑞（Cory）：0:06:00.59,0:06:19.59
我想未来对于测试网络（Testnet）还存在着另外一个问题——Reddit上许多人在问Bitcoin SV的测试流程是怎样的，以及你们是否打算公布这些测试的结果？
丹尼尔：0:06:19.59,0:07:55.55
当然会，在首次发布Bitcoin SV时，我们关注的是稳定性，这需要大量额外测试，特别是在单元测试层面并不多，更多的是在系统测试层面，因此我们建立测试网络、进行测试，然后确保软件可以按我们预期的那样，正确运行。我们还要确认所进行的变更，确保没有任何副作用。大家知道，因为我们发布第一版时十分匆忙，虽然我们已经记录了所有测试结果，但还没有完全准备好发布它们。我们在考虑进行公布，但是时机还未成熟。
史蒂夫：0:07:50.25,0:09:50.87
我做一点补充——我们投入了大量的时间开发了极为稳健的测试流程，目前的报告是容易在我们内部系统上阅读的，但我们需要整理之后才能公布与众。我们目前的头等大事就是确保软件使用的安全性。我们已建立了一个测试框架，其中包括在多个的测试环境中连续测试代码变更——我认为，在代码变更获得质检审核批准前，要先通过五个不同的测试环境——关于刚才有关测试网络的问题，是的，我们已经有了四个。我们有测试网络1和测试网络2。对于第三个测试网络，我们采取了略微不同但是大家可能都比较熟悉的编号命名机制——这样便于内部引用。他们（1和2）都是测试网络3的分叉。测试网络1用于激活测试，因此我们在激活前后进行测试——每过几天我们就会重置一次这个测试环境。测试网络2用于激活后测试，因此我们会测试所有共识变更。第三个是性能测试网络，我想大多数人都可能听到我们之前称之为“Gigablock测试网络”。每次说这个词的时候我都感觉自己的舌头好像打结了，所以后来我开始称它为性能测试网络，我们计划建两个这样的网络： 我们可以用其中一个进行自己的内部测试与实验，不用担心是否会存在未知的外部因素，也不用担心让其他人加入做些我们不知道的东西而影响我们基线性能测试的能力。另外一个（我觉得应该还在建造中，丹尼尔也许能回答这个问题），是那种基本上每个人都可以加入的网络，而且大家可以尝试进行各种各样的破坏性操作。
丹尼尔：0:09:45.02,0:10:20.93
的确，我们最近已经与其他比特币现金开发团队分享了关于测试网络1和2的详细信息。到目前为止，我们只与一个开发团队共享了Gigablock测试网络，不过就像史蒂夫说的那样，我们的确会把它建成一个可以公开访问的测试环境。
康纳：0:10:18.88,0:10:44.00
我的下一个问题是，我看到你们在推特上发了关于复活Gigablock测试网络计划的消息，看起来好像大于32 MB的区块正在那里被挖出并传播，但是区块浏览器本身可能会崩溃——这个复活的Gigablock测试网络计划是什么样的？
丹尼尔：0:10:41.62,0:11:58.34
那正是Gigablock测试网络的作用。Gigablock测试网络最初由Bitcoin Unlimited在nChain的帮助下建立而成，并且他们做了很多出色的工作，所以我们希望能够重振它。我们想要重新使用它，并进行一些大规模测试。它是一个灵活的网络——曾几何时，我们有八个不同的大节点遍布全球，类似于过去网络的镜像。目前我们在正在进行缩减，所以目前没有使用这个网络，所以大家会发现是有三个。我们在测试网络中已经生成了一些大区块，这对于Bitcoin SV扩容性的研究来说很有帮助，因此它指导团队在过去一两个月中为了提升扩容性所做的工作。
史蒂夫：0:11:56.48,0:13:34.25
我认为这一点说的很好，很全面地概括了我们在两个阶段分别关注的工作。就像丹尼尔刚才说到的，由于时间紧迫，我们在定于10月15日发布的版本中将变更的数量降到了最少——只进行了共识变更。我们根本没有做任何性能方面的工作，而是完全地将关注点和精力放到了建立质检流程并确保所进行的变更可安全运行。我们所建立并执行的这个流程的确很好。它突出了我们的团队缺失的资源——为此，我们的招聘人员一直忙于寻找一位测试经理和更多的质检人员。在此之后的第二个阶段，我们开始进行性能方面的工作，就像丹尼尔刚才提到的，我们用性能测试的结果来规划开始的任务，让我们得以进行与性能相关的工作。现在这项工作仍在进行中——对于一些我们已经识别的任务项来说，代码开发工作已经结束，目前正在走质检流程，因此还没有完成所有工作。这基本上就是我们现在所进行的两个阶段。我们对于未来的工作建立了一个路线图，列出了更多的工作，但是主要还是以质检为先，性能其后。性能提升工作即将完成，但是在未来一段时间内有一部分工作将持续进行。
丹尼尔：0:13:37.49,0:14:35.14
对于性能来说，我们所要实现的一些变更的确规模很大，会涉及到软件的基本层面。这些变更主要可以分为两大类。一类是软件的内部变更——也就是对于Bitcoin SV本身的变更，旨在改进内部运行的机制。另外一类则是面向外部的接口。尤其是我们与另外一个开发团队紧密合作推出的一个兼容性变更——并不是共识变更或其他类似的变更——而是在多个不同的实现上有着相同的接口将会很有帮助，因此我们与他们紧密合作，来提升扩容性。
康纳：0:14:32.60,0:15:26.45
很明显，对于Bitcoin SV来说，你们希望实现的主要目标之一就是做其他开发组织所不愿意做的事情，将最大默认区块规模提高到128 MB。这里我想就这一点请教二位——无论是完全取消区块大小限制还是大幅度提高大小限制都面临着许多反对的声音，反对者认为这会导致“无限区块攻击”（Infinite Block Attack），从而带来许多的问题。你们对于无限区块攻击怎么看？这是切实存在的问题吗？矿工本身是否应当更加主动地去采取预防措施？或者换句话说，如果取消了区块大小限制，对于大家认为会发生的这种攻击来说你们怎么看？
史蒂夫：0:15:23.45,0:18:28.56
推特和Reddit上经常会引用我的话——就像我之前所说的一样，无限区块攻击纯粹是胡扯。现在，我想这样的话很容易被断章取义，但是我认为对于120 MB的限制来说，可能有两种不同的派别。有些人认为只要软件还能处理我们就不应当将限制提高到128 MB，还有人认为现在提高区块大小没有什么问题，当软件还具有处理能力时提高区块大小限制，以便当软件升级、处理能力改进时，你不会被局限。显然，我们是属于第二个派别。就像我之前说过的一样，我们计划会推出许多提升性能、加强性能的变更。如果我们等到五月才将区块大小限制提升到128 MB，然后再去提升性能，我们将无法在主网上展示这些变更。对于无限区块攻击本身来说，我认为可以采取一些缓解机制。首先，从技术细节角度上来说，当你发出一条块消息或任何点到点消息，块头包括了消息大小的信息。如果有人说给你发送了一条大小为30 MB的消息，你收到后发现大小为33 MB，那么很明显，你会发现出了问题，然后就能断开连接。如果有人给你发送了一条大小为129 MB的消息，你知道区块大小限制为128 MB，那么下载这条消息就没有什么意义了。这只是可以采取的一些预防措施示例。我刚才说这种攻击纯粹胡扯，是因为预防这种攻击实际上根本不重要。我觉得在比特币的世界中，有一种思想流派认为如果某些东西不在软件中，那么就相当于不存在。我不同意这个观点，因为可以通过一些小的变更就能解决这类问题。无限区块攻击的另一个方面是——让我们不要称之为无限区块攻击，就称大区块攻击——验证需要花费太多的时间，我们对进入的区块采用并行管道来解决这个问题。假设你收到了一个区块，不知什么原因，你花费了两个多小时来下载并验证这个区块。用不了多久，其他人会挖出另一个区块，只要这两个区块没有堵塞在一个串行管道中，那你就会知道这个问题自然而然解决了。
科瑞：0:18:26.55,0:18:48.27
传播这种较大区块会不会带来什么问题？ 因为目前人们对于Bitcoin SV将区块扩容到多大才符合实际需求提出了很多问题，并且担心在整个网络中传播这些区块会带来问题。
史蒂夫：0:18:45.84,0:21:37.73
的确，对于这一点有诸多担忧。我认为人们忘记了致密区块和极瘦区块（xThin）的存在，因为大小限制为32 MB的区块在大多数情形下——甚至几乎在所有情形下——并不是发送32 MB数据。我想真正值得人们担心的问题是中国的防火长城（Great Firewall）。最早在Bitcoin SV中，我们开始与防火墙另一侧的矿工进行沟通时，这也是他们最担心的问题之一。我们之前看到报道称，人们很难建立速率高于200 K/秒的稳定连接，即使是致密区块，你仍然需要将交易传送到防火墙的另一侧。因此，我们在这方面进行了大量的研究——我们尝试让自己的连接穿过防火墙，实际上是CoinGeek的连接，因为他们给我们了权限去访问一些CoinGeek的服务器，让我们进行各种实验，我们可以将连接速率保持在50 MB到90 MB之间，这样以来我们要在很久以后才需要去考虑防火墙的问题。我一时想不起来具体的数字，但是我们可以保持相当大的区块。我们有几个选择——很可能是点到点协议的频繁通讯导致了这些与防火长城有关问题，因此我们找人开发了一种桥接工具，你基本上可以在防火墙两侧建立某种交易真空，将所有通讯收集起来，每隔一两秒把它们作为单个大块数据发送出去，从而避免频繁的通讯往来。另外一个选择是，我们正考虑开发一种数据选择器，用它来将数据发送到防火墙一侧的点到点网络中，穿过分解器，通过多条连接进行传送，然后在另一侧重组数据，这样一来无需经历太多波折就能穿过防火长城，但是回答你这个问题的关键所在——的确，可区块大小传播时间的确存在理论上的限制，而这是由摩尔定律决定的。采用更快的连接能让这个问题更加遥远，未来只要不断采用更快的连接就好。我认为就当前的互联网连接速度来看，128 MB大小的主块不会造成什么问题。
科瑞：0:21:34.99,0:22:17.84
你们推出的变更之一是提高最大脚本限制，我想现在已经从201增加到500（操作码）。那么我有一些与这个方面相关的问题。第一个是，为什么不完全取消脚本大小的限制？我想你们提到在测试的时候遇到了一些问题。第二个问题是，你们有多确定脚本执行已经没有剩余的logN缺陷或漏洞？
史蒂芬：0:22:15.50,0:25:36.79
脚本大小是个很有意思的决定——我们最初计划完全取消限制，并在下一次脚本大小限制之后（下一次生效的脚本大小限制为10,000字节）就会这样做。我们最终采取了比较保守的做法，将脚本大小限制定为500——有趣的是我们为此受到了一些人的抨击，而最初对我们横加指责的原因却是取消脚本大小限制是危险之举。我们这样做是为了采取保守的做法。我们针对logN缺陷进行了一些研究——对不起，应该称之为logN“攻击”，人们更喜欢这么叫。在研究中，我们发现了一些这样的缺陷，并且认真地加以思考。我们认为，如果我们能在这么短的时间里能发现这么多缺陷并且全部修复（就像打地鼠游戏一样，发现一个修复一个），那么这意味着很有可能会有更多未知的缺陷。所以，我们对于这种打地鼠式的方法也考虑了很多，但是我们真的无法确定是否还有缺陷。我们会一一修复这些缺陷，但是更周全的方法是确保如果有人的确发现了这样有缺陷的脚本，这不会导致节点突然停止运行，那么现在问题在于，因为比特币节点本质上采用单线程，如果你碰到一条这样的脚本并且在长时间内锁定脚本引擎，那么同一个队列中在此之后的一切脚本都会停下来并处于等待状态。我们想要做的是，一旦脚本验证途径处于瘫痪状态（部分已经处于这种状态），那么我们基本上就会为众所周知的交易模板分配一些线程，为其他任何类型的脚本也会分配一些线程。如果你碰到了一些问题脚本并且在一段时间内锁定了线程，这并不会让节点停止运行，因为你还有其他专为众所周知的脚本模板所预留的快速渠道，这类脚本可以直接持续地穿过节点。一旦你处于这种情形下，我认为这时更适合完全取消限制，因为最糟的情况可能就是你的非标准脚本导致了堵塞，其他一切不断处于等待中——还有其他方案可以防范这种问题，这意味着我知道只要你愿意，你就可以限制脚本执行的时间，而这要由各位矿工自己做决定。Bitcoin SV的使命在于，为矿工提供工具，从而矿工可以选择如何利用这些工具——如果他们希望限制脚本执行的时间，那是他们的选择。
丹尼尔：0:25:34.82,0:26:15.85
的确，我想指出的是，无论节点什么时候通过点对点网络收到一笔交易，都不是必须要接受交易，你可以拒绝交易。如果节点认为某笔交易看起来可以，那么可以直接说我们不打算处理这笔交易，或者执行时间超过了五分钟，甚至超过了一分钟，节点都可以终止并放弃这笔交易，就是这样。唯一不能这样做的时候，就是交易已经存在于区块中，但是即使如此，节点仍然可以决定是否拒绝该区块。软件中一切都有可能。
史蒂夫：0:26:13.08,0:26:20.64
是的，如果它已经在某个区块中，那意味着其他人已经验证了这个区块，那么……
科瑞：0,0:26:21.21,0:26:43.60
对于重新启用OP_MUL、OP_INVERT、OP_LSHIFT以及OP_RSHIFT 等操作码人们进行了许多讨论，你们是否可以谈一谈重新启用这些操作码为什么如此重要？
史蒂夫：0:26:42.01,0:28:17.01
我认为，最为重要的事情之一是，这些操作码不再仅仅是与DUP和MUL差别不大的变体，而是代表了最初完整的操作码集。我认为这并不一定是个技术问题，而是一个重要的里程碑。我听到人们针对MUL做出了一些有趣的评论。人们问我，如果你正计划将操作码改为大数操作，而不是采用目前强制执行的32位的限制，你为什么重新将OP_MUL包括在操作码集中？ 简单来说，我们现在包括了所有数学操作，除了OP_MUL。我们增加了除、减、取模等操作——如果新的脚本系统包括了除了乘以外的所有数学基本式，那看起来会让很感到很奇怪。另一个方面在于，这些操作码的确有用——我们讨论过一种Rabin签字解决方案，它基本上复制了DATASIGVERIFY的功能。那只是这种操作做法的用例之一——大多数加密基本式操作需要进行数学操作，字节位移对于许多操作来说都很有用。因此，其实质在于完成工作、完成脚本引擎，或者不去完成这些工作，而是让操作码恢复到本来应有的样子。
康纳：0:28:20.42,0:29:22.62
大数与32位限制。我曾经看到过丹尼尔……我想我看到你不久前在Reddit上回答这个问题，新操作码使用了逻辑位移，而中本聪的版本使用的是算数位移——我想人们经常提出的问题是——也许更多是反问——为什么不完全回到中本聪提出的操作码？变更这个操作码并稍微改变操作方式有什么益处？
丹尼尔：0:29:18.75,0:31:12.15
这个问题涉及到两个方面——大数位移和采用逻辑位移，而不是算数位移。当我们重新启用这些操作码时，我们经过了周全的考量并对它们稍作调整，就像我们过去调整OP_SPLIT操作码一样。所以新增加的LSHIFT和RSHIFT都是按位操作符。这两个操作码可以用来实现算数位移——我已经发布了一段简短的脚本来实现这一点，但是我们不能进行撤销操作。你不能用算数位移操作符来实现按位操作。这是算数数值中的字节顺序所致，因此数值代表了数字。也就是说，这个小字节序被交换到其他系统中——我认为这很正常，或者大字节序也是如此。如果你以数字的形式开始位移，那么字节的位移序列会有些奇怪，因此不能进行撤销操作——你不能用算数操作来实现按位操作，因此我们选择采用位移操作符，这是我们所提出的方案。
史蒂夫：0:31:10.57,0:31:51.51
这实际上是我们在五月份做出的决定，也可以说是五月份一系列决定所导致的结果。五月的时候，我们重新启用了OP_AND、OP_OR和OP_XOR这几个操作码，我们当时还决定用OP_SPLIT替换三条各不相同的字符串。所以，这并不是我们达成一致意见所做出的决定，那是比特币现金开发者共同做出的决定——虽然他们不是参加了每次会议，但是他们都收到了邀请。
丹尼尔：0:31:48.24,0:32:23.13
另一个例子是，我们原本提议增加OP_2DIV和OP_2MUL，两者都是独立的操作码，可将数值乘2，但是人们指出，只要让对象乘以2就能轻松地达到相同的目的，并不需要专门增加一个单独的操作符，因此我们放弃了这种打算，从操作集中去掉了这两个操作码，因为我们希望将操作码的数量保持在最低。
史蒂夫：0:32:17.59,0:33:47.20
目前有一种倾向是尽量减少操作码的数量。我是说用OP_SPLIT操作码替换OP_SUBSTR、OP_LEFT和OP_RIGHT实际上是加文·安德森（Gavin Andresen）提出的想法。他在电报工作组（Telegram Workgroup)短暂露面，那是我们正在研究如何在五月份变更操作码，而且加文的话十分权威，因此我们也听取了加文的想法。但是如果我们选择在五月份实现操作码（按位操作码）并且将数据作为大字节数据流（抱歉，大字节实际上并不适用于普通的数字字符串），那可能会导致在将LSHIFT和RSHIFT实现为整数操作码时会出现不一致的现象，因为你必须要具有一系列可以支持两种不同数据类型的按位操作码，这既没有意义，而对于任何人来说也很难运用，就是这样。我是说这有点像P2SH——它并不属于最初中本聪协议的一部分，某些事情已经做了，那就已经成为了事实，如果你要向前发展，那么就要在现有的框架范围内开展工作。
丹尼尔：0:33:45.85,0:34:48.97
当我们碰到大数操作码时，工作变得极为复杂。大家都知道，数字实现就是这样，因为你不能改变现有操作码的行为，我并不是指 OP_MUL，我是说其他已经存在很久的操作码。你不能突然让它们成为大数操作码，而不去认真地查看有什么脚本，以及变更现有的脚本会带来什么样的影响。另一方面，由于P2SH的存在，你不知道现在有什么脚本——脚本中可能会有你不知道的内容，你不知道变更这些操作码的行为回答来什么样的后果。大数这件事情很难搞懂，因此另外一种选择是……我不知道是什么样的选择，但是要经过深思熟虑才可以。
史蒂夫：0:34:43.27,0:35:24.23
我们与其他实现团队进行了沟通——实际上是他们对重新启用大数操作的最佳方式提出的一些建议。这项工作必须极为谨慎，我不知道明年五月我们是否能发展到这一步，也许其他的时间点会实现，但是我们的确愿意在这件事情上投入大量的资源，我们很愿意与BU、XT或其他组织合作，一同完成这项工作并且保证安全。
康纳：0:35:19.30,0:35:57.49
我们沿着这个思路继续采访，Bitcoin Core推出了标准脚本的概念——也就是将脚本分为标准脚本和非标准脚本。我和克莱蒙斯·雷（Clemens Ley）就他们所谓的“非标准脚本”进行了一次非常有趣的谈话。我知道在Bitcoin ABC至少有一位开发人员对这种做法很犹豫，或者某种程度上有些抵制他的做法。那么，你对非标准脚本以及IsStandard校验整体来说有什么看法？
史蒂夫：0:35:58.31,0:37:35.73
我实际上希望能将这个概念用在其他地方。我想我之前提到过多线程脚本验证，并且现在有一些众所周知的专用脚本模板——当你用“众所周知的脚本模板”这个词时，比特币中实际上已经有这样一种校验机制，可以识别所使用的是否是众所周知的模板，那就是IsStandard。总的来说，我支持废除标准交易的概念，但是这实际上是矿工们的选择，更多涉及到行为上的变化，而不是技术上的变化。矿工可以使用许多配置选项来决定如何对待他们心中的标准或非标准脚本，但是现实情况是，并没有太多的矿工在使用这些配置选项。所以，我认为，标准交易作为一个概念对于不同的人来说具有不同的意义，但是我希望让人们可以更加方便地将非标准脚本加入到比特币中，这样他们就可以进行各种尝试。就我与CoinGeek之间的讨论来说，他们更热衷于让矿工们至少在一开始接受最终会有许多不同类型的交易。
丹尼尔：0:37:32.85,0:38:07.95
我认为从效率的角度来说，IsStandard在实现中仍然十分重要——你要通过这种机制来优化现金支付基本用例然后进行优先分级。在这方面，IsStandard仍然扮演重要的角色，但是就节点与整个网络其他部分之间接口来说，我肯定未来会去掉这个机制。
科瑞：0,0:38:06.24,0:38:35.46
康纳提到有些人不同意Bitcoin SV的做法——他们提出了许多问题。比如说，为什么定在11月？ 为什么在11月实现这些变更？他们认为如果推迟六个月的话也许就不会导致分叉了。那么，首先是你对可能将要发生的分叉怎么看？其次，为什么要急于在11月实现变更？
史蒂夫：0:38:33.30,0:40:42.42
无论我们是否实现这些新操作码，11月的时候都会出现对共识规则的分歧。我想早在8月16日或17日的时候，Bitcoin ABC就已经公布了11月硬分叉变更的技术细节、客户端，并且他们的实现包括了CTOR和DSV。对于启动了SV项目的矿工来说，CTOR和DSV是充满争议的变更，一旦他们选择加入，那就没有回头路。这些变更时不可撤销的——我是说虽然你可以在晚些时候撤销，但是对于DSV来说，一旦有人用这个操作码将P2SH交易发送到项目中，甚至只是将非P2SH交易发送到区块链中，这是不可撤销的。因此，我很好奇为什么有些人会说Bitcoin SV项目导致了分叉——我们并不是提议去做其他人所不认可的事情，对于更改操作码限制来说的确有些争议，但是我们所做的……Bitcoin ABC早在5月就已经发布了技术细节，而我们发布的是新操作码的技术细节，所以从紧迫性的角度上来看，我们应该等吗？ 实际上我们不能再等，11月份有些像Segwit（隔离见证）——一旦Segwit得到推广后……当然，你可以说花掉每个人……任何人都可以花费交易，从而达到退出的目的，但是实际上永远也不会那么简单，这会导致巨大的经济动荡，就是这样。我们实现这些变更是因为，无论是否会出现共识规则分歧这些变更都不会带来影响——无论我们是否实现这些变更，都会出现分歧。而且我们倡导的变化根本没有什么可争论的。
丹尼尔: 0:40:39.79,0:41:03.08
如果我们没有将这些变更包含在11月的升级中，那么我们会在毫无变化的情况下继续做事，但是我们有11月的升级，所以我们应该尽可能地使用它。将这些无争议的变更加入其中。
康纳: 0:41:01.55,0:41:35.61
你们能谈谈DATASIGVERIFY吗？ 你们对其有何顾虑？ 瑞安·查尔斯（Ryan Charles）认为的广为流传的一般性概念是，它是一种补充，对吧——它要占用一整兆字节，需要进行大量的运算，而且计算时间保持不变，但成本可能较低——你是否有些赞同他对此的观点，或者你对此有何顾虑？
丹尼尔：0:41:34.01,0:43:38.41
我能说一两句吗？我对此可以有不同的看法。我是一名工程师，我的专业是软件，所以从经济学角度我听到了不同的意见。我相信其中一些观点，但我不是经济学家。根据我在这方面的有限的专业知识，我有点同意这是一种补充，在我看来很像，但这毕竟不是我的领域。我能谈论的是软件 – 因此，增加DSV会让代码变得十分复杂，而且这是一个很大的变更。我们要怎么做呢——每当有人想出一个想法，我们都会添加一个新的操作码吗？那么我们要添加多少个操作码？ 我看到一些报道称，吴忌寒正在谈论增加数百个操作码或类似的东西，如果这样的话，客户端会变得有多大？这个节点要有多大？它是不是必须要支持新增加的这些奇奇怪怪的操作码？ 这样一来，软件就会变得难以管理，而且还有DSV……这是我一开始的主要考虑因素，如果你可以在脚本中实现，那么你就应该这样做，因为这样可以让节点软件简单且稳定，同时更容易测试其是否正常工作。这差不多就像是从微处理器中添加（？）代码一样。如果你已经能在脚本中将实施，那么你就会知道你为什么要这样做。
史蒂夫：0:43:36.16,0:46:09.71
实际上这是一个很意思的矛盾体，因为当我们讨论在5月增加操作码时，似乎推动我们能够形成共识、做出决策的理念是，简化操作码并尽量减少操作码数量（即，你可以组合使用几个原始操作码来复制某种功能，这比增加新操作码或替换现有操作码更可取）。OP_SUBSTR是一个有趣的例子——它综合了SPLIT、SWAP和DROP操作码来实现自己的功能。因此，在真正原始的脚本级别，我们有让其保持最小化的理念，且在这种（？）理念中，我们只需为每个原始函数添加一个新的操作码，所以丹尼尔是对的——这是一个打破制约的问题。这在哪里结束？ 如果我们将只走这条路，它差不多对为什要使用脚本语言的论点展开论证？ 为什么不一次性只通过一个硬代码添加所有这些函数呢？ 支付公钥散列是一个众所周知的构想（？），并且一点都不必费心执行一个脚本，但一旦我们完成了这个，我们就会拿走人们创新的所有灵活性，因此我想这是一种理念上的区别，但我认为让其保持简单的立场确实有意义。所有基元都可以做人们需要做的事情。人们不觉得他们做不到的事情是因为存在的限制。如果我们没有任何操作码限制，如果你可以将一个千兆字节的交易也用一个千兆字节的脚本做出来，那么你可以做任何你想要的加密，即使使用32位整数操作。当然，一旦你摆脱了32位的限制，就会出现很多较小的这些脚本，所以Rabin签名脚本从100兆字节减少到几百字节。
丹尼尔：0:46:06.77,0:47:36.65
是的，我花了整整六个月的时间在脚本上。一旦你开始使用该语言并了解它能做什么，那么你可以用脚本实现的东西令人印象深刻。比特币最初是用脚本设计、发布的。我的意思是比特币不一定非要用脚本——它可以只用与脚本进行的交易来代替，你可以拥有帐户，并且你可以说信任如此多比特币（BTC）从这个公钥到这个公钥 – 但这不是比特币完成的方式。它是使用脚本完成的，如果你开始正确地对脚本进行探索，那么它会提供很多功能。如果你开始真正地深入研究脚本能做什么，是的，你会发现你能用脚本做的事真是太神奇了。我真的很期待看到一些用脚本完成的非常有趣的应用程序。我是说，Awemany的零配置脚本非常有趣，对吧。我的意思是这依赖于DSV是个问题（以及其他一些我不喜欢的方面），但是他深入探索并使用脚本来解决这个问题真的很酷，看到这真的感觉很棒。
史蒂夫：0:47:32.78,0:48:16.44
实际上，今天早上我向我们忙于Rabin签名的研究小组中的几个人提出了一个问题，我不知道他们在这方面达到什么进度了，但他们实际上正在进行Rabin签名脚本概念的证明（我认为这很快就要完成）——它将使用较小的签名，以便让它可以适用于当前的限制，但是它在效果方面与其他算法相同（如DSV），所以我不能给你一个的确切完成日期，但看起来我们快就会让Rabin签名出现在区块链中（一个小型Rabin签名）。
科瑞：0:48:13.61,0:48:57.63
根据你们的回答，我想我差不多已经知道这个问题的答案了，但是有很多关于比特币终止实验的问题。我会稍微把问题变一下——按计划，Bitcoin SV已经上线，你们认为可能会有最终版本吗？将来不会发布新的操作码（可能五年后，我们只是巩固基础协议并由此继续向前推进），或者你们大家会更赞同开放式的想法，认为我们可以在适当的测试下引入新的操作码。
史蒂夫：0:48:55.80,0:49:47.43
我认为你已经知道了我之前所说的关于理念差异的其中一个因素。我认为可以引入新函数就行了。话虽如此——是的，这样就有一个新的地方用于操作码，但这可能是一个有限的地方，在我看来，加密原始函数（例如CHECKSIG使用具有特定椭圆曲线的ECDSA，256位散列使用SHA256）在未来的某些时候，这些将不再像我们希望的那样安全，我们将在某些时候用不同的散列函数、验证函数替代它们，但我认为这还有很长的路要走。
丹尼尔：0:49:42.47,0:50:30.3
我希望看到更多数据。我希望看到证据证明这些东西是被需要的，我能想象的方式是，用完整的脚本语言实现了一些解决方案，并且我们发现这非常有用，而且在用年来衡量的一段时期内，我们会发现很多交易都在使用该功能，然后，也许我们应该考虑引入一个操作码来对其进行优化。但是，在我们甚至知道它是否有用之前进行优化，就是错误的方法。
史蒂夫：0:50:28.19,0:51:45.29
我认为优化实际上将成为挖矿人的经济决策。挖矿人的关注点是优化特定流程是否对他们更有意义 —— 这是否会降低他们的成本，以便让他们能够为其他人提供更好的服务？ 是的，所以最终这些决策将成为挖矿人的主要决策，而不是开发人员的决策。当然开发人员可以提供他们的意见 —— 我不期望每个挖矿人都成为脚本专家，但我们已经看到挖矿人们开始雇用他们自己的开发人员了。我不只是在谈论我们 —— 在中国还有其他挖矿人，我知道他们的员工中有一些非常聪明的人质疑并挑战所有的变更 —— 他们研究这些变更并编制自己的报告。实际上，我们很幸运地能够与其中一些人交谈并与他们进行了一些非常有趣的技术讨论。
康纳：0:51:39.47,0:52:18.70
我想问你们很多问题——我想知道你们对自私挖矿（Selfish Mining）的看法。nChain的首席科学家一直直言不讳，说自私挖矿是子虚乌有。Steve，我知道你有段时间曾经进行自私挖矿模拟。你对自私挖矿本身有什么看法——它是一种攻击载体吗，是捏造的吗，是真的吗？
史蒂夫：0:52:13.74,0:56:00.20
这是一个微妙的问题。所以，是的，我确实进行过模拟——实际上，就在几周前，我开始关闭并将所有数据交给其他人开始分析。我很高兴我把它关掉了，因为它让我在VPS上花了一大笔钱。该模拟是楔形测试网络上的一百个节点——这是一个稍微修改过的楔形测试，这些节点实际上都是你所知的真实节点挖矿——我没有完成对测试数据的全面分析，但去年年底，我进行了一个只有十名矿工的小测试，主要是因为我只是想在我开始在100个节点上花费大量资金之前证明这一切都有效。我得到的结果表明，你可以通过自私挖矿获得短期优势——远不及埃敏（Emin）的论文所预计的那样。造成这个结果的原因可能有很多——我尽我最大的努力让测试偏向自私挖矿的矿工。该模拟可能会偏向任何地方，我努力让其偏向于自私挖矿矿工。这需要比我更有统计专业知识的人来过滤掉所有的杂讯，并看看你是否需要重复任何这些测试，但是这些杂讯对我来说真的很明显，因为我不得不考虑所有这些偏向，所以我花了很多时间来解决这个问题。其实，阻止某人进行自私挖矿很容易，因为这很容易被发现。如果你想要扣留区块一段时间（从几分钟到30分钟到一小时），就会有明显的迹象。你不会进行在过去10分钟或20分钟出现在网络上的交易。如果你认为某人在自私挖矿，你可以自己开始对交易追根溯源，这样你就可以确切地知道这些是什么时候出现的。区块中的时间戳将被关闭。大多数矿工目前使用合理准确的时间戳。比特币协议通常允许大约两个小时的时间戳窗口，但目前人们往往使用相对准确的时间戳，所以一旦你意识到发生了自私挖矿，就很容易开始孤立自私矿工的区块。你可以检测到它们是哪些区块，如果你愿意，你可以手动作废。我觉得，如果30%的网络试图攻击其他70%的网络，那70%的网络不会做出响应是不可思议的——他们会很快做出响应，并且自私矿工需要相当长的时间才能获得任何优势。所以他们冒着巨大的风险，这些风险人们是不会注意到的，或者不会试图解决来进行响应。所以对我而言，现实是自私挖矿可能永远不会发生，如果有人想尝试，他将碰一鼻子灰。
科瑞：0:55:58.07,0:56:35.06
很多人正在将即将到来的11月分叉与以太坊（Ethereum）和以太坊经典（Ethereum Classic）硬分叉进行对比，可能出现一些不解，尤其是在运行不同节点软件的交易所中。我只是想了解在某些客户可能不兼容的情况下你建议交易所做什么，你们觉得11月将会进展到什么程度，而12月又会怎么样呢？
史蒂夫：0:56:33.83,0:58:19.03
我想我无法预测11月15日会发生什么，而且我相信没有任何人能预测的了。在过去，交易所在这样的事件中，我的意思是在某些竞争币上已经计划了硬分叉——例如，zcash经常会有硬分叉，交易所在这些期间通常暂停存款和取款——在一些地方还暂停交易。我认为大多数交易所可能会这样做，直到泥水清澈。在建议方面，我建议交易所准备好两个节点。大部分交易所可能都有ABC节点，一些交易所有SV节点。我建议交易所这两个节点各有一个。我还建议他们预备一个BU和一个XT节点。这不是与硬叉或11月15日真正相关的事情，这只是适用于任何依赖区块链的通用最佳实践，以便这些运行多种实现方式的企业可以快速切换。你知道结果会是什么，我的意思是任何人都可以猜到。只要交易所准备好，并且他们能够从一种实现方式切换到另一种实现方式，我认为他们就会没事。
康纳：0:58:17.56,0:58:40.72
我想我们快接近尾声了——你们真的很好地回答了分散在这儿的所有其他问题。我很想快速提一下并行化问题——你们稍微谈过这个问题，但是你们有没有即使用单个核心又通过并行软件进行过测试，以及你对未来发展有何看法？
丹尼尔：0:58:44.34,1:01:10.90
我们已就衡量客户端性能进行了测试，并研究了我们可以实现最大改进的地方。我们还关注了其他代码——所以我知道Bitcoin Unlimited最近进行了一些非常令人印象深刻的改进。我还没有真正测试过Bitcoin Unlimited的新版本，我很想抽时间试一试。当然，我们正在使用ABC代码分叉，而该代码中存在一些非常大的并行化问题。这些问题源于Core，你也知道，谁会在乎1 MB区块，对吧？但是，由于我们试图达到该容量，因此它们非常重要。C ++开发人员正在忙于解决，但要消除其中的一些问题还有很多工作要做。大部分代码都存在一个主锁，这导致，虽然可能有多个线程正在执行各种操作，但是它们都会卡在一个锁上，这会强迫它们全部都有效地进行单线程处理。存在某些并行化发挥作用的区域，但在这个与系统交易的主要流程中，需要对这个中央锁做很多工作，这就是我们现在正在做的工作。我们已经研究了一段时间了，但还没有做好发布的准备——这不是那种需要大量测试、大量审查的工作，而是发布时机还远未成熟，我们希望下一个版本能够准备好发布。
史蒂夫：1:01:09.28,1:03:12.80
当然，下一个版本不会是另一个硬分叉。期间我们会有一些子版本，可以加强性能。我认为值得将我们正在讨论的很系统的方法加到里面。我们正在进行几个并行的工作流。在这些工作流中，我们有几个开发人员通过在区块附加项挖矿收到内存池并在区块中对其进行验证，从点对点接口的接收中绘制出交易的生命周期。我们将所有这些都绘制出来，这样我们就可以准确地看到每个阶段相接的是什么，这样我们就可以将其完全分开，并且我们将这项工作作为初步练习正在进行，同时另一个开发人员也会处理一些微小的代码变更，这些变更将在短期内改善情况。一旦我们很好地完成绘制，那么nChain办公室的墙将被这些巨大的图表覆盖，因为这些图是综合性的，然后，我们将会处于一个非常好的位置，以便查看所有数据结构并说“好吧，这个与代码路径的这一部分相接，然后再与代码路径的这一部分，等等” 。因此将它们分开并对它们使用不同的锁是安全的，这对于这部分是不安全的等等。整个并行化问题是一个有趣的问题，因为它不仅应用于代码，它还应用于我们开发人员的进程。我们正在研究如何并行化开发，从而让其不会在一个路径中卡在单个开发人员后面，我认为在相当短的时间内我们已经做得非常好了。
史蒂夫：1:03:18.93,1:04:29.82
这实际上确实引到了另一点，即我们在Bitcoin SV中没有任何资源短缺。在这个项目上我们有相当多的开发人员。他们是绝对有经验的开发人员，我对他们能够在短时间内完成工作印象非常深刻，但是当我们解锁这些可以采取的额外并行开发路径时，我们就不再缺乏加入其中的人才。我们的进步速度可能会呈指数增长。在事情真正开始加速之前，在对我们的质检等内部流程进行整理时，总是有点像下注。我们现在开始在团队内部看到——进展的步伐确实在加快。
丹尼尔：1:04:23.13,1:06:07.98
因此，这里有不同类型的变更，我的意思是我们已经有了Bitcoin SV的路线图，指导我们的走向。我们已经面临着在容量面取得一些快速成就的压力，因此有些东西需要进行大量工作才能重写大部分的代码内容，或者至少进行改编，而且这些需要花费很长的时间。然后你就得到了我们需要的短暂收益，以便迅速提高网络容量，而达到这两方面需要合作并且能够很好地协同工作，同时没有任何一方在增加容量方面获得短期胜利，这种胜利对于我们想要的长期收益来说是错误的方向。让所有这些变更沿着相同的路径排列并进行一些快速改进，同时进行大规模的长期变更，这将真正地提高比特币的容量——天哪，这是一个很大的挑战，因为我们正在努力的需要我们牢记长远目标，但我们还需要进行一些短期的改进，这很有挑战性。
康纳：1:06:02.61,1:06:33.30
我们快结束了——谢谢你们的时间。如果我不尽可能多地问你们一些有趣的问题，那我就太失职了，所以我很想谈一下——Bitcoin ABC实际上正在继续延展性修复的问题。你们对交易延展性本身有什么看法，你们认为需要修复吗？
史蒂夫：1:06:29.13,1:06:39.20
我没听到过有人抱怨它
丹尼尔：1:06:33.30,1:06:42.27
我觉得不需要。
史蒂夫：1:06:39.20,1:08:12.06
延展性修复依靠改变交易ID的计算方式进行，基本上这意味着将签名从交易中排除，我认为这是一个广泛的变更。这需要非常仔细地研究，这有点讽刺，因为对于我们想要实现的任何变更，我们得到的大部分推脱都是“有什么用例？”， 而我的意思是使用像没有多次操作的脚本语言之类基本东西几乎是不费脑子的，但我没有看到任何人提出用例并说我们需要……我没有看到有任何企业说我们需要延展性修复，我们愿意容忍中断网络并不得不更新钱包等来完成修复。所以，如果一个企业过来说我们已经拥有了这个令人叹服的用例并且它将改变比特币的面貌，并且这是可信的，以及更可信地拯救闪电网络，那么也许你应该将其提上议程并进行讨论，但是我没有看到这些。
丹尼尔：1:08:08.91,1:08:34.59
所以对我来说ABC计划中有一些小的变更似乎是针对延展性的。我鼓励所有人都看一看这些变更——我自己还没有完成对它们的分析，但是我看没必要修复延展性。
史蒂夫：1:08:30.12,1:08:39.24
至少它不是优先事项。
丹尼尔：1:08:37.50,1:08:42.81
你可以在不修复延展性的情况下做出付款渠道。
史蒂夫：1:08:39.24,1:10:11.17
我们需要将时间和注意力上集中在更重要的事情上——主要是扩容。通过额外的API将支付处理生态系统支撑到节点中，从而让其可以查询事物并提高其零确认经验以及测量零确认风险等等。是的，这对我来说似乎并不是优先考虑事项。我们的核心优先事项，就是保持Bitcoin SV代码质量方面的安全等，确保不会出现漏洞。我们的另外两个核心优先事项是扩大规模和改善用户的即时交易体验。我认为，当我们这两个事项实现时，我们可以站在世界的前面说“你好，这个区块链在扩容时采取了与世界上所有其他几千块区块链截然不同的方法——我们不怕大型机器，我们不怕数据中心。顺便说一下，这么大的区块处理了十分钟前发生的一大堆交易，人们已经走出商店喝了十分钟的咖啡了” ——然后我想全世界都会注意到。
科瑞：1:10:13.23,1:10:25.46
你们认为我们距离达到这个目标有多远——即这种采用将会以显著的速度增长到我们需要扩容的程度？
史蒂夫：1:10:24.03,1:11:57.13
我想我在本次访谈开始时谈到了不同开发人员小组之间的互动，以及我认为一旦共识协议本身开始稳定下来，很快就能达到目标。当我们到达一个协议稳定的阶段，我们就可以把原本会浪费在非生产性对抗性互动上的大量时间和精力集中在重要事项上——例如扩容。BU已经针对这方面完成了一些优秀的工作，我希望他们继续。因此，取决于11月的结果，如果人们不再关注所有这些需要发生的共识变更——或者打引号的“需要发生的”，那么我认为开发人员的注意力会让你知道以后将集中在扩容和零确认上，我认为采用的速度会提升。我不能给你一个确切的日期，但我很期待看到我们明年年中会处于什么位置——从Bitcoin SV方面我很确信，从现在到明年6月之间我们将会取得很大的进展。
科瑞：1:11:52.36,1:11:59.29
我都等不及了
康纳：1:11:57.13,1:12:41.02
非常好。我想在我们结束之前，我希望解决的最后一个问题是——任何可能会说“哦，他们没有问我的问题”的人——我想很多人会把你们与矿工混为一谈。很多这些问题都假设你们个人会有51%的攻击事件以及类似事件，所以毫无疑问，他们两位不是矿工。我想很多人都不理解这一点。有人指责说这将是一个太简易温和的访谈，所以现在我们被迫在这里提出这个问题，因为有一个用户特别着迷于你们的nChain首席科学家
史蒂夫：1:12:37.00,1:12:42.79
所以让我猜猜——是Contrarian__
康纳：1:12:41.02,1:13:03.10
是的——我认为他的名字可能是Greg，但我不确定。问题是，因为你们的客户端声称实现了中本聪的愿景，你们个人是否认为克雷格·怀特（Craig Wright）是或曾经是中本聪的主要部分吗？
史蒂夫：1:12:59.47,1:14:01.69
为此，我有一个全面忽视Contrarian__的政策，因为我通常会试图表现得更圆滑一些，但我的意思是他显然是一个找茬的笨蛋。关于我是否相信克雷格·怀特是中本聪的问题——他是不是对我来说无关紧要。我一直在想这个问题，如果我得到了加密证明，我想我可能会说他不是，因为你知道这只是从根本上改变了一些东西而且这真的无所谓。克雷格是一个有趣的人——实际上我享受与他一起工作。我发现他有时会易怒，你知道的，我们有分歧，有时候会因此而争吵，然后事后我们会给对方一个拥抱，一切都很好。但总的来说，我很喜欢和他一起工作。这才是最重要的。
丹尼尔：1:13:59.21,1:14:20.12
我同意这一点。我的意思是当我加入nChain时，我必须得考虑这一点。你知道，归根结底，他是不是都无所谓。我喜欢和他一起工作，这是一个很棒的工作场所。
康纳：1:14:17.80,1:14:33.25
非常好。那么，非常感谢你们为我们解答。我想很多人会学到很多东西——我觉得我学到了一些东西，因此我们非常感谢你的时间，谢谢你们。
史蒂夫：1:14:30.25,1:14:33.25
这是我的荣幸
