Taproot Assets 协议 是一种在比特币上表示基于 UTXO 的资产的协议。本文致力于解释 TAP 是如何创建和转移资产的。
共享UTXO 让多个用户共享对一个UTXO的所有权、让他们的资金寄身于同一个UTXO中。
总结了最近披露的影响 0.21.0 以前版本的 Bitcoin Core 软件的安全漏洞。为方便读者判定自己正在使用的软件版本的安全性,按照修复的时间倒序重新排列了漏洞的叙述。使用越新版本的用户需要严肃阅读的部分越少越靠前。
,Taproot Assets 利用了比特币网络的安全性和稳定性,以及闪电网络的速度、可扩展性和低手续费。
本文尝试总结和分类其他人对比特币脚本的研究
这个方案有以下特性:1. (应该)在今天的比特币上就可以工作(无需 OP_CAT)2. 不像比特币脚本中的其它形式的 lamport 签名,这个方案是可以签名花费交易的。
随着建立在比特币上的系统变得越来越有表达力,比特币的应用场景也迅速增长。虽然这让人非常激动,但这种更强表达力的支持者和批评者都同意,一个重要的顾虑是 “MEV” 风险。令人遗憾的是,在比特币语境下,“MEV” 缺乏明确的定义;而这个术语的标准定义又过于宽泛,以至于在关于协议风险的讨论中完全无用。
闪电网络的承诺是让比特币支付能够得到近乎瞬时的结算。但是,以自治的方式实现这个目标构成了持续的技术挑战,主因是通道余额的不透明,但这也是内化于闪电网络的设计的。在本文中,我们会深入了解闪电网络中的寻路程序(在更广泛的意义上,是支付的规划),尤其是 LND 客户端中的相关实现。我们将讨论现有的、让支付
深入了解如何打包支付转发路径上各个节点沟通的数据,使得沿路转发支付时泄露的信息尽可能少。
BitVM 2:比特币上的免许可验证
在链上向 Phoenix 钱包存入资金现在变得更便宜(*),也更隐私,这都得益于过去几年添加到比特币和闪电网络上的强大新功能的组合。
介绍一系列的技术和解决方案,允许闪电钱包只保留一种形式的资金、只展示一种余额,同时保留跟一切钱包交互的能力。
介绍获得入账流动性的方案。
静态收款码的方案
本篇所述的内容,将使读者对闪电网络的 “网络” 特性有更直观的理解,也将意识到,这里有多么大的改进空间。本文也将解释一些已经发生和正在发生的改进。同时,其中的关键事实,也解释了闪电网络当前的一些用户体验。
具体解释,在当前的比特币上,闪电通道是如何构造的、通道内的交易是如何实现的、这样的 “支付” 有什么样的特点。
我一直在讨论闪电网络的用户体验,好几年了,也包括离线支付的困难
文章旨在填补关于闪电网络的文献资料的一些空白
为了彻底改变用户进入闪电网络以及在闪电网络中交互的体验而提出异步支付和 JIT 通道技术
人们对比特币区块的有限空间的需求大大上升,这导致交易为了得到区块确认必须付出更高的手续费。
本文是我对所有 Bitcoin Core 发行版本的历史同步性能的研究的其中一个结果,也是构建真正老旧的版本的挑战(难以找到编译好的二进制文件)的成果。
人们常常忽视的地方是,LSP 不仅加强了闪电网络的可扩展性和可靠性,而且是在不需要用户放弃资金自主保管的前提下完成的。
我们探究了多路径支付的复杂之处、它对网络去中心化和隐私性的好处,以及当前可用的不同实现 —— 每一种都有自身的取舍。
使用合适的限制条款,我们可以创建链上效率高得多的 HTLC 输出、使之不受替代交易循环攻击,而且更难被阻塞。
Payjoin 是一种协议,运用一种简单、聪明的技巧来构造比特币交易,一石多鸟地解决了许多问题。
探索比特币钱包需要区块过滤器的理由
“拼接(splicing)” 是一个简单的概念,就是指重设闪电通道大小的能力。但随着时间推移,越来越显而易见的是,这种重设闪电通道大小的能力,将给我们带来许多额外的好处,这些好处往往在意料之外,而且从根本上提高了闪电网络的可用性。
了解助记词和钱包背后的基本原理
对闪电通道的替代交易循环攻击(replacementcyclingattack)是怎么一回事?关于这种最近在邮件组中公开的漏洞,人们有很多讨论,但内部的机制却有点难以理解。我尝试用图片来解释一下。
今天,ZeroSync(一个为使用零知识证明拓展比特币而成立的协会)的开发者 Robin Linus 提出了 “BitVM”,为将来的比特币应用开发打开了非常有趣的可能性。它可以启用几乎所有的任意计算,并使用这些计算来执行在比特币链上发生的事情。
而在闪电网络语境下,备份指的是对一个节点的通道状态的备份,包括关于它的通道余额、通道配置以及通道里发生过的所有承诺交易的信息。这些状态存储在节点的硬盘上,可用于在节点遭遇宕机、数据丢失和其它意外事件之后复原这个节点。在持有这样的备份时,节点可以尽可能降低在遭遇**软硬件故障**时丢失资金的风险。
无论你是开发闪电网络项目的开发者、谋求创新的企业家,还是仅仅对暂缓支付发票的原理感到好奇,这篇文章都适合你。
本文探讨,基于现在许多聪明的头脑正在开发的解决方案,闪电网络的用户体验会是什么样。
下列版本号以前的闪电节点实现,易受本文所述的创建大量假通道的 DoS 攻击: LND 0.16.0、CLN 23.02、eclair 0.9.0、LDK 0.0.114
将你的闪电节点私钥和安全规则验证从闪电节点中分离出来
我正在提议改变 Bitcoin Core 的一组交易池规则(policy,策略),以开启基于交易包的交易池验证(作为 “交易包转发” 特性的准备工作)。这不是共识层的改变,也不是 P2P 协议层的改变。但是,因为交易池规则将极大地影响交易的传播,所以我认为在邮件组里公开也是有意义的。
我正在撰写一份提案,建议改变当前的点对点协议以启用 “交易包转发(package relay)” 特性,并征求对其中的设计和方法的反馈。这里是一个链接,汇总了最的提案:https://github.com/bitcoin/bips/pull/1324
* 比特币有一种 “绝不牺牲安全性” 的设计哲学。 * L2 合约式协议(比如闪电通道)尝试引入更多功能、可扩展性以及隐私性,但交易转发中的一些审查攻击是其软肋。 * 交易包转发是一项 L1 的交易转发策略升级,可以关闭这些攻击界面,因此可以加强闪电通道的安全模型。
上周的文章介绍了 “锚点输出” 和 CPFP carve out,这种方法仍然有一些不足之处,本篇文章探讨了目前为解决这些和其他限制所做的努力。
到目前为止,我们已经探讨了关于去中心交易转发的目的和挑战,这些因素使得节点本地和整个网络都要使用比共识规则更严格的交易验证规则。因为 Bitcoin Core 软件的交易转发规则变更可能影响一个应用的交易是否能被转发,所以在提出之前,需要整个比特币社区的社会合作。类似地,使用了交易转发的应用和二
前一篇文章讨论了保护节点资源的问题。由于各个节点的资源不同,因此有些规则是可配置的。我们还提出了为什么最好统一规则的理由,但是哪些内容应该包含在这个规则里呢?本文将讨论网络范围的资源概念,这对于可扩展性、可升级性和启动和维护全节点的可访问性等方面至关重要。
限制条款(covenant) 是一种允许内省(introspection)的构造:一个交易的输出,可以为接下来花费它的交易设置条件(超越具体的 “必须提供它自己以及某一个公钥的有效签名”条件)。
等待确认(六):规则一致性
“交易池”系列周刊的第五篇 - 用于保护节点资源的规则
比特币钱包软件让你可以在同一个应用中使用许多个 “钱包” 并生成无数个地址。理解 “xPub” 和 “xPriv” 可以帮助你理解这是怎么做到的。
在本文中,我会简要介绍比特币轻客户端的需要,以及为什么 “致密区块过滤器(compact block filters)” 比 “布隆过滤器(Bloom filters)” 更好地满足了这种需要。然后,我会深入解释致密区块过滤器是怎么工作的,并会附上在测试网上构造这样的过滤器的逐步讲解。
为了让一切都能顺利工作,签名(而不是 哈希值/原像)更有可能让我们满意。
闪电网络可以说是比特币有史以来最具影响力的重量级创新技术。它能够以高效且低成本的方式进行交易,无需占用任何链上空间,同时又能完全保留比特币的抗审查和免信任特性。
闪电网络经济即将到来,它将粘合两大基础元素:技术创新和需求人群。
制作比特币钱包备份时,我们希望根据自身需要和风险情况,找出下列特性的最优组合方案。
概述在本文中,我会探究基于Taproot的闪电通道(下文简称“Taproot通道”)的注资交易和承诺交易的结构。
问:什么是闪电网络?答:闪电网络是一个去中心化网络,旨在实现比特币所有权的实时链下转移,并且无需用户信任第三方。该系统目前还在开发中。
如果你熟悉比特币,你可能知道怎么创建一个用来接收支付的地址(以及相应的 QR 码)。而且这样的地址也是可以重复使用的,虽然重复使用相同的地址不是一种值得推荐的习惯但这是一种人们习惯的用户体验,也有特定的用途。
一个网络中的计算机依据协议跟彼此交流。在这里,“协议” 指的是一套规则系统,指定了消息应该如何传输和解读。闪电网络协议中的支付消息传输部分由 BOLT#4 描述,也叫 “洋葱路由协议(Onion Rounting Protocol)”。
在本文中,我们会讲解 HTLC 工作的方式,并使用一个例子来展示多跳支付是如何在闪电网络中实现的。
闪电网络是一种去中心化的链下技术方案,可支持每秒上万笔交易并发,接近于 Visa 系统能做到的程度(举个例子)。
现在,他们想要在通道中放入一个哈希时间锁合约(HTLC),以确保 Bob 在用 1btc 交换 Carol 手中的秘密值后,Bob 可以从 Alice 那里取回 1btc。
在上一篇文章中,Alice 和 Bob 建立了一个双向的支付通道。现在,Alice 想要给一个第三方 Carol 支付 1 btc。
本系列的第一篇文章将列举必要的模块并展示这些模块如何能组合起来创建 “智能合约”;这个概念可以用来理解闪电网络的第一个前提:双向的支付通道。
在本篇中,我们将学习闪电支付通道和闪电网络是如何实现的,并在此基础上了解其它的以脚本实现的特性。
“哈希锁” 也称 “哈希原像检查”,也就是检查某个传入的数据的哈希值是否为某一值。
“时间锁” 就是在某一个时间事件发生后才能打开的锁,即,为了通过这样的操作码的检查,由某种方式取得的当前时间已经越过了脚本预先指定的时间。
本章,我们正式进入最常被使用的比特币复杂脚本模块:多签名。
理解基于比特币脚本的合约式协议,如何嵌入具体的应用场景中并为相关参与者服务。
本专栏分享的内容包含比特币生态涉及的理论研究、扩容技术、文化、密码学、观点、技术分析等内容
适合对比特币感兴趣的同学
上图为比特币生态的知识点结构图
本专栏分享比特币生态的技术资料,内容来源于:https://www.btcstudy.org/