在这种进攻中，进攻者可迫使许多受害者同时向认领本身的资金，然后进攻者就可以操作这种拥堵环境来偷取在截至日期前未被认领的任何资金。
Pieter Wuille表明白为什么在不参考区块链外部时钟时间的环境下，限制区块速率会使运行全节点的本钱更高，同时也难以低落问题区块率，并防备合谋进攻。
虽然，由于用度是付给矿工的，所以进攻者没有直接的念头来执行这种进攻，可是，假如进攻者有手段迅速接洽受害者，他们就有大概提出赎金要求，从而使其赢利。
比特币软件基本设施更新
原文链接：https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
BOLT2还答允通道同时路由多达483笔付出生意业务，每笔付出需要一个43 vbyte的 P2WSH 输出，总共需要约莫20,000 vbytes的数据需要相对较快地添加到链中，这意味着它大概需要付出较高的用度。假如这一费率是严格要求的5倍，则很容易导致付出高出100美元的生意业务费。 另外，假如确认了理睬生意业务，则需要结算HTLC（再次利用大概需要付出高额用度的生意业务）。假如受害者是向外发送这些付款的一方，他们将需要付出特另外生意业务费来收回每笔付款，这大概会使进攻对他们造成两到三倍的价钱。
原帖链接：https://bitcoin.stackexchange.com/a/96185
写在前面：本周的技能周报，主要涉及到三种关于闪电网络的进攻方法及相应的缓解法子，不难发明，关于闪电网络安详隐患的研究已越来越多，，一方面，这代表着学术界对闪电网络的重视，另一方面，也意味着LN间隔大局限应用尚有较远的间隔。而接下来，则是一些通例的周报内容，包罗来自Bitcoin StackExchange的精选问答，以及比特币软件基本设施的最新希望。
问题3: 在用度超付进攻中，受损桌面软件为什么不能提供与假输入对应的假先前生意业务？
Eclair#1461添加了几个转发到Bitcoin Core RPC的API端点，用于转发该措施的钱包余额和其他信息。它的方针是使Eclair与Ride The Lightning节点打点仪表板更容易集成。
LND 0.10.2-beta.rc2 这一LND 候选版本客户端此刻进入了测试阶段。
暗码学家Jonas Nick回覆了比特币开拓邮件列表中关于拟议的CoinSwap实现的帖子，其提醒开拓者称，P2PKH、P2WPKH以及利用160位RIPEMD160哈希的P2SH地点易受碰撞进攻，当多方协作利用原始协议建设地点时，碰撞进攻会将其安详性低落到80位（请参阅我们在传统P2SH地点中对此弱点的描写）。尽量这以前只是P2SH多重签名用户体贴的问题，但它合用于相关情况，譬喻CoinSwap，个中，提议的两个用户可共享一个P2PKH或P2WPKH地点。
基于诺言（Reputation-Based）的行为；作者对先前提出的若干办理方案举办了从头评估，包罗对“替代锚提案”（alternative anchor proposal）有效性的存眷，以及利用付费签名（ pay-for-signature）无剧本剧本以无需信任的方法，向第三方完成适配器签名所需的最终签名的发起措施。
研究者还提醒称，这些缓解法子固然可低落进攻的风险，但要完全消除风险，需要对HTLC机制举办重大修改。
二、Bitcoin StackExchange精选比特币问答
虽然，理论上照旧可以制止这个问题的，但它要求两边的ECDSA协议被设计成包括一个特另外commitment进程，Nick留意到一些两边ECDSA协议和实现已经在这样做了。
或 《闪电网络最新裂痕阐明：仅需进攻85个节点便可窃取闪电节点通道资金》一文。 Bitcoin Core#19071添加了说明开拓人员如作甚新的尝试性Bitcoin Core GUI存储库做出孝敬的文档。与GUI相关的Pull请求，应被发送到这个新的存储库中，它将利用Linux内核项目利用的monotree开拓模子与主存储库双向同步。对付用户来说，这次疏散并没有泛起出可见的变革，用户仍可以在Bitcoin Core的官方版本中收到GUI，可能在利用主存储库源代码的
René Pickhardt在闪电网络开拓者邮件列表中果真披露了一个措施缺陷，其在约莫一年前曾私下向闪电网络维护人员披露过该问题。据悉，在当前的闪电网络协议中，每次更新通道状态时，提倡通道的一方必需理睬付出单边封锁生意业务的任何链上生意业务用度。而付出用度的一方，也可以选择利用的费率，但对方的安详性也取决于费率是否符合。这意味着，假如对方认为当前市场条件下所选的费率太低了，他们可以随时封锁通道。为了制止这种不须要的生意业务，BOLT2给出了一个例子，说明付费方选择的用度是最低公道预计值的5倍，纵然对方利用的是差异的用度预计较法，该预计值也足以让对方满足。--with-gui举办构建时收到GUI。
原帖链接：https://bitcoin.stackexchange.com/a/96298
提前封锁通道；
安详研究3：针对闪电网络的系统性进攻
原帖链接：https://bitcoin.stackexchange.com/a/96309
安详研究1 ：关于闪电网络用度赎金进攻的办理方案
问题1: 为什么选一个巨大的公式来计较“nBits”中的难度方针？
对此，Andrew Chow深入探讨了一些关于该公式，它的汗青，甚至是比特币0.1.5版客户端示例代码的细节。
一、闪电网络协议安详研究 & CoinSwap碰撞进攻风险
Bitcoin Core #16377更新了
walletcreatefundedpsbt和fundrawtransaction这两个RPC。这些RPC凡是利用钱包去自动选择要在未签名生意业务中耗费的UTXO，但它们也答允用户指定要在该生意业务中耗费的一个或多个UTXO。以前，假如用户选择的UTXO不敷以付出生意业务的所有输出，钱包会自动选择更多的UTXO来举办耗费。可是，假如用户手动选择UTXO，那么他们大概有一些不想耗费特别UTXO的原因，因此假如用户手动选择任何UTXO，则RPC此刻会默认失败。可以利用新的add_inputs参数包围这两个RPC。
Bitcoin Core＃18027在GUI的“文件”菜单中添加了两个选项，以处理惩罚部门签名比特币生意业务（PSBT）：（1）从文件加载PSBT，（2）从剪贴板加载PSBT。
安详研究4：关于两方ECDSA碰撞进攻风险的提醒
Bastien Teinturier在闪电网络开拓者邮件列表中宣布了一个帖子链接，其具体描写了闪电网络理睬协议，它的弱点以及办理办理这些弱点的发起。这篇文章具体探讨了针对闪电网络的原子性进攻以及一些发起的缓解法子。安详研究2：关于闪电网络原子性进攻的接头
Bitcoin Core#19133添加了一个bitcoin-cli-generate参数，以代替在0.19.0.1版本Bitcoin Core软件中删除的generateRPC成果。据悉，新的实现制止了钱包和其他组件之间不须要的依赖干系。
HTLC认领生意业务的即时宣布；
问题2: 比特币真的需要时间戳吗？
淘汰未办理HTLC的最大数量；
原文链接：https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002735.html
对此，研究者还提出了以下几种缓解要领：
据悉，这种进攻操作了一种用于跨多个闪电网络通道的机制（HTLC），研究者发明，通过操作HTLC涉及到的时间限制，会容易导致无辜的闪电网络节点对区块链提倡flood攻击，从而可以窃取到资金。
原贴链接：https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017986.html
Bitcoin StackExchange是Optech孝敬者寻找有关比特币技能问题与谜底的渠道之一，在这期周报中，我们将先容3个精选问题与谜底：
Pickhardt在他帖子中总结了办理该问题的几种想法，但他发明，没有一个方法可以或许让他完全满足。最初在Eclair中实施，厥后在C-Lightning中实施的缓解法子，是针对LN节点来限制待付款的数量，使得生意业务量变小，总用度变低。开拓中的另一个缓解法子是锚输出（anchor output），它答允在通道封锁时选择费率，从而消除了高估用度的须要性，以防备过早封锁通道。文中还提到了一些想法，而Pickhardt但愿读者可以或许思考这一问题，并提出任何其他大概的办理方案。
关于具有多个输入的断绝见证（segwit）生意业务的用度多付进攻，justinmoon提出了疑问，为什么进攻的调停法子（需要输入以前生意业务的副本）不易受到恶意软件提供的虚假先前生意业务的进攻。其答复称，由于提供的任何先前生意业务，必需具有与支出输入的先前生意业务哈希匹配的哈希，因此这种进攻是不行行的。
为了证明这种进攻的可行性，研究者在测试网长举办了模仿，并得出进攻85个通道就可以担保进攻乐成。
来自希伯来大学的研究者Jona Harris和Aviv Zohar在其最新宣布的论文中，评估了一种针对闪电网络的系统性进攻，它答允进攻者窃取锁定在付出通道中的资金。郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
