比特币Optech：通讯第383期回顾

我刚想提一下，Moon，你和Reardon在330期播客里讨论过L的更新。

I was just going to plug that Moon, you and Reardon were on podcast three thirty when we talked about the update to the L.

大约一年前讨论L增强提案时，专门谈到了这个操作码添加到L增强包的事。

Hance proposal just about a year ago, talking about this specific opcode addition to the L Enhance bundle.

如果有人好奇，也可以回听那期播客快速了解情况。

If people are curious, they can also jump back to that to get up to speed as well.

很好。

Great.

好的。

Okay.

那么我主要想说明，我们并非绝对需要这个功能。

So then I will mostly, just mention that we don't absolutely need to have this.

所以如果没有每次提交，只有CTV、堆栈检查和内部密钥，你需要把这些数据放入开放返回中。

So if you don't have per commit, if you only have CTV, check-in from stack and internal key, then what you would do is you would, put this data into an open return.

对吧？

Right?

因此内部数据状态会显示为一笔包含OP_RETURN的支出，数据是可用的。

So the internal data state would look like a spend that has an op return, the data is available.

OP_RETURN数据当然比见证数据贵四倍。

Op return data is of course four times more expensive than witness data.

所以这是一种低效做法。

So that's an inefficiency.

如果这样做，每个人在区块中的可用空间都会减少。

Like everyone has less space in the block if we do this.

我们正努力追求效率，这就是动机所在。

We are trying to be efficient, so that is a motivation.

因此我们希望将这些恢复数据放在见证中。

So we want to have this, this recovery data in the witness.

另一种方法是模板哈希方案，由于他们通过Taproot方案计算这个C缓存类型哈希的方式，它会提交到附件(annex)。

And the other, approach to this is the template hash approach, which makes it possible to because of the way they they compute this C cache type hash using the Taproot schematics, it commits to the annex.

你可以将这些数据放入非空的ONNX中进行转发，这样就能获得见证折扣。

And you can put this this data if you relay non empty ONNX into the ONNX, and that gets the witness discount.

当然，你也可以将OPTURN与模板哈希结合使用，因为它对所有输出进行了承诺。

Of course, you can also use OPTURN with template hash because it commits to all the outputs.

所以它基本上就像CTV，但CTV不对ONNX进行承诺，而模板哈希会对ONNX进行承诺。

So it it's basically like CTV, but CTV does not commit to the ONNX, template hash commits to the ONNX.

如果要解释这些提案之间最大的区别，我认为就是这一点。

If I had to explain the the the greatest difference between the proposals is this.

我认为存在一种可能性，如果我们开始中继非反ONEX数据，可能会引发另一轮关于外生资产的热潮，因为那里简直是外生OSAT负载的理想存放地。

And I think there is a possibility that we if we start relaying non anti ONEX, then we will see another exogenous asset hype cycle regarding because that's kinda like the ideal place for any exogenous OSAT payloads.

就像我说的，它能享受见证折扣。

Like I said, it gets the witness discount.

它承载数据，诸如此类。

It continues data, so on and so on.

我不想过多赘述这一点。

I don't want to harp too much on it.

我已经向大家表达了我的看法，我认为存在风险，但这并非技术性或首要风险。

I I already told everyone what I think about this, I think there is a risk, but it's not a technical and not a first order risk.

那么你的论点会是，配对承诺（Pair Commit）能让人们在丢失所有备份数据的通道关闭情况下更高效地进行恢复。

So your argument would be that Pair Commit makes it more efficient to help people recover from a channel closure where they lost all of their backup data.

那么模板哈希——我不记得他们具体叫什么了——但模板哈希加上从堆栈检查寻找（check seek from stack）和内部密钥（internal key）呢？

Would then the template hash, don't remember what they called it, but template hash plus check seek from stack and internal key.

你会说如果加入配对承诺（peer commit）后，这会得到显著增强吗？

Would you say that it gets significantly enhanced if peer commit got added to it?

不，不会有显著增强。

No, it does not get enhanced significantly.

实际上我要说的是，由于检查模板验证（check template verify）的工作方式，模板哈希必须——某种程度上——你必须拥有那个需要核对和验证的模板哈希在堆栈上。

What I would say it actually, template hash, because of the way, check seek from, check template verify works, you have to, sort of like, have that hash, that template hash that you that you have to check and verify against on the stack.

你必须以某种方式包含这个数据，要么作为签名数据的一部分，要么作为见证参数。

You have to include this somehow either as part of the data signed or as a witness parameter.

对吧？

Right?

所以你必须在堆栈上拥有模板哈希数据。

So you have to have the the template hash data on the stack.

这意味着你必须把这部分成本计入你的业务开销。

That means you have to add this to to your, business cost.

现在有了模板哈希，你能做到这一点。

Now with template hash, can you do that.

你计算这个模板哈希并通过单字节操作码将其置于栈上，然后可以验证签名。

You calculate this template hash and have it on the stack with a single opcode operation, single byte cost, and then you can check a signature against it.

这意味着实际上，你可以用1字节替代33字节，33或34字节的开销现在只需1字节。

That means you can actually, instead of using 33 bytes, you can use like one byte, 33, 34 bytes, and and you can use one byte.

因此从技术上讲，TemplateDash使得更高效的闪电网络对称实现成为可能。

So technically, TemplateDash makes an even more efficient, lightning symmetry implementation possible.

所以如果你只关注闪电网络对称性和契约池结构或板块结构，并且重视模板哈希实现的简洁性。

So if you are only interested in lightning symmetry and the and the covenant pool constructions or plank constructions, then, and, and, and, you value the simplicity of the, of the template hash implementation.

就像你非常看重其简洁性以及它是纯TypeScript实现这一事实——之前有人对使用可升级操作码等方案并不满意。

Like you, you put a large value into that simplicity and the fact that it's a TypeScript only, there have been people who were not happy about using an op an upgradable opcode and and stuff like that.

那么你会认为这是个绝对更优的方案。

Then you would think that this is a strictly better proposal.

从某种角度来看，它确实更胜一筹。

From a certain perspective, it is strictly better.

正如我所说，我们正试图权衡多种风险。

Like I said, we are trying to consider a lot of different risks.

当我们提出这些后续代码时，也在考虑社会层面的潜在风险。

When we propose these follow-up codes, we are trying to consider like social trauma risks as well.

从这个角度看，我认为联盟方案更优。

And from that perspective, I think Alliance is better.

但从技术角度而言，我认为模板哈希检查CycFromStack和内部密钥是非常扎实的提案。

But from any technical perspective, I think template has checked CycFromStack and internal key are a very, very good solid proposal.

所以在技术层面上我很欣赏这个方案。

So I I like it on a technical level.

我认为它可能会在社会层面引发令人遗憾的——该怎么形容——连锁反应？

I think it is going to have a regrettable, how do you say this fallout in the social space?

