BRC:BRC-20 等致网络拥堵 比特币开发者们怎么看?

Inscription和BRC-20的火热所导致的比特币网络拥堵手续费高昂这一事宜已经在比特币开发者社区中有所讨论。

5月8日,比特币核心开发者AliSherief在比特币开发邮件列表中发起讨论,表示面对这类“无价值”的交易,比特币开发者是否应该采取行动,并给出了一种可选方案,即“引入一个运行时选项来立即删除所有非标准的Taproot事务”。

目前,已经有众多开发者参与到讨论当中,少数人认为得直接审查这类交易,有些人认为这就是系统运作的方式,无需干预,也有建议进行适当调整或者引流至L2等观点,吴说整理如下:

AliSherief:“最近由于诸如BRC-20之类的项目占据了大量交易量,导致真正的比特币交易价格过高,从而引发了比特币交易池的大规模拥堵,这种情况自2017年12月以来很少见。这些几乎毫无价值的代币威胁到了比特币网络作为点对点数字货币的正常使用。如果未来几周交易量不降下来,是否应该采取措施?比特币网络是开发者、矿工和用户三方结构,而矿工往往是导致系统被滥用的主体,因此目前比特币交易的和谐受到了干扰。我们应该考虑采取行动,以缩小BIP342中的漏洞,并通过BIP和比特币核心代码库的提交来实现这一目标。另一种替代方案是在节点级别实施“审查”,并引入运行时选项以立即清除所有非标准的Taproot交易,这种方案更容易实现,但需要至少下一次发布才能推出。我们需要为所有人寻找一种解决方案,虽然有些人会有批评意见,但我们有责任确保这种拥堵不会再次发生。”

OKX发布BRC-30提案,引入存款、铸造和提取等权益操作功能:6月1日消息,OKX 官网发布 BRC-30 提案,它是 BRC-20 协议的增强版本,采用了 BRC-20 的设计原则,并引入存款、铸造和提取等权益操作功能,旨在为比特币网络引入一种针对 BRC-20 代币和比特币的质押机制。用户可以抵押他们自己的 BRC-20 代币和比特币,并获得相应的 BRC-30 代币作为回报。

此外 OKX 官推发文明天见并配图BRC-?0,明天见。[2023/6/1 11:52:01]

链接:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021620.html

MichaelFolkson:“矿工在区块中包含手续费高、符合共识规则的交易。如果用户不喜欢矿工所包含的交易,有两个理论上的选择:共识规则变更或政策变更。前者需要软分叉,难以实现且效果有限;后者无需共识规则变更,但仍有可能绕过P2P网络直接提交交易给矿工。BIP342的设计决策有其技术原因,不能简单地划分数据为有用和无用。政策或共识规则的变更是不可行的。交易的可用性与使用Taproot还是Pre-Taproot地址无关,与有限的区块空间和市场需求有关。盲目的政策或共识规则调整可能会适得其反。”

Michael Saylor:BRC-20部分用例可能是“非法的”,但反对审查Ordinal交易:5月23日消息,MicroStrategy 联合创始人兼执行主席 Michael Saylor 在接受采访时表示,如果 BRC-20 Token 被视为发行未注册证券的可替代 Token,就会有很多人反对,因为这是不道德且非法的。你不能责怪社区反对这一点。然而,如果它们以道德和法律的方式发布和监管,就没有问题,这一切都归结为用例和感知。

Saylor举例解释如果用 BRC-20 来 Token 化纳斯达克交易的所有股票和 ETF,这样个人就可以亲自保管他们的股票,而不是把它们锁在一个集中的托管人那里。如果以这种方式呈现,那么比特币爱好者会喜欢它的。

不过,Saylor 反对审查比特币网络上的 Ordinal 交易,他表示,最好让自由市场发挥作用,人们应该投资于他们相信的东西,可以自由地批评他们认为愚蠢的东西,但不应该审查它们。[2023/5/23 15:20:15]

链接:

BitKeep钱包已上线BRC-20 Ranking:5月15日消息,Web3多链钱包BitKeep现已推出BRC-20 Ranking,实时更新BRC-20代币价格变动、24小时涨跌幅、持有人数和交易量等信息,降低移动端用户参与比特币生态的门槛。目前已收录前100名流行的BRC-20代币数据。

据CoinTelegraph采访报道,BitKeep本月将全面接入比特币生态,帮助用户在移动端和浏览器插件使用BTC Taproot地址格式,并支持BRC-20代币及比特币NFT的充提管理、转账交易等操作;同时,BitKeep一直在持续关注BRC21等新协议,根据市场趋势和用户需求,提供更多样化的支持与服务。[2023/5/15 15:04:01]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021625.html

公告 | 贝尔链OASIS平台第8期销毁131.86万枚BRC:据官方最新消息,为配合Baer Chain生态的长远稳定发展,根据OASIS平台运营规划,每周平台所有游戏总充值BRC的10%将进行永久性销毁。本周OASIS平台共销毁1318624枚BRC,目前销毁已完成。销毁地址见原文链接。[2020/1/13]

ErikAronesty:“比特币的主要目标可能只能是货币用例,而不是成为全球所有事物的总账本。可以为非经济交易提供一个永久的激励机制,让其保持在链下。”

链接:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021635.html

LukeDashjr:“早在几个月前就应该采取行动。自比特币核心诞生以来,垃圾邮件过滤一直是其标准功能。现在没有将现有的过滤器扩展到Taproot交易中是一个错误。我们可以解决这个问题,或尝试一个较为局限的方法,比如OP_RETURN。由于这是一个漏洞修复,它甚至不需要等待主要版本的发布。”

动态 | 贝尔链OASIS平台第7期销毁151.16万枚BRC:据最新消息,为配合Baer Chain生态的长远稳定发展,根据OASIS平台运营规划,每周平台所有游戏总充值BRC的10%将进行永久性销毁。本周OASIS平台共销毁1511602枚BRC,目前销毁已完成。销毁地址见原文链接。[2020/1/6]

链接:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021631.html

PeterTodd:“矿工是这次热潮的受益者,即使限制,矿工也有方法绕过。很多像我这样的人都不会运行节点去审查那些交易。”

链接:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021634.html

jk_14:“Spam交易泛滥并不是根本原因,高昂的手续费才是,建议解决比特币长期安全预算问题,以降低交易费用。”

链接:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021641.html

Aleksandr:“两种方式,要么设置这类交易最多只能占据10%的区块容量,要么改变结构让这些交易的手续费会更贵,推动这些交易走向闪电网络这类L2。”

链接:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021670.html

了解更多:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/date.html

其他观点:

SamsonMow接受Cointelegraph采访时表示,围绕Ordinals和BRC-20代币的炒作是不可持续的,并将在几个月内消失;基本上是在向比特币矿工直接支付巨额费用,这种情况不可能持续下去;SamsonMow认为它们就像垃圾邮件一样堵塞了网络,比特币的大规模采用是因为它作为一种储蓄技术和一种交易手段,而不是因为“人们制作JPEG并将它们粘贴在链中”。

比特币第2层侧链Mintlayer的首席执行官EnricoRubboli:Ordinals背后的技术“存在严重缺陷”并且不遵循“核心比特币社区的公理”。Ordinals可能会导致对比特币进行额外的监管审查,因为新的BRC-20代币可能被视为不受监管的证券。

AngelBlock创始人AlexStrzesniewski:我看到许多BTC最大主义者的强烈反对,但我认为任何人都不应该使用他们的平台来试图审查交易并试图辨别任何网络上的有效和无效交易。

F2pool:Ordinals是对比特币应用的有益探索,有助于在比特币网络中释放更大的价值。

Bitfinex和Tether的CTOPaoloArdoino在罗马区块链周接受Cointelegraph采访时针对BRC-20和Ordinals表示,如果一个特性存在,那么用户就有权使用它,交易所应该加快应用闪电网络。

https://cointelegraph.com/news/ordinals-good-or-bad-for-bitcoin-supporters-and-opposers-raise-voice

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金星链

[0:453ms0-0:961ms