1. 链一财经首页
  2. 资讯

追踪交易错误,提高比特币闪电网络支付的可靠性

比特币闪电网络中,支付的可靠性取决于所选Lightning Node路线的可靠性。 有关节点先前付款的历史信息有助于用户选择更好的闪电节点,使得付款体验更佳。 因此,有必要对比特币闪电节点和通道的的历史交易进行跟踪,比如把以前失败交易严重的节点通道列为黑名单。

为了有效实现这种机制,重要的是要知道哪些属于的非理想的付款尝试的节点。(这是否存在刷历史数据和信用漏洞?)

非理想的付款尝试不仅包含失败的付款尝试(无论是立即失败还是延迟),也包含成功付款,但需要很长时间才能收到`htlc_fulfill`消息。

对于非理想的付款尝试,我们目前无法确定应受到惩罚的节点。 特别是:

*如果尝试需要很长时间才能完成(才能最终解决或失败),我们没有任何信息可以指出延迟的来源。

*节点可以返回损坏的失败消息。 当此消息在多次加密轮次后到达发件人时,发件人不再能够查明未付款的节点。

一种可能的解决方案是更改失败消息,使得沿着向后路径的每一跳都添加一个hmac信息(当前只有错误源对消息进行认证)。 这允许将损坏的源缩小到一对节点,这足以正确地确认需要惩罚的节点。

除此之外,所有跃点都可以为失败消息添加两个时间戳:htlc创建时间和htlc失败时间。 使用此信息,支付的发送者可以再次识别一对节点的延迟源。 这些时间戳也可以添加到结算消息中,以便还可以对缓慢结算的付款进行诊断。

这里的挑战是设计失败消息格式,使得跳跃无法学习它们在路径中的位置。 只是将时间戳和hmacs附加到可变长度消息将显示节点和错误源之间的距离。

一个固定长度的消息,其中跃点将一些先前(未使用的)数据从消息中移出以创建空间以添加它们自己的数据似乎不起作用。 会发生的事情是,较早的节点计算出的hmac数据会被移出并且发送者无法再恢复。 在这种情况下,发件人无法验证hmac。 重新生成移出的数据(类似于前向路径上的确定性填充)也不是解决方案,因为节点可以在传递消息之前修改该(未使用的)数据。 这将使所有hmacs无效,从而拒绝发件人定位负责节点。

一个空间效率低的解决方案是让每一跳为每个可能的(实际)消息长度添加hmacs,但这将需要总共n ^ 2个hmacs(20 * 20 * 32个字节)。 其中一半可以在途中丢弃,但它仍然会留下10 * 20 * 32 = 6.4kb的hmacs。

另一个方向可能是使用可变长度消息,但让错误源添加一个看似随机的长度填充。 可以从共享秘密确定性地导出实际长度,使得错误节点不能仅添加填充。 这有点模糊了与错误源的距离,但仍然显示了一些信息。 如果知道填充长度在0到20个块的字节之间,则消息长度(例如25个块)将显示错误源至少5跳。 尽管如此,这可能是一个公平的权衡。

所有这一切的替代方案是尝试通过探测不同的路径长度并来自不同的角度来定位坏节点。 然而,这将需要更多的尝试和更复杂的结果处理。 还有一定程度的间接性,因为并非所有信息都是在一次往返中收集的。 除此之外,如果恶意节点设法识别探测器,则它可能以某种方式以不同的方式起作用。

我有兴趣听听您对能够无可挽回地定位坏节点的重要性的看法,以及有关失败消息格式的想法。

根据国家《关于防范代币发行融资风险的公告》,大家应警惕代币发行融资与交易的风险隐患。

本文来自LIANYI转载,不代表链一财经立场,转载请联系原作者。

发表评论

登录后才能评论