如果我们选择这个方向，这是我预测的结果。

If we go the direction, that's what I predict.

但是，如果——再次强调如果——我认为我们将进行脚本恢复，那么我们就是在走GSR路线。

But, if if and and again, if I if I think that we are going to have script restore, we are going in the GSR direction.

这是整个问题的另一个方面。

This is another aspect to all this.

那样的话我们就会拥有CAT操作码。

Then we are going to have cat.

所以任何配对提交、向量提交提案都可以通过CAT来实现。

So any any pair commit, vector commit proposal can be implemented with cat.

虽然单次提交仍是更简单安全的实现方式，但你可以用多个操作码来模拟单次提交的功能，CAT就是其中之一。

Per commit is still a simpler and safer way to do it, but you can use multiple opcodes to emulate basically what Per commit does, and CAT is one of them.

当然，如果只采用CAT的话，在表达能力上会存在非常非常明显的门槛限制。

Of course, a very, very significant threshold breaks in expressivity if you just bought CAT.

所以如果我百分百确定我们会恢复脚本功能，那么我会说可能没必要专门添加一个操作码——这个操作码当初被选中就是因为我们以为无法就CAT达成共识。

So if I was like 100% sure that we are going to have script restored, then I would say it might make sense not to add an opcode that was specifically selected because we thought that we can't have consensus on cat.

所以这将是另一个，你知道的，另一个考量

So that would be another, you know, another

还有其他考虑吗？

Another consideration?

好的。

Alright.

是的。

Yeah.

另一个方面，为什么你会偏好模板哈希。

Another another other aspect of this, why you would prefer template hash.

对。

Yes.

但是，如果我们认为未来有些不确定，我们现在就想改进，而社区已经有些受创，我们想尽量减少这些外生资产代币相关创伤的可能性，那么我认为目前Anahance是更好的选择。

But, if if we if we say that future is a bit uncertain and we want to improve things now and, the community is sort of traumatized already, and we want to minimize the potential for these exogenous asset token related traumas, then I believe Anahance is the better choice right here, right now.

啊，好的。

Ah, okay.

明白了。

I see.

因为你认为如果采用模板哈希，配合你称之为'闪电对称性'的改进备份版本，就会想要使用附件(Annex)来存储数据，而人们会利用附件进行见证数据填充，这显然会导致问题，所以选择L方案。

Because you think that if a template hash came, for the, the improved backup version with the Lightning Symmetry, as you call it, you would want to use the Annex for data storage and that would be people using the Annex for witness stuffing and that would blow up of course, so L.

通过配对提交的增强方案可以构建一种见证结构，这种结构专门限制额外数据填充，从而在社会层面更安全。

Enhance by having a pair commit would have a witness construction that only allows the, or doesn't specifically allow more data stuffing and that way it's socially safer.

这是你的论点吗？

Is that your argument?

是的。

Yes.

是的。

Yes.

再举个例子，如果你采用每笔提交都带模板哈希的方案，且模板哈希仅承诺ONNX存在与否（而非ONNX具体数据），仅记录ONNX存在状态。

And then again, if you, if you, if you, if you had per commit with template hash and template hash, let's say only committed to the ONNX being there or not being there, not the ONNX data, just ONNX present or not present.

这种情况下，我甚至认为该提案优于当前采用检查模板验证(CheckTemplate Verify)的LHONS提案。

In that situation, I might even consider that proposal superior to the current LHONS proposal with with the CheckTemplate Verify.

不过我们也喜欢检查模板验证(CTV)，因为它能作为裸CTV使用。

Although we also like CheckTemplate Verify for its ability to be used as a bare CTV.

你知道，你可以在传统脚本中使用它，而不需要整个见证机制和其他所有东西。

You know, you can use it in legacy script without the whole witness thing and and everything.

理论上我们喜欢这样，但实际上，似乎总是你真正需要的是Taproot。

We we like that in theory, but in practice, it always seems to be that you really want taproot.

只要它没有损坏，你确实希望密钥池可用于任何协作变更和优化。

You really want to have so long it's not broken that key pod be available for any cooperative change and and optimization.

比如，你可以直接跳过整个脚本化的Taproot处理，只需进行一次单一的——我的意思是，可能是一个基于协作的多签签名，但它看起来仍然像是一个单一签名，并且只获取链上发生事件的最少信息。

Like, you can just skip the whole skip Scripty tap treating, and you can just, do a single, single, or I mean, it's probably a collaborative music based signature, but it still looks like a single SIG and retrieves minimal information about what happened on chain.

因此，这始终是合作解决问题的优选方式。

So that is a preferable way to resolve things cooperatively always.

只要密码学不被攻破，这种高效且内置于所有协议中的能力就能有效简化脚本执行流程。

So long again we do not have this cryptography broken that is very efficient and and also baked in in all of these protocols sort of to to have that ability to shortcut the script execution.

从这个角度看，它并非极具价值，但从另一角度而言，我们确实欣赏CTV能独立于Tabscript之外存在的特性。

So from that regard, it's not super valuable, but on from another perspective, we actually like that CTV can exist outside of Tabscript.

所以这就像抛硬币，结果可能因个人偏好而异。

So this is like coin toss or it can go either way depending on personal preferences.

本周我们还有一项共识变更议题。

And we have one more changing consensus item this week.

SLHDSA Sphinx后, 后量子签名优化方案。

SLHDSA Sphinx post quantum signature optimizations.

我们未能达成一致条件，所以我将尽力谈谈后量子签名优化。

We were unable to get conduition on, so I'm going to do my best to talk about post quantum signature optimizations.

如果我犯了错误，Merg可以插话纠正。

Merg can chime in if I make a mistake.

否则，Conditions那边也有些很棒的博客素材。

Otherwise, Conditions got some great blog material as well.

是的，Conduition在比特币开发者邮件列表上发布了关于优化Sphinx签名算法的内容。

So yeah, Conduition posted the Bitcoin Dev mailing list about optimizing the Sphinx signing algorithm.

我发现Sphinx Plus现在改名叫SLHDSA了。

I found out that Sphinx Plus is now called SLHDSA.

Merch已经在向我挥手了。

Merch is already waving at me.

怎么了，Merch？

What's that, Merch?

不，抱歉，我只是在看你之前在聊天里写的内容，但我觉得Sphinx Plus是昵称，而SLHDSA是无状态哈希数字签名算法，听起来技术性更强，不过我不确定，也许你是对的，我还没研究清楚这些术语的顺序。

No, sorry, I was just looking what you had written in chat earlier, but I think Sphinx Plus is the nickname and SLHDSA is stateless hash based digital signature algorithm, so it seems much more technically, but I don't know, maybe you're right, I haven't researched the order of things.

这是一种量子抗性签名方案或算法，曾是BIP30提案的候选方案，也是比特币量子抗性相关讨论中的方案之一。

