动不动喊“矿难来了”的人,可能根本不懂比特币挖矿
文 | Odaily星球日报 & Poolin币印矿池, 查看原文
作者 | 黄雪姣
作为长期跟踪矿业的记者,我发现很多人在行情极端、行业动荡时,喜欢发表一些对比特币挖矿的看法和推论,引起投资者的传播和恐慌。
但实际上,这当中有相当一部分是通过错误的概念推导而来。很多自以为了解挖矿原理、或和矿业有过接触的人,对挖矿的一些基本概念实则一知半解,甚至存在误区。
譬如,在 BTC 大暴跌的 3 月 12 日,比特币网络长达 1 个小时没出块,不少人(包括我以及个别矿圈朋友)还以为是矿机关机、算力暴跌所致,由此担忧“矿难”是不是已经在路上了。
但其实,网络长时间未出块在之前也常有发生,这单纯是巧合之下的运气问题,1 个小时内没有矿机碰撞出(符合难度)的哈希结果。
类似的例子还有很多,从矿工到持币者,因为对诸多数据的意义理解不当,做了很多过度解读,甚至歪曲解读,如果以此指导交易,显然风险很大。在专业人士看来,这完全可以避免。
因此,Odaily星球日报联合 Poolin币印矿池,为大家精心整理了一份重要却又常被误解的挖矿“冷知识”,快来看看你知道几个。
“全网算力难度”是一个真实的数据吗?
3 月 18 日上午,距比特币大暴跌过去的第 4 天,大家都在惧怕“矿难”到来。
一则“比特币算力本月下降约 40%,跌破百E”的新闻吓到不少人。
统计者是圈内知名数据分析机构、推特大V Skew Markets,采用的数据源是专业数据网站 BitinfoCharts,看起来应该没什么差池了。但“行家”一看便知这个数据非常离谱。
Skew 官推
返回去看数据源 BitinfoCharts,将月内算力高点(133.29)和低点(95.96)一减一除,得到月内最高跌幅为 28%,所以,40% 这一数字可谓“谬之千里”。
如果说 Skew 没有计算错误,得出本月比特币大跌 28% 的结论,那能代表真实情况吗?换句话说,“某日的全网算力”是可信数据吗?
事实就是——不能信,因为这个“全网算力”是公式推导而来的,是一个理论值,并不是实时监测的数据。
行业中通常使用“难度计算公式”如下:
实际上,网络中对于全网运行着多少矿机并无记录,矿工们也找不到什么权威的统计办法。
根据公式,出块时间的长短,决定了区块浏览器所显示的理论算力。但我们要知道,比特币的哈希碰撞出块本就是个概率学的问题,同样的算力可能 3 分钟就碰撞出结果,也可能半个小时才碰到。因此,短期的理论算力,并不能代表实际的算力增减。
譬如,正常每天应产出 144 个区块,而实际上一天内的出块数量小于 144 个,到底是不是算力快速下降所致,这就需要拉长时间纬度来看。如长期看每天的出块都在减少,我们才能进一步确定是算力下降的缘故。
但人们瞬间决策不可能依赖 1 个月前甚至半年前的数据。因此,矿业从业者普遍取近7日算力均值作为某一时间段的算力表示,兼顾了准确和效率。
了解了这些,再看到比特币算力日内“骤降”、“闪崩”等标题文章时,你自会一笑置之。
比特币算力“被暴跌”了太多次
难度调整周期不是14天一次吗?为啥还能延长?
3 月 12 日晚,就比特币大暴跌对矿业的影响,币印创始人潘志彪大胆推测:目前距离下次难度调整还有 11 天,但是,如果这期间算力下跌了30%,难度调整周期就会向后 5 天,变成 16 天。所以矿工必须搞出至少半个月的现金流(以等全网难度下降到适合挖掘的水平)。
很多人看到这儿可能会疑惑,大家都知道比特币是 14 天调整一次难度,怎么还能延期?
原因其实也简单。比特币网络调整难度的目的,是为了调整出块的速度保持在平均 10 分钟 1 个块,每 2016 个块作为一个周期调整。
我们所熟知的 14 天一调整,是建立在短期内全网算力较为平稳、出块时间为 10 分钟变化不大的基础上。
如上所述,倘若挖矿算力真的快速下跌、矿机计算能力不足以在平均时间内找到目标哈希值,那么出块时间也将延长,进而影响到难度调整的周期。
已经跌破某些矿机关机价,为何算力也没下降?
想了解这个问题,我们需要知道关机币价是怎么算出来的。
关机价指的是,币价下跌到某款矿机的收入=成本(也即净收入为 0)时的点位。
币价低于该点位,用该款矿机挖矿将无利可图。因此,从经济学的角度看,多数矿工应在该点位暂时关机、观望后市。
3 月 12-13 日的大暴跌,迅速地击穿了诸多老矿机的关机价,而 45-65W/T 的高性能新代矿机也在以几毛钱到几块钱的微利在运作。
但我们观察到,数日来比特币的算力并未大幅下降。据多位业内资深人士估算,在 2019 年底的百E 算力中,有 50E 来自 15TH/s 级别的老矿机,很显然,这些矿机直到现在也未全部下架。
矿工都在亏本挖矿吗?
从关机价的计算公式看,当“矿机的收入-成本(主要是电费)=0”时即应该停止挖矿。在同一时间同一币价下,不同的电费成本将影响到关机价的高低。电费成本越低的矿工,其越能承受币价下跌,也即关机价更低。
因此,当我们说跌破关机价时,用的是行业普遍的电费水平,但不排除那些拥有便宜电费资源的矿工仍能运行老矿机。
倘若以 0.24 元/kWh 的电价和 5000 美元的币价计,今天蚂蚁S9 开机尚有几毛钱的收益。
即使矿工有心关机,实操起来也不会那么容易。举个例子,很多矿场已向有关部门申报过用电量,因此不便突然关停。对于无法支撑电费的客户,双方很可能选择把机器暂时租借给矿场来继续运行。对于矿场主来说,他们的电力成本会比客户便宜很多,运行老矿机不一定会亏本。
同时,朋友圈里许多人喜欢发表“BTC 价格跌到 xxxx,S9 就就会都被挤出去”的言论,这也是一个非常经不起推敲的说法。上文说到,S9 级别的老矿机仍然占到全网算力近一半,这些矿机如果关机,所谓的“关机价”也会大幅下降,那么大家就都不会轻易关机,这成了“囚徒困境”。在实际情况中,老矿机并没有那么容易全部停挖。
此外,如今也有许多矿工会选择使用金融工具,撑过行业下行阶段。短时跌破“关机价”真的并不一定影响算力。
像打游戏和抢红包,挖矿也能开外挂,很多矿机都在开
2018 年底,矿圈对一项名为 Asicboost 的挖矿优化算法的讨论一度非常热烈。优化算法,顾名思义,就是能提高挖矿效率。
根据 Rawpool 矿池的测算数据,在固件中添加这一算法的矿机,降耗能达到12.5%以上。降耗的逻辑是,利用区块数据格式的特性,巧妙地降低了矿机接受数据的次数,从而降低了运行功耗。
根据公开资料,Asicboost 最早在 2015 年被两位研究者——Timo Hanke 和 Sergio Lerner 提出并陆续申请专利。可能是受限于专利,这项技术在早期并未得到大规模使用。
直至 2018 年 10 月,当时正值币价下行,多款矿机濒临关机,于是,比特大陆率先宣布要在蚂蚁S9、T9+ 等矿机型号中添加 Asicboost。
消息一经发布,各大矿池紧随其后,宣布自己“兼容 AsicBoost 挖矿”。
数据来自:Asicboost.dance
根据 Asicboost.dance 网站的最新数据,Asicboost 的使用率从那以后节节攀升,从渗透率不足 5% 上升到现在的接近 70%,即全网近 3/4 的矿机都在“开外挂”。
交易拥堵,矿池能对某笔交易定向加速?
3 月 12 日、13 日的大暴跌,让很多来不及补仓的合约用户爆仓,同时,这也是对比特币网络交易速度的又一次大考。数据显示,12 日-14 日,比特币未确认交易总笔数呈暴涨之势。
图片来自:Johoe's Bitcoin Mempool Statistics
基本上,这种情况基本每逢行情就会来一回。
此时,若不想自己的交易被堵住太久,用户唯有提高手续费,来增加被矿工优先打包的概率。当然,速度也并不能得到保证。
其实,直接给矿池“递小费”也能加速这个过程。
目前,不少矿池都已推出“交易加速”服务。购买该服务的用户,矿池将率先把其发起的交易放到下一次出块打包交易的队列里。如下个区块顺利由该矿池出块,就可以使该笔交易立刻到账,如矿池没有成功的发现下一个区块,则会向该笔交易增加手续费,使得其他矿池也优先打包该笔交易,从而完成交易加速。
据了解,购买该服务的用户,平均交易到账时间为 25 分钟,和链上不拥堵时普通交易所需时间相当。在交易量暴涨、网络拥堵时,这项服务也算提供了多一种选择。
以上这些“冷知识”,你都了解了吗?再看到谁妄加评论挖矿,纸上谈挖矿,发表一些经不起推敲的言论,不要忘记这篇文章转给他!
Crypto Billionaire Justin Sun Set for Space Flight? Blue Origin’s Tweet Sparks Buzz
The post Crypto Billionaire Justin Sun Set for Space Flight? Blue Origin’s Tweet Sparks Buzz appeare...
No Room For Doubt: Analyst’s $900K Bitcoin Forecast Follows Familiar Script
Bitcoin’s price slipped to $105,235 today, dropping 1.5% over the past 24 hours and falling 4.2% in ...
IRS vs. Coinbase: Supreme Court Asked to Reject Crypto Privacy Challenge
The post IRS vs. Coinbase: Supreme Court Asked to Reject Crypto Privacy Challenge appeared first on ...