btcc COO Samson Mow:
各位中国矿工,矿主,交易所老总:
这封邮件的目的是想通过协商达成一个共识。
对现在情况的一些总结:
1)绝大多数矿工们并不赞同一个有争议的硬分叉。
2)Core 同意开始讨论硬分叉因该做些什么和因该何时才能安全地实施硬分叉。
3)我们都认为我们必须尽快地平息市场的动荡和恢复对比特币的信心。
4)我们都同意下一步是让商界领袖起草一封呼吁书,请大家等待一段时间,让Core拟定一个硬分叉的方案。在此之间不要支持硬分叉的启动。谢谢大家的理解。
5)Core 会在几个星期之后发表一个声明来阐明他们的计划。如有任何问题,请与我联系。
bitpay首席执行官Stephen Pair:
分叉从定义上来讲不能存在争议(特别是要求获得绝对多数的同意)。我强烈建议部署分叉所需的代码,以允许比特币区块扩容到2MB(无论你运行的是哪一个分支)。除非大多数矿工都是支持的,硬分叉实际上是不会发生的(这种情况下,这种分叉就不会存在什么争议)。将这样的分叉代码编入到比特币软件项目中,开发者们既不支持,也不会反对…他们不能强迫矿工激活这样的分叉,也无法阻止。如果实施一段时间后,分叉还是没有激活,那就作失效处理(如果需要的话,时间到期后代码可完全删除)。
一般来说,如果你能确定社区支持某种分叉(硬或者软),并且项目团队没有任何的技术缺陷,那我的意见是,激活这种分叉的代码就应该放入到项目当中。然后让矿工们来决定是否要激活这种分叉。而矿工们应该听取客户的需求,以及任何技术上的争论,无论是赞成的还是反对的。
同时我也认为,矿池在修改共识代码中发挥的作用也越来越重要。我认为,负责任的矿池运营者应当学习和考虑任何的分叉提议。他们应该对这些建议进行评估,并给矿工们提出建议,告诉他们是否应该支持某个方案。然后,矿工们来决定是否要借出他们的算力来激活这一分叉。
smartwallet Dino Mark A:
当前最主要的争议,就是“多数共识”的定义是什么。从我和不同利益相关者之间的对话来看,大多数人认为75%的阈值是一个有争议的分叉。
关于矿池这点建议,我是赞同的,他们应该允许矿工设立一个标志,来对分叉进行选择。
对于是否选择一个特定的分叉,这是一个好主意,这应该是在行业峰会上谈论的话题,所有的利益相关方(开发者、交易所、矿工、钱包提供商、咨询公司,风险投资公司等等),他们可以提供反馈、研究和提案,并尝试基于冷静和理性的技术/经济讨论,来达成共识。
当前形势下,我们仅仅有少数开发人员在维护一个分支(据我所知Jeff和Gavin只是在提供建议),这与其他数百位开发者站到了对立面,然后一些人在暗中游说矿工采取这个分叉,对于比特币这个项目的长期健康而言,这是不利的。迄今为止,中国矿工们和core开发者之间,还没有开放的沟通渠道,结果是,他们没有足够的信息来做出明智的决定。
我相信,只要这样的事情继续发生,我们会继续看到坏消息以及市场的不确定性。
bitpay首席执行官 Stephen Pair:
我觉得你对Jeff 和Gavin反对数百名开发人员的意见的看法,是错误的。大多数你看到的业余比特币爱好者们,他们都喜欢在社交媒体上畅所欲言,但仅有少部分人是见多识广的。也有很多非常有才华的专业比特币开发者们,他们并不喜欢在社交媒体上浪费他们的时间。
你需要让区块进行扩容(但要谨慎和适度),这样我们就会感觉到可扩展性限制的一些痛苦,随着不断增长的用户群,我们就创造了经济激励来改善可扩展性。
我并没有听过有哪位工程师说,如果比特币区块扩容到2MB,比特币就会倒下,甚至是死亡。
我认为让Bitcoin Core开发者登船会是一个很好的尝试,但我对此能够发生的可能性表示怀疑。
smartwallet Dino Mark A:
澄清一点,我所说的数十位签署了(Bitcoin Core)可扩展性路线图的开发者,以及数百位Bitcoin Core贡献者,除了jtoomin之外,没有人在维护Classic这个分叉(据我所知)。很明显的是,绝大多数优秀的开发者并不同意Classic的方式。
没有人认为比特币扩容到2MB会死,这点我同意,事实上每一位开发者都认为,我们需要更大的区块(包括core!)。眼下的问题是,怎样进行一次硬分叉才是最安全的方式,为了确保安全,我们需要做什么事,时间轴又会是怎样的。
我支持Gavin的BIP(比特币改进提议)…这个过程,时限和阈值是健全的。激活分叉的阈值必须足够高,那么就不会出现反转的风险…它也必须是足够低的,使得不能让一个小分支拥有否决分叉的权力。
Classic/XT这类分支的出现是不受欢迎的;一些开发者有着分歧,他们试图尝试一个政治上有争议的硬分叉,然后我们在信息不充分的情况下,在 reddit等社交媒体上进行了内战。
我不确信你能够从中幸免。替代型项目是好事,也应该鼓励。你永远不会知道的是,其中有一些项目可能会比Bitcoin Core拥有更好的结构和领导。我想看到的是,项目会采用工程学思维,而不是计算机思维。
我不担心Bitcoin Core项目正在做太多实验性很强的东西。例如隔离验证(segregated witness)应该不用放入到可扩展性和区块扩容的争论当中。这是一个好主意(主要是因为它可以解决延展性的问题),但它也是一种侵入性和风险性较大的改变。这需要对现有的软件进行大量的修改(不只是Bitcoin Core)。这不应该操之过急,但现在看来它似乎只是为了用来避免一次硬分叉。我认为这是core开发者存在的,计算机思维压倒工程学思维的一种症状。
另一个我在社区中听到的声音是…我们听到很多不认识的,随机的人试图鼓励BitPay进行站队,站到Bitcoin Core的对立面,并且是激励地表达这种意见的。他们似乎是故意在创造不和谐。这些人或商议试图破坏比特币,或者他们只是我们需要去忽略的有毒性的人。作为一个社区,我们需要弄清楚如何保护自己免受有毒人物的伤害……这让我想起了有关该话题的一次谈话(我建议大家可以看看):
https://www.youtube.com/watch?v=Q52kFL8zVoM
我们应该冷静下来,然后想出正式的机制,应对未来的硬分叉(HF)升级,以避免这样的事情再次发生。如果每一次比特币升级都要出现这样的硬分叉争斗,或者更糟的情况下,一个有争议的硬分叉导致 BTC在一个坏链中迷失,金融市场对于比特币作为一种可行的/稳定的长期持有资产,将很难会有信心。
如果这样的改变是很容易的,我会更担心比特币。虽然我同意你的看法,我们应该尝试冷静下来。我们确实需要累积经验,在管理分叉问题上变得精通(无论是软分叉还是硬分叉)。这对于比特币的未来而言是非常重要的。如果社区变得熟练,它会减少很多的张力,即使是对有争议的改变。
Bitfury CIO Alex Petrov:
Stephen ,如果你对声明的意见是一致的,没什么不同看法的话。你随时都可以在上面签名。
btcc Samson Mow:
@Stephen 感谢您抽出时间来看这封信!欢迎您代表个人来签名。将有很多矿工会支持它,而且还包括交易所和钱包。我们都是其中的一部分。要么我们可以发送一个统一的信息,要求开发者一起参与进来,要么我们会继续观看Classic的戏剧,然后是下一场戏。
我还将 Charlie Lee添加到了邮件讨论当中,并邀请他来考虑签署该声明。
coinbase 首席执行官 Brian Armstrong:
我同意Stephen,70%+的分叉是“有争议”的,这是没有办法的。只要是能扩容到2MB,并且代码也能写好,运行这样的分叉我都是ok的。我对哪只开发团队并没有什么偏爱。眼下,Classic似乎是最接近这样做的,并且他们的分叉代码是由两位强大的core 开发者编写和审查的(Gavin 和Garzik)。
Samson,我相信你可能是对支持Classic的矿工产生误解了。他们最近走访了一些矿工,声称得到了Bitmain、Slush、KNC等其他厂商的支持。你可能会掌握一些我没有掌握的信息,但我认为说大多数矿工都不会支持这一点,这是不准确的。现在我们还是未知的。
我也不认为另一封公开信会产生多大的影响。Core可以做出他们想要建立什么的决定,我们也可以选择我们要运行什么的决定。如果有其他好的选择,我们没有理由要试图说服他们。
btcc Samson Mow:
@Brian 隔离验证几乎可以实现2MB扩容的效果,它也是最安全,最快可用的。请记住,我是站在硬分叉(HF)先于隔离验证(SW)一方的,但在这里,我们需要采用隔离验证。关于矿工,我掌握的信息是相对准确的:)
@Sam ,你说你想要一个明确的期限,你想要说些什么么?
KNC Sam Cole :
所有人。
我们正在试图说服的大多数开发者,此前从未会听取这种类型的方法。我担心的是,两个星期的时间无法改变他们的想法,我们只是在一次又一次地做着同样的事情,只是期盼能有一个不一样的结果。
所以,我是希望这次是能成功的,但我不认为它会有什么改变。所以,我们作为一家公司,会推动classic。如果core坚决不听,它会给你所有指向的东西。
我只是认为,区块扩容的争论已经进行了1年的时间,现在是时候承认我们需要去尝试一些不一样的东西了。
至于隔离验证的软分叉,它实际需要的代码并没有那么简单。
bitfury Alex Petrov:
你好,Sam,我们明白你的意思,我们也尊重你的选择。
你可以对我们的声明签字,也可以选择不签。
我们已经和双方的开发者进行了沟通。Core团队改善了他们的沟通,并表示愿意合作。(诚实地说,是classic在帮助改善core)。
只有我们进行谈话,我们才能准备好解决问题。这是比特币历史上,我们第一次面临“危机”,我们应该妥善地通过协商来解决它。我们正在寻找最佳的、风险较低的解决方案。但没有办法,社区再次分裂了,并持续进行了争斗…这意味着比特币社区和市场更多的不稳定。
现在的争斗已经够多了,但它们并没有任何的帮助。
任何(争议的)硬分叉不仅仅是会造成一个分裂,如果我们实施不当,不及时协调,这可能会创建两个单独版本的区块链。
这会伴随着比特币用户的流失(包括敏感的金融损失)。我们权衡了所有可能的设想,也考虑了最坏情况下的风险会是怎样的,将会有超过50位core开发者可能会离开这个项目。我们的目标是找到共识,并执行协调好的软分叉/硬分叉。
我们相信我们可以创造多赢的局面,而不是不稳定。
在投票之后,我们应该团结在一个版本,这是更为民主的方式。
我们也同意审阅任何未来的硬分叉,并避免额外的硬分叉的发生。
为了恢复比特币市场的稳定性,我们必须迅速采取集体行动,来阻止这一趋势。我们已经开过了会议,讨论过如何解决这一僵局,试图找到一个更为平衡的解决方案,并推动进步。
目前我们迫切需要的是一个具有包容性的路线图,它需要考虑到企业和社区的需求,并降低未来市场的不确定性。
比特币是强大的,并且变革性的,我们将走在一起,确保其未来是光明的。
KnC:Sam Cole
我完全赞成妥协。
所以,我能做的就是在两个星期内,不会部署classic节点或挖取任何classic区块。让我们再给他们一次机会。我会在这封信上签名,我会同意在两个星期内闭上我的嘴,不为 classic或者任何其他分叉进行游说。
在那之后,我认为我们需要对他们强硬一点,直到他们放弃,或者我们把比特币和他们分离开来,这个列表上的每一个人都不仅仅希望比特币能够存活下去。而且我觉得,和现在的core团队在一起,我们除了生存模式以外,什么都没有。
房子干净往往会是一件好事。
bitfury Alex Petrov:
Stephen,我们明白你的意思,不过看起来你有点偏题了。
我们在这里讨论,是希望能够找到共赢的共识,而不是要闹任何的分裂,我们正在寻找并探讨很多找到共识的方法。
Core在2015年12月份测试了隔离验证,并完成了大部分测试。他们还计划公布更多的功能。
当然,隔离验证并不是最终的解决方案,但它允许的扩容效果最多能够达到4Mb。
1.core同样可以在短期内做一次2Mb的硬分叉,并且可能是更专业一点的。
2.classic是在2016年3月1日, core是在2016年4月1日公布,并且在2015年10月份就已经预先计划了(所以,你觉得1个月能够起到很大的作用,而classic的“非常快速和简单的测试”是适当的决定)
3. 我们已经执行了core、classic等等20多种不同的技术源代码,这不仅仅是我们的偏好选择。
4.选择“classic”可能意味着永远失去50-150位core开发者。classic采用了core 99.95%的源代码,这不是什么好的选择。
5.当我们能够正式预案硬分叉时,甚至双方可能会结合起来,或者classic会合并到core开发团队。为了避免社区会产生误会,我们同意下有关日期,并公布于众。将区块链分裂成两条链的行为,其风险性还是过高了,它会有损于比特币。
6.当然,core也不是完美的,他们也存在着问题,比如公共和沟通上的问题,他们没有做到透明交付等等。附:请大家也查看下classic的diff/pulls,有大量的代码并不是出自Gavin/Jeff之手。
硬分叉也是有风险的,因为在开发角度上来看,Gavin+Garzik+Toomim是无法和300位开发者相比的。
当然,请不要将我的短文看作是对core或者 classic的偏好。
我们支持的是平衡和客观的解决方案,其风险性是较少的,并且是最有效的。
现在,我们应该聚在一起做一个最后的声明,这在之前已经有了很多的讨论,本周也应该把这个声明公布出来,为社区和市场提供清晰性和稳定性。所有负面的斗争和负面的帖子,都带来了不好的影响。
你可以对这个声明进行签名,或者选择不签,这是你的决定。
bitpay首席执行官 Stephen Pair:
Samson说隔离验证是一个更安全的方案。我并不认同这个观点,隔离验证是一个非常危险的改变,它需要进行大量的代码更改,虽然它可能是一个好主意,但它需要时间 ,我期望隔离验证需要一整年或者两年的时间来部署。
比特币可以也将会扩展,甚至它会超过传统支付网络的容量。它也不会损害系统的去中心化的完整性。在BitPay,我们会选择在扩展性方面,对未来最有希望的分支,因为我们相信任何其他的分叉将黯然失色,最终将会消亡。它是基于一个很简单的经济学预测。最低费用又提供最多性能的分叉将会获胜。
当务之急是挖矿社区要弄清楚如何向前推进,你们已经投入了大量的精力和财力,来维护比特币区块链的安全性。你需要采取措施来确保这条链,并让这个挖矿算法继续生存下去。你的用户放弃你,去选择一个新挖矿算法的分支,这是完全有可能的。另外,一些在比特币上投入很少的人,可能会受益于比特币的崩盘或系统的重启,而不是尝试去保护它。
bitpay Stephen Pair :
对于这封公开信,我觉得是好的,但我并不想签名 。我对此非常赞赏,并感谢你们的努力。虽然我觉得你们在夸大(core)项目的开发者参与人数(记住,我从2010年开始就一直非常密切地参与比特币),我真的希望你们的说服努力会是成功的。
smartwallet Dino Mark A:
Brian、Stephen以及其他交易运营商。
我很好奇,你们当中有谁假设过这样的一个场景:当一个主要的矿池或矿工在最后一分钟改变他们的主意,运行了一个分叉时会有什么风险?假设其中75%的算力投票Classic成功,但在28天的宽限期内,某些矿工改变了他们的主意,然后继续运行core。当触发块时,出乎所有人的意料,我们出现了50/50的分裂情况。现在,Coinbase接受了Classic分叉上的BTC,为客户支付了美元,如果这个分叉失败了,那Coinbase就被这种没有价值的BTC给套牢了。这种情况同样适用于其他交易所/支付处理器。
没有矿工和矿池签署了一项具有法律约束力的协议,他们会持续在一个特定的分叉中挖矿么?从法律法规的角度来看,谁来对支付处理器、交易所以及商家的潜在损失负责呢?难道特定的矿工群体需要对此负责么?
我提出这些问题,是因为行业中还没有一个开放的论坛,能够对各种扩容方法的利与弊进行集体评审。所有我看到的就是一种深深的分裂(见Barry Silbert的推文 https://twitter.com/barrysilbert/status/694911989701861376 and this http://bitcoinocracy.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground) ,什么是安全的,什么又是不安全的。是的,如果我们迟迟不去扩容,它会伤害到用户的增长。然而,如果我们继续向分叉前进,将导致金钱的损失,我们知不知道它会对比特币的品牌造成长期的损害?
是否大家都习惯于斗争,看看谁能赢下这场战斗?这会对更广泛的金融市场打来什么样的信号?有哪种基金会愿意持有一个在每一次升级过程中都是不确定性的加密资产?更糟糕的是,coinmarketcap上面我们已经看到了正在升起的竞争者,它们具有更加平滑的开发过程,包括提前预制的硬分叉。它们有更高级多脚本语言,称为solidity,能让开发者轻而易举地开发智能合约。而比特币则陷于笨重的操作码,其中大部分是被禁止的。在这里,我们争吵2MB的区块大小,以及更多我们要去担心的问题。而竞争者只是在旁观然后从中吸取经验。我们缺少大局观。
作为一名创始人,我明白用户和快速扩展的重要性,并且我也知道,VC对公司的压力。在另一方面,如果CNBC头条新闻是“比特币因为硬分叉升级后,交易所遭受损失后”,我们会集体中毒,我的投资者也会遭受损失。
我支持2MB硬分叉,我们需要它。如果Core在合理的时间内没有推出可扩展性的解决方案,我会切换到一个安全的替代方案。但是,作为一个行业,我们在选择另一条道路前,我们是不是应该采取一个深思熟虑的数据驱动方法。
coinbase 首席执行官 Brian Armstrong:
Philip会尽量解释这个问题。如果你有3-4个不同的节点都是用的同一个协议,它们可以单独或组队进行升级。如果达到一定的阈值(70%?),那么网络会进行升级(任何不支持它的节点,都急于去切换到这个网络,或者他们的客户会进行切换)。因此,如果你有一组不同的节点,协议的升级和共识规则仍然是有效的,这类似于Web浏览器和web标准。希望这能提供一点帮助。
Dino,我不认为你所写的东西是可能发生的。少数分支(不管它有30%或者49%),它能够持续的时间我认为不会超过几个小时。矿工的风险在于,如果你挖的不是最长的链,那么你会失去这25个BTC。所以,矿工会很快逃离失败的链(50/50分裂就像是一个不稳定的分子,其中有50%的矿工的收入会是零,他们会急切地猜测哪一方会赢,那么他们就会加入对方)。
btcc Samson Mow:
在接下来的两周内,我们需要Bitcoin Core开发者和我们携手合作,除了隔离验证(SegWit)之外,明确在扩展路线图当中加入一次未来的硬分叉。直到我们找到最好的前进道路之前,我们不会在产品系统上运行一个Classic节点,或在Classic节点上挖取任何区块。我们请大家要理性行事,暂缓作出运行一个争议硬分叉的决定(Classic/XT或者任何其他的版本)。如果Bitcoin Core仍不同意以这种方式进行扩容,以未来12个月为激活日期,我们很可能需要寻找新的领导团队来实现硬分叉。
声明:此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。本网站所提供的信息,只供参考之用。