This has been a quantum resistance signature scheme or algorithm that's been a candidate for the BIP30 proposal and other ideas around quantum resistance to Bitcoin.

Conduition对该算法进行了一系列性能优化，他认为自己现在可能拥有，引用，'可能是目前公开可用的SLH DSA最快实现，至少在我的硬件上是这样，也可能是GPU实现中最快的之一'。

Conduition has made a bunch of performance improvements in the algorithm that he believes he may now possess, quote, what may be the fastest publicly available implementation of SLH DSA, at least on my hardware, and possibly also one of the fastest GPU implementations.

Moon，我看到你举手了。

Moon, I see your hand up.

Moon，你静音了。

Moon, you're muted.

我想补充一点，严格从技术角度来说，比特币通常不需要像Sphinx这样的方案。

So I just wanted to chime in on that, you generally don't want strictly, technically, something like Sphinx for Bitcoin.

如果你的目标只是每个UTXO支出时使用一个签名，那么Sphinx方案实在是过度设计了。

Like, if if your goal is just to have, like, one signature per spending, a UTXO, then Sphinx is way, way overdone.

比如，我们可以使用哈希算法实现更高效的后量子签名方案。

Like, we we can have much more efficient of it, post quantum signature schemes, using hashes.

Sphinx更适用于非比特币场景，比如需要多次甚至频繁签名的环境。

Sphinx is more more suited to not Bitcoin context and into a context where you have to sign multiple times, even many times.

但这是有代价的。

But this is a cost.

对吧？

Right?

所以基本上，比特币开发者试图在典型使用场景与使用通用方案的成本之间取得平衡——这些方案并非专为比特币设计。

So so, basically, in Bitcoin, what the developers are trying to do is balance out the typical use cases in Bitcoin against the cost of using something very general and not not really, developed with Bitcoin in mind.

关键点似乎是这个一次性签名随机森林机制，通过无状态设计实现——因为这些基于哈希的签名只能使用一次。

And the the key piece seems to be this random, forest of, of, one time use signatures, thing where you basically you are trying to make it stateless because you can only reuse these hash based signatures like one times.

如果不想在签名设备中维护状态（这很麻烦），

So if you don't want to have to maintain a state in a signing device, that's a pain in the ass.

就必须提取交易摘要作为随机源，并找到要签名的随机树分支。

And you have to take a digest of the transaction and use that as a source of randomness and and find the random tree branch that you want to sign with.

所以这大致就是他们的研究方向，如果我没理解错的话。

So that is kind of what they researched, if I understand it correctly.

然后，嗯，是的。

And, and, yeah.

我必须简短地表示不同意。

I have to disagree briefly.

我很希望我们能让UTXO只能单次签名，那样就太好了。

I would love if we could make UTXOs only, like, if you could only sign a single time for UTXO, that would be great.

但我们不能那样做。

But we cannot do that.

那样显然会立即消除地址重用问题，这将会非常棒。

Like, that would obviously get rid of address reuse immediately, which would be brilliant.

但如果你创建了一笔交易，比如因为第一次手续费太低而需要追加手续费的情况呢？

But what if you create a transaction that, for example, doesn't get, like if you have to bump a transaction because it was too low fee the first time, right?

所以总会遇到需要重新发起相同交易的情况。

So there's always situations in which you have to reissue the same transaction.

即便没有任何地址复用的情况，你也必须能够为比特币交易多次签名，否则很容易就能通过等待你签名后伪造签名窃取资金，从而阻止你的交易被确认。

Even if you don't have any address reuse, you have to be able to sign more than once for Bitcoin transactions, or it would be very easy to just censor your transaction from being confirmed, waiting until you make a signature and then forge your signature and steal your money.

所以我们需要多次、多次的签名。

So we need many, many times signatures.

是的。

Yes.

是的。

Yes.

我同意。

I I agree.

不过，比特币通过Taproot已经实现了非平衡树的功能。

However, Bitcoin has this thing with Taproot already where you can have nonbalance trees.

比如，Sphinx就是理想方案。

Like, Sphinx is ideal.

我是说，想象一下他们称之为'超森林水域'的平衡默克尔构造集。

I mean, imagine to have a balanced Merkel construct set that they call hyperforestal water.

我不知道。

I don't know.

基本上，比特币的等效情况是大多数时候你只需要一个签名，但你也希望有能力在必要时以更高的存储成本、带宽成本和手续费为代价，拥有多个签名作为备份方案，但你持乐观态度。

And and basically, the Bitcoin equivalent would be is most of the times you want to have like one signature, but you want to have the ability to have many, many signatures at more cost and more more storage cost, more bandwidth cost, more fees as a backup if you have to, but you are optimistic.

实际上你认为，比如说90%的情况下，你的第一个签名就能被打包进区块。

You you actually think that your first, let's say 90 something percent of the times your first signature will get into a block.

所以你希望这个流程能真正高效。

So you want to have that, like, really efficient.

这就是我想表达的意思——Sphinx并不真正适合比特币，但这项研究看起来很棒。

And, and that's what I wanted to mean that Sphinx is not really suited for Bitcoin, but this research looks great.

我还没有深入研究，但我非常喜欢目前读到的内容。

I did not dig into it, but I really, really liked what I read so far.

这个观点很有意思。

That's an interesting point.

如果你有一棵可以从中花费的叶子树，每片叶子只能使用一次，但你仍然可以拥有许多叶子，成本只会逐渐增加。

If you had sort of a tree of possible leaves to spend from and you only get to use each leaf once, but you could still have many leaves and the cost would just gradually increase.

这实际上也能满足我们的需求。

That would actually also satisfy our requirement.

但当你比如提高交易手续费时，你的交易体积也会随之增大，这有点讽刺。

But then when you, for example, fee bump, your transaction, your transaction would also increase in size, which is kind of funny.

是啊。

Yeah.

手续费率越高，你还得把交易做得更大。

The higher fee rate, you also have to make the bigger transaction.

而且它是有状态的。

And it's stateful.

对吧？

Right?

这正是我之前提到的。

That that's what I mentioned.

缺点是它看起来更适合比特币，但状态性会反噬你。

The the downside is that it looks more suited for Bitcoin, but the statefulness bites you back.

对。

Right.

那么回到Sphinx。

So back to Sphinx.

Sphinx基于改进版的Winternet一次性签名方案和少量多次签名方案，我认为关键点在于随机子集的森林结构和默克尔树。

Sphinx is based on the mod on a modified version of Winternet's one time signatures and on a few time signature scheme, I think that's the point, with the forest random forest of random subsets and Merkle trees.

所以主要缺点是相比我们现在使用的方案，它们的体积非常庞大。

So the big downsides are they're enormous comparatively to what we're using these days.

我手头没有具体数据，但目前公钥需要几KB，签名至少有几百字节，我记得是800字节或更多。

