比特币Knots项目争议与Luke Dashjr的技术实践剖析

Luke的安全实践

Luke多年来多次出现安全漏洞，至今仍未实施基本的安全措施，这让许多同行感到困惑。

2022年底，Luke的服务器遭到入侵。这本可能发生在任何人身上，但令人担忧的是，比特币Knots的二进制文件仍托管在已知被入侵的服务器上，三年后Luke仍未重建服务器以确保其清洁。这不是无知，而是疏忽性的懒惰。

Luke自己的网站承认，他在似乎是同一台已知被入侵的公共Web服务器上存放个人文件。这应该是个明显的问题：不应将私人文件放在公开可访问的机器上，更不用说放在已被入侵的机器上。

2023年1月，由于糟糕的安全实践，Luke损失了200多枚比特币。据我们了解，他甚至没有使用硬件密钥管理设备来保持密钥永久离线。粗略的理解是，他将比特币钱包文件保存在PGP加密容器中，该容器位于联网机器上， somehow他的PGP私钥和机器都被入侵，导致灾难性损失。

更令人担忧的是，Luke向FBI举报了他的比特币核心贡献者同行，声称其中一人在活动期间访问了他的笔记本电脑。据参加核心开发会议的人透露，Luke经常在这样的活动中将笔记本电脑无人看管，这为恶意人员安装恶意软件提供了机会。

比特币Knots的合并过程不透明。对比比特币核心的合并拉取请求与Knots的合并拉取请求，问题很明显：在比特币核心仓库中，很容易找到讨论代码变更的相关拉取请求，而在Knots中，这是个谜。

比特币核心合并拉取请求的提交都是加密签名的，而Knots的提交则没有。这是Knots缺乏的另一个完整性检查和保证。

另一个git仓库的担忧是，Luke只是手动从拉取请求中提取代码，然后自己提交，导致任何想要审计的人都必须手动重新检查Luke的提交与其他人可能审查过的拉取请求代码。

具体示例：Luke提交的应用比特币核心拉取请求#30635的代码变更，通过并排放置代码差异可以看到它们并不完全相同。这是预期的，因为Knots代码与核心不完全相同。

但这的安全影响是什么？主要是原始代码作者（本例中为Sjors Provoost）编写的完整性完全丧失，上游比特币核心审查员为确保代码变更安全所做的工作也完全丧失。为了让Luke实施的这一根本性新代码变更具有类似的安全属性，它需要重新经过稳健的同行评审过程。

2012年1月，当时比特币核心的首席维护者Gavin Andresen称Luke为"有毒之人"。

另一位长期贡献者认为Luke对开发是"净负值"。

2013年，Luke声称Erik Voorhees是罪犯，应该因运行SatoshiDice而被捕。

2014年，Luke滥用其Gentoo比特币核心软件包维护者的职位，默认启用他的自定义黑名单规则给Gentoo用户，并试图将担忧视为恶搞。

2015年，Luke因试图重新定义"纸钱包"一词而引发争议。

一个月后，因Luke的个人项目"音调比特币"引发更多维基争议。

2021年，许多开发人员对Luke感到沮丧，因为他们认为他通过纠缠激活参数来阻碍Taproot的BIP合并。

到2024年，比特币开发人员对Luke作为BIP编辑的糟糕领导力感到足够沮丧，以至于提议增加更多编辑。

Knots实际上对闪电网络和Whirlpool混合协议都有害。

当您了解Luke关于比特币混合的个人意见时，这一特定决定将更有意义。

Luke声称比特币Knots比比特币核心有更多的维护者和贡献者，这不是任何理智的软件工程师会声称的。

您不会在分叉中自动继承这些属性。正如我之前解释的，Luke的工程实践实际上破坏了来自原始作者和原始审查员的代码变更的完整性。

如果您浏览Luke的Reddit评论、X回复或Bitcointalk帖子，您可以看到Luke对许多事情倾向于持有边缘观点。

“去中心化安全软件在安全方面需要严格注意细节。这段软件的维护者独自工作，并且不擅长安全。这是一个例子。因此，我们可以合理地得出结论，他将无法确保该软件未来所需的安全水平。”

我绝不是声称Luke多年来没有为比特币做出重要贡献。Luke显然拥有可用于为项目做出积极贡献的技术技能。相反，我请您考虑您真正希望从比特币客户端首席维护者那里得到什么。

回顾过去六个月发生的事情。社交和技术社区的大量时间和注意力都花在哪里？我倾向于同意Luke及其同伙最近相当有毒。

“我们拒绝：国王、总统和投票。我们相信：粗略共识和运行代码。” - David Clark，1992

这句话对于如何管理一个任何人都可以贡献的开放全球技术项目的最佳实践至关重要。Luke是否真正体现了这些特征？

这是您希望领导自由货币开发的人吗？