11 年后,比特币依然很难用_以太坊:DEFI

来源/LongHash长期以来,各种公司和许多开发者都在尝试提高比特币的用户友好程度,然而这个全球最流行加密货币的总体可用性却依旧相当不如人意。相比对普通人而言易于识读的地址,长串随机生成的字母和数字依旧被广泛用为比特币付款的收款地址。为了确保更高的隐私性需要特定的钱包,人为失误造成的亏损依旧常见。而这些还只是一些能够被控制的问题。加密货币交易中还存在币价的高波动性和税务问题。

上周末,比特币可用性的相关问题再一次被暴露在社交媒体上。著名的黄金支持者同时也是比特币怀疑者PeterSchiff发推特表示自己无法获取在多年前获赠的比特币了。比特币的使用是否有可能被简化到能够与Facebook和Gmail这样最普及的app媲美的程度?也许不能。比特币与生俱来的特性要求其用户个人承担很大的责任,因为其大体上的想法是成为用户自己的银行。最终,网络层面的技术进步可能会提高比特币对普通人而言的可用性。但现实是,正如目前的情况一样,要使用比特币,用户必须首先搞清楚为什么要使用它以及必须要做出的权衡取舍。尽管围绕交易所建立的用户界面在数年中已经经历了许多,非托管类钱包依旧面对着令人难以置信的难关。这些问题主要围绕着密钥管理以及比特币交易的不可逆性,这对普通人来说依旧是难以理解和掌握的。比特币付款不可能变得简单

简化比特币付款很难,因为其运作方式与其他任何的线上金融系统都是截然不同的。大多数人都已经习惯了银行的操作方式,即由第三方来保障资金的安全。因此当用户控制着自己的资金时,在上手的过程中就会有一条很高的学习曲线。比特币的复杂性一定程度上起到了保护作用。如果用比特币付款很容易,那么也很容易会出现意外把一笔不可逆的交易发送给错误的对象,或者一名黑客偷走你的钱的状况。围绕完全中心化的系统开发支付app会容易得多,因为他们面对用户失误时有更大的抗性。失手把一笔付款发送给了错误的对象?他们可以逆转这笔交易。有人黑进了你的账户?他们会确保一切恢复到黑客攻击之前的样子。目前,比特币钱包中还无法实现这类保护措施。当用户犯错时,他们可能为此付出高昂的代价。中心化解决方案一个最好的例子可能是像Coinbase这样的托管钱包。这家公司成功开发了把新用户导流到比特币网络的一个最强大的app,但是这样做的代价是它自己成为了一家比特币银行。显然,当你允许第三方掌握私钥时,就会失去比特币作为支付系统的许多好处。然而,这种方案对于那些仅仅希望投资比特币的人来说却很足够了,而这部分人目前正代表了绝大多数比特币用户。但这些中心化解决方案也不是完美的。即使有了像Coinbase这样的比特币银行,账户也可能被黑,因此用户就需要采用最好的安全性操作,例如双重身份验证。除此之外,事实证明基于文本的双重身份验证在保障安全性方面甚至还不如只使用用户名和密码。此外,当比特币软件的开发是为了降低用户方面的个人责任时,从消除那些最初赋予比特币价值的特性这方面来看,就总是会存在一定程度的权衡取舍。优质的比特币钱包UI是什么样子?

那么,怎样才能开发出能够保留去中心化金融系统无需许可的本质的优质用户界面呢?想要不承担任何负面风险就享受个人责任的好处是完全不可能的。在这个阶段,父母辈可能很容易就由于误操作而亏钱—除非你只是给他们一张纸或者一个硬件钱包,让他们在文件柜里放上十年,这样比特币付款就不再成问题了。话虽如此,对于那些希望承担这部分额外的责任的人来说,也可以开发一些值得注意的工具。举个例子,BlockstreamGreen是一款采用绿色地址来提高钱包安全性的钱包。这就像是在不把资金控制权交给第三方的前提下,在一种比特币钱包里增加银行级别的安全审查。它采用了一种2-of-2多签地址来存储用户资金,同时其中一个私钥由一个服务器控制,只有在用户成功输入某种形式的双重身份验证后,这个服务器才会签署一笔交易。用户也不必担心服务器脱机时资金不可用的风险,因为当服务器无响应时,一笔预签署的退款交易可以被广播到全网。非托管类的交易所是另一个领域,他们阔步疾行,在为懂行的比特币用户提供允许他们脱离第三方托管资金进行交易的用户界面方面取得了巨大的进步。这个领域最重要的一个例子可能就是Shapeshift,它结合了非托管类交易所和KeepKey硬件钱包。Arwen也一直致力于把非托管类功能带给已经上线的交易所。为了真正让普通人能够更方便地使用比特币而不必再回到中心化服务器,技术进步是必需的。在这一点上,闪电网络当然是最明显的一个例子,但是其他的进步,例如“Bitcoinvaults”应该就能够在钱包层面减少用户失误的普遍性。但如果人们希望使用比特币来付款,个人责任始终是不可替代的。LongHash,用数据读懂区块链。

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

金宝趣谈

[0:46ms0-4:643ms