I don't have it here from the top of my head, but we're looking at several kilobytes for pubkeys and signatures currently are in the several 100 bytes at least, I think 800 bytes or more.

我们怎么定义公钥？理论上所有东西都可以表示为哈希值，当你处理公钥脚本时，森林根也只是一个哈希值。

What do we call a pubkey because in theory, every everything can be just represented as a hash when you are dealing with a pubkey and script, when you are representing a pubkey script, everything is just a hash, a forest root is just a hash.

所以我总是对此感到困惑。

So I'm always confused by this.

你可以将公钥承诺写入输出中，从而廉价地使用输出数据（或减少昂贵输出数据的使用），然后在见证中提供额外信息来证明支出权限等等——或者可能不是见证而是另一个扩展，因为现在数据量太大了，否则会大幅降低吞吐量。

You could make a commitment to a public key into the output and thereby use the output data cheaply, or use less output data that is expensive, and then provide the additional information and the witness to prove that you were authorized to spend and so forth, or maybe not the witness, but another extension because the data is so much bigger here now, otherwise that would be a huge throughput decrease.

但具体如何实现这一点可能并不那么重要，不过总的来说，对于我们执行的每个操作、花费的每个输入，我们都需要在链上存储更多数据来授权交易。

But how you implement that specifically is maybe not that important, but generally, per operation that we're performing, per input that we're spending, we would have a lot more data on chain to authorize the transaction.

是的，我想现在我们使用的签名大约是65字节，65到80字节左右，对吧？

Yes, I think right now we have like 65 byte signatures, 65 to 80 bytes something in that range, right?

而基于哈希的最小签名是304字节。

And the smallest hash based signature was 304 bytes.

实际上我一直在研究的方案，大小在800字节到3.5千字节之间。

And, actually, what I have been playing with, ranges from 800 to 3.5 kilobytes.

这些都是非常基础的版本。

These are very primitives.

他们正在研究的提案其实更优秀。

The the proposal that they have been looked at are actually better.

但如果你想使用无状态结构，那就必须面对几千字节的大小。

But, if you want to use the stateless structure, then it is going to be kilobytes.

这是肯定的。

That's for sure.

是的。

Yeah.

而无状态性非常重要。

And stateless is very important.

例如，在硬件设备上，我们无法访问内存池中的内容或之前已签名的内容，或者存储这些内容会非常困难。如果你使用某种Tails实现的钱包或其他不知道之前操作记录的签名者，我们绝对需要无状态签名。

For example, on hardware devices, we would not have access to what's in the mempool or what has been signed before, or it would be very painful to store it, and if you, for example, use some sort of Tails implement wallet or whatever where you don't know what you did before or generally have signers that don't track previous interactions, we absolutely would like stateless signatures.

嗯，Conduition并不一定改进这些操作的输出结果，而更多是优化和提升执行这些特定操作的性能。

Well, Conduition is not necessarily improving any of these, the output of these, but more so the optimization and the performance of doing these particular operations.

对于SLHDSA来说，他的性能优化方案需要数兆字节的内存和预计算，因此在硬件签名设备等资源受限环境中无法发挥作用。

So for SLHDSA, his optimizations performance wise required several megabytes of RAM and some pre computation, so it wouldn't help in these resource constrained environments like hardware signing devices.

他在文章中详细列出了多种优化手段来提升性能，包括SHA-256中间状态缓存、XMSS树缓存（这是SLHDSA使用的内部数据结构之一）。

In his post, he wrote up a bunch of different optimizations to improve performance, SHA-two 56 mid state caching, XMSS tree caching, which is one of the internal data structures used in SLHDSA.

他运用了CPU厂商提供的专用硬件指令进行硬件加速，包括向量化哈希、并行化部分哈希运算、多线程处理其他操作，甚至利用GPU和Vulkan图形编程API实现更深度的并行运算。

He applied some hardware acceleration using dedicated hardware instructions from CPU manufacturers, vectorized hashing, paralyzing some of the hashing operations, multithreading to paralyze some of the other operations, GPUs and the Vulkan Graphics programming API to further paralyze some operations.

根据他笔记中的输出数据对比或时间对比，优化后的代码能在11毫秒内完成消息签名，而他提到的最快开源库则需要94毫秒。

And the output, the data comparison or the time comparison in his notes, his code can then sign a message in eleven milliseconds while the fastest open source library he notes is ninety four milliseconds.

那就是PQClean库。

That's the PQClean library.

他的代码能在两毫秒内生成密钥，而PQClean需要十二毫秒。我还看到根据他图表上的视觉效果，验证速度也有显著提升，虽然没有具体数字，但看起来验证速度至少快了一个数量级。

His code can generate keys in two milliseconds whereas PQClean takes twelve milliseconds, and I also saw that there was a big speed up in verification according to the visuals on his chart, but I didn't see exact numbers, but it looked like at least an order of magnitude faster on verification as well.

我会

I would

我记得他在某处写道，签名验证的速度几乎与椭圆曲线签名验证一样快。

I think he wrote somewhere that the signature verification was almost as fast as the elliptic curve signature verification.

哦，实际上那是在我们的总结里

Oh, actually that's in our write up

这里。

here.

由于我们没有开启conduition，我建议大家不要只看我们的总结，他在原始帖子中引用了自己conduition.io网站上的博客文章，里面有详细说明。那篇博客还有几个月前的一篇早期文章，概述了各种基于哈希的签名方案。如果你对这类内容感兴趣，我觉得这两篇博客会很有帮助。

Because we didn't have conduition on, I would encourage folks to not just read our summary, but he has a blog post that he references in his original post to his conduition.io website that gets into the details, and that blog also has an earlier post from a few months ago, I think it was a few months ago, overviewing the different hash based signature schemes, so if you're curious about these kind of things, I think that those two blog posts would be very informative for folks.

嗯，Moon？

Yeah, Moon?

我也建议大家去看看。

I would also encourage everyone to take a look at it.

看起来组织得非常好，写得也很棒。

It looks extremely well organized, well written.

我还没时间深入研究，估计也不会去研究，但看起来确实需要投入不少时间，因为里面有很多非常复杂的内容。

I haven't had time to dig into it, I don't think I will, but it also looks like you need to really take some time because there's a lot of very complex stuff in there.

我其实很喜欢这个，相比那些关于Opryten的过滤器讨论之类的，这让我在智力上感到更加耳目一新，我更喜欢这个。

I actually love this, it's much more refreshing to me intellectually than the whole filter talk and and all that thing about Opryten, so I I like like this better.

不过，好吧，

But Well,

这标准可真是够低的。

talking about a low bar here.

是啊。

Yeah.

但关于这一切我还有一点想说。

But one more thing I wanted to say about all this.

我们讨论所有这些话题，是因为未来几年可能会出现具有密码学意义的量子计算机。

So we are we are talking about all these things because of the potentially cryptographically relevant quantum computers to appear in the coming few years.

这并非确定无疑的事。

This is not a certainty.

许多人将其视为必然会发生的事情。

A lot of people are handling it as a certainty.

我们并不确定。

We don't know.

假设我们将拥有具有密码学意义的量子计算机，比特币为此升级需要付出巨大代价。

It has a huge cost for Bitcoin to upgrade assuming that we are going to have cryptographically relevant quantum computers.

而如果这种情况并未发生，那么这些代价基本上就是白费了。

And if that does not happen, then this cost was paid for nothing, basically.

这也是我认为我们应该首先考虑有状态签名方案的原因，只有在那样的未来真正到来时，才迁移到更全面的后量子解决方案。

And that is another reason why I think we should probably consider stateful signing first and only migrate to more comprehensive post quantum solutions if that future actually unfolds.

所以我支持这样的观点：我们应该先启用基本原语，让人们能够创建量子安全的输出方案，在花费时保留选择权。

So I'm on the I'm on the side that says we should just enable the basic primitives where people can use them to create quantum safe outputs where where you have optionality at spend time.

因此你可以在花费时决定是否使用AC签名，是否要使用由后量子恶意软件签名的AC签名。

So you can decide the spend time if you want to use an AC signature, if you want to use an AC signature that is signed by a post quantum malware.

这可以是一个不同的Tap叶节点，你知道的。

This can be a different tap leaf, you know.

你可以直接揭示一个Tap叶节点，在那里你还需要提供冗长的端口签名，这效率非常低。

You you can just reveal a tap leaf where where you you also have to provide the long port signature, which is very inefficient.

这些VOTS一次性签名、互联网一次性签名效率更高，但计算量更大，顺便说一句。

These these VOTS one time signature, Internet one time signatures are much more efficient, computationally heavier, by the way.

所以端口签名计算量轻，而它则计算量更大。

So long port is computationally lightweight, mean then it is computationally heavier.

因此对每个节点来说成本更高，但在数据存储和网络传播方面成本更低。

So it's a larger cost for every node, but a smaller cost in terms of data storage and network propagation.

所以你需要权衡这些因素。

So you have to balance these things out.

但我想说的是，我认为我们首先应该为用户提供在花费时选择量子抗性方式花费比特币的灵活性。

But guess, I my point was that I believe we we first should provide people with optionality to have, a quantum resistant way to spend their coins at spend time.

所以他们可以决定，啊，我在新闻上听说有人在某处破解了160位椭圆曲线签名，并且他们证明可以用量子计算机破解。

So they can decide, a, I heard in the news that someone somewhere cracked on 160 bit elliptic curve signature, and they proved it that they could crack it with a quantum computer.

好的。

Okay.

我现在要花掉我的1000个比特币或1万个比特币，从今天开始附加某种量子抗性算法，但如果闪电通道有100万个槽位，可能关闭闪电通道的人并不在意这个。

I am going to spend my thousand Bitcoins or 10,000 Bitcoins now attaching some form of quantum hard algorithm from this day on, but maybe someone closing the Lightning channel does not really care about it if the Lightning channel is like 1,000,000 slots.

这看起来不会一下子全部发生。

That that just doesn't seem so it's not going to happen all at once.

不会让所有UTXO一下子都变得不安全。

It's not going to make every UTX auto cable all at once.

人们有不同的观点。

People have different perspectives.

我个人认为我们应该给他们自由选择权，而且我认为在完全后量子迁移发生之前，现在就应该认真研究对比特币更友好的有状态构造方案。

I personally believe we should give them the freedom, and I think we should take a hard look at, more Bitcoin friendly stateful, constructs for now before the migration happens, before the full post quantum migration happens.

这只是我对此的看法。

That that's just my take on this.

抱歉。

Sorry.

太棒了，感谢你的分享。

Awesome, thank you for that.

我正想说些非常相似的观点。

I was going to say something very similar.

我认为BIP 360目前正在进行相当大幅度的重写，正越来越接近这种无密钥路径结构的Taproot方案。这非常契合你所描述的：我们将拥有一个仅需Schnorr签名即可花费的脚本叶节点（虽然成本略高，因为需要证明该叶节点存在于树中），同时旁边还可以设置后量子叶节点作为备用选项。这样在花费时，你可以选择仅披露后量子叶节点并使用它。我之前确实没考虑过先采用有状态方案的路径，但你甚至可以同时设置包含有状态和无状态的叶节点，这会很有意思。

I think the BIP three sixty is currently again in a pretty substantial rewrite and it's getting closer and closer to this taproot without the key path construction, and I think that would very much fit into what you're describing where we would have a script leaf that is spendable just with Schnorr signatures and slightly more expensive because you have to go to the script leaf, like show in the control block that it existed in the tree, and then you would have the option to have post quantum leaves next to that, that you can fall back to, so when you spend, you can just simply only reveal the post quantum leaf and use that, and I hadn't actually considered previously the route of going stateful first, but you could even have leafs for stateful and stateless, and that might be interesting.

是的。

Yes.

是的。

Yes.

而且，而且，首要的、最重要的事情是应对长程攻击。

And, and, the first thing, the most important thing is to deal with long range attacks.

对吧？

Right?

而且，BIP 360已经处理了长程攻击问题。

And, and BIPS three sixty already deals with long range attacks.

如果所有人都迁移到BIP 360，当然，我们对于未迁移的UTXO无能为力，这很遗憾，或者说这是个非常棘手的话题，我不想深入讨论。

If everyone migrates to BIPS three sixty, of course, we can do nothing about non migrating UTXO sadly, or or that is a very difficult conversation I don't want to steer into.

但首先必须解决长程攻击问题。

But first you have to deal with the long range attack.

当短程攻击看起来可能实际可行时，就必须认真应对短程攻击了。

And when it looks like short range attacks are becoming, like, maybe possible, practically, then you really have to deal with the short range attacks.

重申一下，我认为可以先作为可选方案，然后视情况而定。

Again, I think first optionally, and then then then we will see.

一旦充分证明了可行性，我们就必须全面迁移到后量子化方案——可能是无状态的签名方案，同时再增加区块大小或采用扩展盒之类的方案，到时候再看吧。

And once, sufficient capability is demonstrated, we absolutely have to migrate a full post quantum, maybe stateless, signature scheme with another block size increase, extension box or something, we will see I guess.

太棒了。

Awesome.

Moon，感谢你参与讨论这个话题。

Moon, thanks for chiming in on that one.

我想我们可以就此结束，本周的共识变更环节就到这里，接下来我们将进入版本发布和候选发布环节。

I think we can wrap that up and thus wrap up the changing consensus segment for this week, and we'll move on to releases and release candidates.

Moon，欢迎你继续留下，如果你有其他事情要处理，我们也完全理解。

Moon, you're welcome to hang on or if you have other things to do, we understand.

本周我们有两个版本发布。

We have two release, two releases this week.

现在我把话筒交给Gustavo，他负责本周的这个环节以及'值得关注的代码'部分。

I'll turn it over to Gustavo who authored this and the Notable Codes segment for this week.

谢谢Gustavo。

Thanks Gustavo.

欢迎。

Welcome.

谢谢你，Mike。

Thank you, Mike.

谢谢你，Merg。

Thank you, Merg.

也感谢Moon和Julian在解释方面所做的出色工作。

And thank you, Moon and Julian for all the great work in explaining.

本周我们在Lightning方面有两个版本发布。

So this week we have two releases on the Lightning front.

第一个是Core Lightning 2512版，也称为'大胆无缝升级体验'，包含几个新功能：如将BIP39助记词种子短语作为新的默认备份方法、路径查找功能改进、XPAY、ping方法也得到大幅优化、新增实验性的即时通道功能，以及许多其他功能和错误修复。

The first one, Core Lightning version 2512, also called Bold Seamless Upgrade Experience, has a few new features such as BIP39 mnemonic seed phrases as a new default backup method, pathfinding is improved, XPAY, the ping method is also improved heavily, experimental just in time channels are added and there are many other features and bug fixes.

这个版本中值得注意的一个重要方面是对大型节点进行了大量性能改进。

One important thing to remark from this release is the vast array of performance improvements for large nodes.

我认为这就是为什么人们称之为Bolt无缝升级体验，因为Bolt作为一项服务，利用这些改进为大型节点带来了好处。

I believe that's why they call it the Bolt's seamless upgrade experience because Bolt's being a service that uses cord lining benefits from these improvements for large nodes.

需要特别强调的是，这些性能改进还涉及破坏性的数据库变更。

Importantly, to also add that there are breaking database changes related to these performance improvements.

因此，本次发布包含了一个降级工具，以防升级数据库时出现问题。

So this release includes a downgrade tool in case something goes wrong when upgrading the database.

但我们将在重要代码和文档变更部分更详细地讨论这一点。

But we're going to be covering that in more detail in the notable code and documentation changes section.

以上就是CoreLiving 2,512版本的更新内容。

So that covers CoreLiving version 2,512.

该版本还包含更多功能改进和错误修复，具体内容可查阅变更日志或发布说明。

There are there are many more features and bug fixes explained in the change log or release notes of this new version.

关于LDK版本0.2，这是LDK的重大更新，实验性地加入了拼接功能，新增异步支付功能，支持静态发票支付，这是经过数月甚至可能数年的开发成果，最后还包含了使用临时锚点的零费用承诺通道功能。

So for LDK version 0.2, this is a major release of LDK that adds splicing in an experimental manner, paying, serving and paying static invoices for async payments, which has been a work of many months, even maybe even years on LDK and finally zero fee commitment channels using ephemeral anchors are also part of this release.

需要注意的是，拼接功能预计将与Eclair及未来版本的Cord兼容，但异步支付实现仅适用于基于LDK的节点。

You can, it's important to note that splicing is expected to be compatible with Eclair and future versions of cord lining, however the async payments implementation will only work with LDK based notes.

另一个重要变化是API的扩展，提供了原生Rust异步API，因此部分方法已更新为同步方式运行，但还有更多改进正在路上。

There are also another important change is the expansion of the API to offer a native rust asynchronous API, So a few methods are updated to to operate in a synchronous manner, but many, many more changes right there.

以上就是发布环节的全部内容。

So that covers the release section.

Mike，有什么要补充的吗？

Merge, Mike, any any comments?

还有什么需要补充的吗？

Anything to add here?

完美。

Perfect.

我们继续讨论显著的代码和文档变更，涉及CoreLightning、LDK、LMD、BTCPay服务器以及一项BIP改进。

We move on with the notable code and documentation changes where we have corelining, LDK, LMD, BTCPay server and also a BIP improvement.

那么我们从Core Lightning 87.28开始。

So we start with Core Lightning eighty seven twenty eight.

这里修复了一个与解锁HSMD时输入的密码相关的bug，或者简单来说，就是与你的CoreLogin节点密钥相关的问题。

Here, there's a bug fix related to the password you enter when unlocking your HSMD or simply your the key related to your CoreLogin node.

过去，一旦用户输入错误的密码，HSMD会因未知消息类型而崩溃。

So previously, once a user would enter the wrong passphrase, HSMD would crash with an unknown message type.

现在这个问题已得到妥善处理，即使输入错误密码也不会导致崩溃。

Now this is properly handled so that it doesn't crash if you enter the wrong passphrase.

系统会优雅地处理这种用户错误边缘情况并正常退出。

It will simply handle this user error edge case and exit cleanly.

虽然可能不算重大改进，但对用户体验很重要——用户原本无法理解为何系统会直接退出或崩溃，而不是提示密码错误。

So not, maybe not a huge improvement but quite user facing because the user wouldn't understand why it would simply exit, it would fail or crash instead of just responding that the wrong passphrase was entered.

具体来说，这里发生的情况是它使用了write_all函数，而write_all函数缺少了wire协议长度修复前缀。

Particularly what happened here is that it was using write all and write all was missing the wire protocol length fix prefix.

因此当Lightning D从HSMD接收到错误或消息类型时，无法正确解析。

So the when Lightning D would receive the error or message type from HSMD, it wouldn't interpret it correctly.

不过write_all已被wire_sync_write取代，这样就避免了未知消息类型错误，并且这个问题得到了100%妥善处理

However, write all is replaced with wire sync write which makes it that there's no unknown message type error and this is properly 100 handled

并干净利落地退出。

and exits cleanly.

那么我们继续看Core Lightning 8,002。

So we move on with Core Lightning 8,002.

这个版本在发布说明部分有提到。

This is the one that was mentioning in the release section.

新增了一个Lightning D降级工具，当升级数据库出错时，可以安全地回退到2,509版本。

There's a Lightning D downgrade tool that is added in case there's an error when you upgrade your database, can safely downgrade it to 2,509 in case of an error.

这里没有太多要说的，只是一个100%的安全机制

So not much else to say here, just a safety mechanism 100 for

新版本。

the new release.

最后是Coralining 8,035的最后一个更新。

And finally, the last one for Coralining 8,035.

这里修复了一个长期存在的错误。

Here a long standing bug was fixed.

基本上当Coralining重启时，它会回滚最近的15个区块。

We're basically coraligning when it restarts, it will roll back the latest 15 blocks.

默认情况下是这样，但这也是可配置的。

Well, by default, that could also be configurable.

当回滚这15个最新区块时，它会重置那些已保存交易（或者说UTXO）的消费高度——

When it rolls back those latest 15 blocks, any transactions it had had saved or let's say UTXOs it had saved, it will reset the spend height of those UTXOs that

属于

were part

这15个区块的部分UTXO，由于区块回滚，这些UTXO的消费高度值将被重置为空。

of those 15 blocks, it will reset that value to null because it rolled back the blocks, so it removes the spin height value of the UTXOs that were spent in those blocks.

然而，这个bug的问题是当重启并重新同步链、下载区块时，它没有正确更新这些UTXO的消费高度。

However, the bug was that when restarting and resyncing the chain and downloading the blocks, it would not properly update the spend height of those UTXOs.

所以这个PR的核心作用是让Core Lightning现在会确保重新监视所有UTXO，包括那些被回滚且消费高度被移除的UTXO。

So basically what this PR does is that Core Lightning will now make sure to rewatch all UTXOs, including those that were rolled back and the spin height was removed.

这不仅向前修复了bug以防未来再次出现，还添加了一次性后向扫描功能，以恢复之前因该bug遗漏的所有消费记录。

So not only does that to move forward so that the bug is removed in the future, but it also adds a one time backward scan to recover any spends that were previously missed due to this bug.

举个例子，如果你上周有一个记录，某个UTXO的消费高度被置为null（因为你回滚了那15个区块），而系统未能重新监视该UTXO并更新其消费高度。

So for example, if you had a note last week, a UTXO spend height was changed to null because you had rolled back those 15 blocks and it had failed to rewatch that UTXO and upgrade updated spend height.

重启时，它现在会执行一次反向扫描，确保所有已花费的UTXO都被重新监控。

When when restarting, it will now do a one time backward scan to make sure no UTXOs spent all UTXOs are rewatched.

这里主要的问题是，Core Lightning可能会转发已经关闭的通道公告，因为它未能重新监控那些用于关闭通道的已花费UTXO。

And most the issue here caused was that Core Lightning could relay channel announcements that had already been closed because it would fail to rewatch a UTXO that was spent, that would close a channel.

什么事，默奇？

Yes, Murch?

对，你最后提到了一点，但我看资料时没注意到具体内容。当你重启一个CLN节点时，它可能会错过某个区块或公告。所以再次启动节点时，它会回退15个区块，从那里重新处理区块链和公告。为了做到这一点，它会把状态重置到15个区块前的状态，这意味着它会将通道状态的认知回退到15个区块前的状态。

Yeah, you said it towards the end, but when I read this, I missed the actual thing, so when you restart a CLN node, it might miss a block or miss announcements, so on starting the node again, it goes back 15 blocks and reprocesses the blockchain and the announcements from there, and in order to do so, would sort of reset the state to 15 blocks in the past, which would mean that it changed how it perceived channel states back to 15 blocks ago.

因此，如果CLN在这些区块中有状态变更，它实际上不会重新监视新通道，因为某种程度上它会从数据库中删除信息，然后在这15个区块的重扫描中不再重新收集这些信息。

So if CLN had a state change in those blocks, it would actually not rewatch the new channels, because the, like it sort of would remove information from its database and then not recollect it on this 15 block rescan.

所以，这看起来像是有人考虑过，为了正确处理这个问题，我们需要回滚这个状态，但随后某些处理方式与第一次相比发生了变化，导致无法以相同方式重新处理。因此，如果你在这15个区块期间有任何状态变更，就会引入与初始扫描不同的观察差异。

So, this seems like someone thought about, oh, in order to process this correctly, we need to roll back this state, but then some, something changed in how things got processed versus the first time and it wouldn't get reprocessed in the same way, so it caused, if you had any state chain during the time, these 15 blocks, would introduce some observation differences versus the original scan.

总之，看起来他们已经修复了这个问题，虽然必须承认这个bug确实有点吓人，但好在已经修复了。

Anyway, it seems like they fixed it, which is probably it's kind of scary that they had this bug, I must admit, but good that they fixed it.

是的，没错。

Yeah, exactly.

正如你在merch中提到的，这是对这个PR很好的重新表述。

As you mentioned in merch, that was a good way to rephrase this this PR.

谢谢你这么说。

Thank you for that.

那么我们继续讨论LDK4226。

So we move on with LDK4226.

这里发生了两件事。

So here two things happen.

我认为如果按照提交顺序，新增了三个明确与跳板支付转发相关的本地失败类型。

I would say if we follow in the commit order, the three new local failures are added that are explicitly related to trampoline payment forwarding.

LDK的跳板支付实现非常精简，此前尚未实现转发功能，因此新增这三个失败原因作为支持跳板支付转发的第一步。

So LDK has a very minimalistic trampoline payments implementation where forwards were not yet implemented, so three new failure reasons are added as a first step towards supporting trampoline payment forwarding.

同时还新增了一个安全机制，用于强制校验跳板洋葱路由的接收方约束条件。

As well, another safety mechanism is also added that basically enforces the trampoline onion recipient constraints.

这意味着新增了测试用例来验证跳板载荷与外部洋葱路由的匹配性，特别关注接收跳板支付时的金额和CLTV字段。

This means that tests are added to cover the validation of trampoline payloads against the outer onion and this is specifically related to the amount and the CLTV fields of received trampolines.

总之就是安全机制和整体上为LDK增加更多跳板支付支持做准备。

So just safety mechanism and overall preparation towards more support for trampoline payments in LDK.

接下来是LND $10,341的修改。

And so the next one is LND $10,341.

这里修复了一个bug：当TOR服务重启时，LND会重复添加相同的TOR洋葱地址到节点公告和getinfo输出中。

Here, a bug is fixed where basically on a restart of the TOR service, LND would re add the same TOR Onion address to the node announcement and to the get info output.

简单说就是公告和命令输出中的洋葱地址会被重复显示，对吧？

So basically the Onion address would just be duplicated in that announcement and that output of the command, right?

因此这个PR确保创建新隐藏服务时永远不会重复生成地址。

So here instead the PR ensures that the create new hidden service will never duplicate an address.

所以当TOR服务重启时，会确保不会在节点公告消息或getinfo输出中重复添加已存在的地址。

So if the TOR service restarts, it will make sure not to duplicate an address that is already present in the note announce a note announcement message or they get info output.

这其实不是什么大问题。

So not much of a this wasn't a major issue.

只是让Tor服务重启的处理方式更规范。

It's just cleaner way of of handling a a Tor service restart.

对此还有什么要补充的吗？

Anything to add here?

合并吧，Mike。

Merge, Mike.

很好。

Perfect.

我们继续讨论BTCPay服务器的6986号问题。

We move on with BTCPay server 6,986.

这里引入了一个名为'货币化'的新功能，它能让大使——即基于B2C模式的服务器用户——通过运行服务器并大量开展用户和商户入驻工作来获得收益。

So a new feature here is introduced called monetization, which is which enables ambassadors, which are B2C based server users that run a server that are doing a lot of work onboarding users and merchants.

该功能允许他们将自己的工作变现。

This feature allows them to monetize their work.

那么它是如何运作的呢？

And how does it work?

简单来说，当我作为大使，比如说在我的城市或国家为BTCPay服务器招募用户和商户时，通常会运营一个服务器，并让他们注册到我的服务器上，这样他们就能在我的服务器上创建自己的店铺。

Basically, when I'm an ambassador and I'm, let's say, onboarding users and merchants to BTCPay server in my city or my country, I will often run a server and tell them to sign up to my server so that they can create their store on my server.

该功能允许服务器管理员要求用户登录时订阅服务。

This feature allows server admins to require a subscription for user login.

这意味着用户（比如商户）在我的服务器上创建账户后，首先会进入默认的7天免费试用期，之后我作为服务器管理员可以配置入门套餐或二级套餐。

So this means that a user that creates an account on my server or let's say a merchant that creates an account on my server would enter first a default seven day free trial period and I could as a server admin then configure a starter plan or a second tier plan.

这实际上是基于我们在第375期通讯中描述的订阅功能构建的，该功能允许商户向用户定义周期性支付方案和套餐计划。

Really this builds on a feature we described in Newsletter three seventy five called subscriptions, where merchants can define recurring payment offerings and plans to users.

因此这只是订阅功能的延伸，让BitsyPay服务器的推广者能够通过这种方式将其工作变现。

So this is just a way an extension of the subscription feature allowing ambassadors of BitsyPay server to monetize their work in this way.

不过，订阅功能有默认设置，如我之前提到的，包括7天免费试用期和免费入门套餐。

However, subscription there's defaults, like I mentioned, of a seven day free trial period and a free startup plan.

但管理员可以完全按照自己的需求进行自定义设置。

However, admins can customize this in the exact way they want.

最后，对于已经拥有订阅的现有用户——抱歉，我指的是那些已经在大使服务器上拥有店铺的用户——他们不会自动加入订阅计划，不过服务器管理员可以轻松将这些现有用户迁移至新的订阅模式。

Finally, existing users that already had a subscription or excuse me, users that were already part of a that already had a store on a server of an ambassador will not be automatically enrolled into a subscription, though the server admin can easily migrate pre existing users to the new subscription model.

对此还有什么补充想法吗？

Any extra thoughts here?

很好。

Perfect.

最后一项，BIPS 2015为BIPS 54（共识清理提案）添加了文本测试向量。

So the final one, BIPS twenty fifteen adds text test vectors to BIPS 54, which is the consensus cleanup proposal.

这里为共识清理软件的四个不同部分新增了测试向量。

Here new test vectors are added for the four different parts of the consensus cleanup software.

这些测试向量是通过Bitcoin Inquisition上公开拉取请求中的BIP54实现生成的，同时还使用了包含在定制版Bitcoin Core分支中的自定义矿工测试单元来构建。

This is generated using the BIP54 implementation that is available on an open pull request in Bitcoin Inquisition and also a custom miner test unit that is included in the custom Bitcoin Core branch is also used to build these test vectors.

因此，这还包括了关于如何使用和审查这些测试向量以评估该提案的文档和说明。

So this also includes documentation and instructions on how to use and review these test vectors to review this proposal.

在三月（实际上是二月）的通讯中，变化共识部分也涵盖了这一内容，所以你可以查阅该期通讯以获取关于这些测试向量及该BIP提案的更多背景信息。

So in March, newsletter February, this was also covered in the changing consensus section, so you can check that newsletter for additional context on these test vectors in this BIP proposal.

以上就是本节以及整个通讯和节目的全部内容。

So that covers this section and the whole newsletter and show.

Merg、Mike，如果你们有任何想法请提出。

Merg, Mike, if you have any thoughts please.

是的，我们要求或强烈建议BIP在进入提案阶段前必须具备测试向量，且在最终确定前必须完成测试。拥有测试向量来验证BIP实现正确性，意味着不同实现版本更有可能相互兼容且完全符合规范。这项伟大的共识清理工作已经持续多年——它最初于2019年提出，而最近两年由Antoine Ponceau重新提交的版本进行了完善。现在有了测试向量，我认为这标志着BIP不仅完全明确了规范，而且实现起来也更容易了。

Yeah, so we require or we emphatically suggest that BIPs have test vectors before they move to proposed and they're required before BIPs move to final, so having test vectors to test that you implemented a BIP correctly means that it makes it much more likely that the different implementations of a specification are interactive, are all spec conform, and so the great consensus cleanup is moving towards, well, it's been a multi year process, it was originally proposed in 2019, there's this redo or warming it back up by Antoine Ponceau in the last two years, and with the test vectors now I think the BIP is not just completely specified, but also it's easier to implement completely.

我认为这是向真正提出激活伟大共识清理迈进的又一个里程碑。

I think this is another milestone towards being able to actually propose activation of the GREAT Consensus Cleanup.

因此，如果你对共识清理感兴趣，现在是时候更积极地发声了，应该让更多人知道并支持这项提案——在我看来，在所有软分叉提案中，它目前在采用曲线或准备曲线上是最接近成熟的一个。

So I think that if the Consensus Cleanup is something that you're interested in, it's time to get a little more verbal about it and to mention that this is a proposal people should be looking into and supporting, because I think it's by far the closest among soft fork proposals that is on the adoption curve or readiness curve.

总之，伟大的共识清理正在接近最终实现

So yeah, anyway, great consensus cleanup is getting closer to being

谢谢Murch。

Thank you Murch.

我想补充的是，如果大家对第340期通讯中的这项具体提案感兴趣，其中详细解析了该提案的各个部分——包括传统输入的SIG OPS限制、将时间扭曲宽限期延长至两小时、以及重复交易修复方案。大家可以通过查阅第240期通讯获取更多背景信息，以便全面理解这项提案的内容。

I want to add that if people are interested in this specific proposal in newsletter three forty, there was a breakdown of the different parts of this proposal which are the legacy input SIG OPS limit, the increasing the time warp grace period to two hours, duplicate and the duplicate transaction fix, so people can check out Newsletter two forty for additional context to fully understand what this proposal is about.

是的，也别忘了查看主题页面，那里有Gustavo提到的一些内容参考，以及其他相关讨论。我记得Antoine最近也在通过播客和视频向大家介绍BIP54，以及为什么我们不应将其视为比特币协议的潜在变更选项。

Yeah, and check out the topics page as well, where you see references to some of what Gustavo mentioned, among other mentions, and I think that Antoine's been out as well doing podcasts and videos with people about BIP54 and why we shouldn't be thinking about that as a potential Bitcoin protocol change.

感谢Gustavo带我们浏览了版本更新和重要代码环节。

So thanks, Gustavo, for taking us through the releases and Notable Code segment.

也感谢Murch共同主持。

Thank you, Murch, for co hosting as well.

我们要感谢Moon和Julian的参与，感谢各位听众的收听。

We want to thank Moon and Julian for joining us and for you all for listening.

干杯。

Cheers.