比特币网络监控与B10C | SLP707

所以与此同时，这件事相比比特币早期已经增长了这么多。

So at the same time, it's like this thing has grown so much compared to early days of Bitcoin.

你需要一种方式，让人们能够明显地追踪并及时了解最新动态。

You want a way for people to sort of obviously track and stay up to date on what's going on.

然后，如果需要修复，你又该如何传达这个信息呢？

And then also, if the a fix is needed, how do you get the word out?

对吧？

Right?

是的。

Yeah.

是的。

Yeah.

没错。

Right.

而我选择在PureObserver项目中采用的方式是进行被动监控。

And and the the route I choose with the with the PureObserver project is to have passive monitoring.

所以你也可以进行主动监控。

So you can also have active monitoring.

主动监控就是连接到网络中所有可到达的节点。

Active monitoring is you connect to all nodes on the network that are reachable.

就像一个间谍节点那样的东西。

Like a spy node kind of thing.

是的，举个例子。

Yeah, example.

或者它也可以是一个研究节点。

Or it could also be like a research node.

这不仅仅是间谍。

It's not only spies.

间谍这个词总带有负面色彩。

Spies always has this negative touch to it.

但我选择了被动方式，因此我在全球不同地点部署了行为良好的Pick n' Core节点和Knots节点等。

But I choose the passive route, so I have well behaving Pick n' Core nodes and Knots nodes and whatever in different locations around the world.

它们都表现良好。

They all are well behaving.

它们都表现得非常正常，就像完全标准的节点一样，我称它们为蜜罐节点。

They all behave very, yeah, like completely stock normal nodes, and I call them honeypot nodes.

所以我希望攻击者或全网范围的攻击者也会攻击我的其中一个节点，而我已经在它上面附加了一整套监控工具和基础设施，以便我们能真正了解这个节点发生了什么。

So I have the hope that an attacker or a network wide attacker also happens to attack one of my nodes, and I have just attached a bunch of monitoring tools and infrastructure to it so we can actually know what happened to this node.

我们有它的日志、数据和指标，可以了解到这个节点到底发生了什么，比如为什么它会崩溃，为什么它会变慢，或者其他情况？

We have logs from it, we have data, we have metrics from it, and we can get an idea of, okay, what what happened to this node and why why is it, for example, crashing or why is it slowing down or what else?

是的。

Yeah.

很有趣。

Interesting.

正如你提到的，我认为是在你的博客中，你说你用不同的配置运行它们。

And as you mentioned in your I believe it was in your blog, you mentioned that you run them with different configurations.

对吧？

Right?

其中一些运行在TOR、I2P和CJDNS上，还有一个使用了已知易受DDoS攻击的Bloom过滤器。

Some of them are on TOR and I two p and CJDNS, and one is got, like, you said Bloom filters known to be DOSable.

跟你之前提到的类似，能详细说说你使用的不同配置吗？

Talk us through some of the different configurations that you have Yeah.

嗯。

Yeah.

关于这个。

On this.

嗯。

Yeah.

所以我们的目标有两个。

So so the goal is twofold.

我们希望检测到外部攻击者发送了某种导致我们系统变慢的内容，比如动态服务，或者节点内部出现故障，比如某个功能存在漏洞，甚至可能是一个只有少数用户使用的功能。

So we want to detect if someone comes from the outside and sends up something we end up slowing down on, so a dynamic service, or if the node internally has a problem, like, for example, a bug in some feature, maybe not even like a much used feature, like a feature that's only used by a selected few percent on the network.

因此，我说过，为了获得良好的覆盖范围，我们需要用不同的配置运行这些节点。

So that's why I said, Okay, to have good coverage there, we want to run these nodes with different configurations.

例如，我有一些节点运行在Tor上，也有一些节点运行在I2P上。

So for example, I have nodes running on Tor, but also nodes running on I2P.

Tor和I2P都是隐私网络，还有一种叫做CJDNS的网络。

So Tor and I2P are both the privacy networks, and there is a certain network that's called CJDNS.

它并不是真正的隐私网络。

It's not really a privacy network.

它更像是一种覆盖网络。

It's more like an overlay network.

我在上面运行了一些节点。

I have some nodes running there.

目前这个网络上的节点活动并不多，但也许未来我们会看到更多使用。

There is not much activity node activity on this network right now, but maybe we're going to see more of it in the future.

正如你提到的，我有一些使用Bloom过滤器的节点，Bloom过滤器是我们现在使用的紧凑区块过滤器的前身，它们会泄露一些隐私信息，而且也被认为容易遭受拒绝服务攻击。

And, yeah, as you mentioned, I have some nodes with Bloom filters, and Bloom filters are the predecessor of the compact block filters that we have now, and they leak some privacy information and they're also known to be DOSable.

如果有人连接到你并请求大量这些过滤器，会导致速度变慢，这在拒绝服务攻击中是已知的，因此默认情况下它们是被禁用的。

So if someone connects to you and actually requests a bunch of these filters from you, know it will slow down, and that's known in DOS Director, and they're disabled by default.

很少有人运行它们。

Very few people run them.

是的。

Yeah.

但我实际上在这个节点上观察到它被攻击了，因为还有一些旧的钱包，比如旧的ShieldBuff钱包，它们尚未实现紧凑区块过滤器。

But I actually like on this node, which I run this on, I actually have seen it getting DOSed just because there are still some old wallets out there, the old ShieldBuff wallets that haven't implemented the copy block filters.

它们仍然依赖这些Bloom过滤器节点可用。

They still rely on these Bloom filter nodes to be available.

所以当一个新的Bloom过滤器节点上线时，所有这些旧钱包都会连接到它，从而以大量请求淹没它，导致拒绝服务。

So if a new Bloom filter nodes comes online, they all reach out to it and, yeah, in some way, DOS it, they overloaded with requests for these filters.

此外，我还运行了一个带有黑名单的节点，只是为了观察，如果我阻止这些已知或恶意的IP地址连接到该节点，会发生什么，以及那些未被封禁的节点又会怎样。

And, yeah, I also run, for example, one node with the band list just to see what happens to this node if I exclude these known or maliciously known IP addresses from connecting to it and what happens to the other nodes where they're not banned.

我还在一些节点上测试AES Map项目。

I'm also testing the AES Map project on it, on some of the nodes.

有些节点是裁剪过的，有些不是，有些节点为对等节点提供了大量入站连接插槽。

Some of the nodes are pruned, some of them are unpruned, some of them have, like, very many inbound connection slots available for peers.

所以，如果一个节点有500个入站连接，而正常的只有115个，且这个节点仅运行在仅同步区块模式下，没有内存池，会发生什么？

So just what happens if if one like, if if 500 inbound connections are on this node compared, to the to the normal one hundred fifteen and one node is just running in in books only mode, it doesn't have mempool.

是的。

Yeah.

你得尽量覆盖尽可能多的情况。

You you get a feeling just to cover as many grounds here as as possible.

我明白了。

I see.

嗯。

Yeah.

那么，到目前为止，你在对等节点观察项目中有什么总体的发现可以分享吗？

And so are there any overall insights that you have to share from what you've done so far on the peer observer project?

总的来说，它产生的数据量超出了一个人能处理和分析的范围，我注意到了。

So generally, it produces more data than than one person can handle in analyze, I noticed.

而且，并非所有事情都能通过被动监控来完成。

And also, like, not everything can be done with passive monitoring.

所以，如果你想研究区块传播，你还需要一些主动监控，因为这些被动节点并未连接到整个网络。

So if you want to look at, for example, block propagation, you need some active monitoring as well because these passive nodes don't connect to all of the network.

你无法获得网络上发生情况的完整样本。

You don't get a good sample of what what happens on the network.

你只能看到与你的对等节点和节点相关的本地情况，却无法获得网络的全局视图。

You only get the local view of what happens with your peers and your node, but you don't get the global view of the network.

而对于一些对研究非常有帮助的数据，如果你能获得，最好拥有网络的全局视图。

And for for some of the data that is really helpful for research, you want to have this global view of the network if you can get it.

但我认为总体上拥有它还是很好的。

But I think it's generally good to have.

反馈非常积极。

The feedback has been very positive.

希望还有其他人也在关注其他方面的监控内容。

Hope is that there is other people looking at other stuff as well to monitor.

我目前主要关注P2P相关的内容，尤其是被动监控方面，但比特币数据中还有大量其他值得研究和监控的方面，也有人正在做这些工作。

So I'm currently focusing on P2P stuff, especially on the passive stuff, but there's so much other things to look at in Bitcoin data and things to monitor for, and people are doing it.

比如，现在有人在做监控吗？比如StretchM项目，还有Pool发送的那些东西。

Like, is people now doing the monitoring, the StretchM works that Pool sent out and so on.

但没错。

But yeah.

所以 definitely 很有必要进行P2P监控，但如果我们想对整个比特币网络进行良好覆盖的监控，还有更多内容值得监测。

So definitely good to have a P2P monitoring, but there is so much more if we want to do good good to have good coverage of of general Bitcoin network monitoring.

那么，你认为哪些非P2P的内容需要被监控？或者还有哪些其他有趣的内容值得监测？

So what are the non P2P things that you think need to be monitored Or what else would be interesting to monitor?

是的，好问题。

Yeah, good question.

另外，人们一直监控的还有分叉、孤块等等。

So other thing that has been or people have been monitoring is in general, forks and vorks and stay blocks and so on.

哦，明白了。

Oh, okay.

对，对。

Yeah, yeah.

是的。

Yeah.

所以 Bitmap 的功能是运行分叉监控。

So so Bitmap's feature is running the fork monitor.

一个分叉监控工具。

A fork monitor thing.

是的。

Yeah.

对。

Right.

我还有一个类似的工具，叫分叉观察者。

And I have a similar tool called fork observer.

我的所有工具都以 observer 为顶级域名。

I all have all my tools have the observer, top domain.

是的。

Yeah.

我想这就是其中一件事。

And I guess that's one thing.

还有 stretchum.org 的东西，Mempool Space 也以某种方式监控着池子发出的内容。

And there is the stretchum.org thing and Mempool Space also has this in some capacity that they monitor, like what Pool sends out.

但没错，我觉得还有很多事情可做。

But yeah, I think there is plenty of things.

如果你看看一些东西，只要开始关注你感兴趣的领域进行监控，就会有很多容易发现和学习的低垂果实。

If you look at some stuff, there is plenty of lower hanging fruits to detect and to learn if you start to do monitoring in some area that interests you.

嗯。

Yeah.

但我现在没有一份给人们的具体清单。

But I don't have like a list of things for people right now.

从成本角度来看，做这件事需要多少花费？

In terms of costs, what does it cost to do this?

也就是说，做这件事成本高吗？还是成本低？

Like, how do you it a big cost to do this or is it a cheap cost?

因为我最初是自己搭建的，并且有项目资助，但除此之外没有其他资金支持，所以我尽量让这个项目成本最低。

So since I initially built this out myself and I have grant funding, but I don't have any other funding for it or had any other funding for it, I tried to make this as cheap as possible.

所以我认为，运行一个节点每月大约5美元，如果扩展的话，我现在大约运行着18个节点。

So I think if running one node is 5 USD per month or so, and then scaling this up, I think I currently run 18 nodes or so.

所以成本并不高，而且很多人主动表示愿意赞助其中一些节点。

So it's not too expensive, and a lot of people have stepped up and said, hey, we're going to sponsor some of these nodes.

例如，Brink 一直在赞助其中一些节点。

For example, Brink has been sponsoring some of them.

MIT DCI 也是如此，他们最初在启动阶段提供了很大帮助，赞助了Weaver的节点。

MIT DCI as well, they were initially very helpful in getting the bootstrapped, sponsoring Weaver's notes.

还有localhost research团队也在赞助一个节点。

And, yeah, the localhost research people are also sponsoring a note.

Chencode现在也在赞助一个节点，甚至一些个人也主动表示愿意提供支持。

Chencode is now sponsoring a note, and even some individuals stepped up and said, hey.

我有闲置的资源。

I have I have capacity.

我可以赞助一个节点左右。

I can sponsor, like, a node or so.

但我认为目前的瓶颈并不是启动新节点、运行新节点和维护它们，而是更在于让人们参与进来，查看数据，毕竟没错。

But I I think currently, it's not it's not the the bottleneck is not spinning up new nodes and running new nodes and maintaining them, but it's more actually getting people on board, looking at the data, but well, because Right.

作为什么进入

As what in to does

分析日志

analyze the logs

以及类似的事情。

and things like this.

是的。

Yeah.

而且还要思考新的指标来跟踪，甚至可能开发一些匿名检测框架，因为如果你现在无法处理数据，数据再多又有什么用呢？

And and and think about new metrics to track and maybe even working on some anonymous detection frameworks or so because what what does more data have you if you if you can't process it right now?

我认为下一步应该是更多地关注数据，而不是继续生产更多数据。

I think I think next step would be to to look more at more more looking at the data and not producing more data.

明白了。

Understood.

好的。

Okay.

所以跟我们聊聊你们是怎么获取这些数据的？我们现在讨论的是哪种类型的数据？比如在P2P的世界里，我们说的是INV消息、节点之间的版本协商，以及对等节点如何发现彼此这类事情吗？

So talk to us a little bit about how you're getting that like, what kinds of data are we talking about here in from a now let's say in the world of p two p, like, are we talking things like the INV message and, you know, that, like, kind of that version negotiation between nodes, like peer like, how peers find each other, this kinda this kinda thing.

我们讨论的就是这个领域。

This is the realm that we're talking about.

对吧？

Right?

是的。

Yes.

所以Pure Observer工具分为三个部分。

So the the Pure Observer tooling so at Pure Observer, I split it in in in three components.

分别是工具、基础设施和数据分析。

So tooling, infrastructure, and data analysis.

工具部分负责连接节点的不同接口，其中一个接口是BeaconCore的追踪接口，通过它我们可以很好地观察到P2P消息的交换情况。

And the the tooling is is what hooks into different interfaces of a node, and one of the interfaces is the tracing interface of BeaconCore, and from there, we can get a very good view of what P2P messages are exchanged.

例如，当连接建立时，会交换版本消息和verack消息，此外随着时间推移，还会传播地址、传播区块以及共享交易。

So for example, when the connection is opened, the version message and the verac message is being exchanged and so on, but also over time, addresses being gossiped, blocks being propagated, and transactions being shared.

但也可能包括连接的建立。

But it could also be connections being opened.

如果你观察到某个节点收到大量连接请求，这也可能是异常情况的迹象。

And if you, for example, observe a node getting a very high rate of connections being open to it could also be an indication that something is wrong.

当然，这些情况之外，交易被添加到内存池，或者交易在内存池中被替换，也是我们可以追踪并值得关注的，因为例如，一个网络攻击者可能会频繁地反复替换大量交易，这会消耗网络中所有节点的大量带宽，而我们希望发现这类行为。

So definitely these, but also just simply a transaction getting added to mempool or a transaction getting replaced in the mempool is is something that that we can track or is interesting to track because, like, for example, a network of wide attacker could do like a tech where he replaces a lot of transactions over and over and over again, which costs a lot of bandwidth for all nodes on the network, and that's something we want to see.

因此，交易被替换的情况也 definitely 是我们要关注的。

So definitely, like, transactions getting replaced as well.

为了使这些内容对听众，尤其是那些不那么深入技术细节的人更实用，我们来谈谈比特币节点的正常行为是什么，以及什么属于异常行为，比如典型的间谍节点行为或过度积极地建立连接。

So just to make this, I guess, practical for listeners, and especially people who aren't, let's say, as deep into the weeds, let's talk about what is the expected behavior for a Bitcoin node and what would be unexpected behavior or typically, like, spy node behavior or like aggressively trying to connect.

所以你能为我们描述一下，一个标准的、预期的节点应该是怎样的吗？

So maybe you could talk us through like what is like a standard expected node?

你首先应该看到哪些正常行为？

What are the normal behaviors you should see first?

然后我们可以讨论一个更具恶意或可疑的节点可能会做什么。

And then we can talk about what is like a more malicious or maybe questionable node might do.

好的。

Alright.

如果你在家运行一个节点，并且它位于防火墙后面，它会建立几个出站连接。

So if you run a home a node at home and it's behind a firewall, it's it's going to open a few outbound connections.

它会主动连接网络上的几个节点，向它们请求交易和区块，并与已连接的节点共享这些信息。

So it it's going to reach out to a few peers on the network, and it's going to ask them for transactions and blocks, and it's going to share these with the connected peers.

现在，将这与你在云服务商那里运行的、没有防火墙的节点进行比较。

Now compare that to a node you run-in, for example, a cloud provider, and it doesn't have a firewall.

因此，端口8333是开放的，任何人都可以连接到它。

So the port eight thousand eight and sixty three is open, and people can connect to it.

除了这些出站连接外，也会有其他节点连接到它，因此这个节点会收到一些入站连接。

Additional to these outbound connections, it's going to make some of the outbound connections are going to reach it as well, so it's going to be inbound connections on this node.

对。

Right.

你是可被访问的，就是这样。

You're reachable, the way it is.

对吧？

Right?

嗯。

Yeah.

在那里，它默认会接受大约114到115个连接。

There, it's it's going to accept by by default, I think, 114 or 115 connections.

这些连接会随着时间推移填满。

These are going to fill up over time.

这个云节点的IP地址会传播到整个网络，可能某个家里的节点会说：嘿，我少了一个八到十个或十一个出站连接，我要连接到这个云节点。

The IP address of this node, this cloud node is going to spread out across the network and maybe one of the nodes at home is going to say, Hey, I'm missing one of my eight or 10 or 11 outbound connections, I'm going to open a connection to this cloud node.

随着时间推移，这个云节点会填满所有入站连接的插槽。

And over time, the cloud node will fill up all all the the inbound connection slots.

所以，攻击者可以做的一件事是，他可以尝试向这个云节点打开尽可能多的连接，填满尽可能多的这些入站插槽，然后什么都不做。

So and one thing that an attacker could do is the attacker could go ahead and say, Okay, I want to open all or I want to open many connections to this cloud node, as many as possible, and fill up many of these inbound slots there as possible, and just don't do anything with it.

只是待在那里，或者不

Just sit there or don't

这就像一种恶意干扰手段。

And like a griefing method sort of thing.

是的。

Yeah.

这就是攻击者可以做的一件事。

That's one attacker could do.

它还可以连接到许多出站节点或这些云节点中的多个，然后说：嘿，把你们知道的交易数据发给我，节点会乐意这么做，但在这个过程中，它可能会暴露自己比网络中的其他节点更早知道某笔交易。

What it could also do, it could connect to many outbound or many of these cloud nodes and just say, okay, hey, send me data about transactions you know, and the node would happily do it, but then again, it might reveal while doing so that it knows about one transaction earlier than the rest of the network does.

例如，这将导致隐私泄露：攻击者可以观察网络中所有节点，发现某个节点率先广播了这笔交易，从而推断出这笔交易很可能由该节点或该IP地址最初创建。不过，我无法将UTXO与这个IP地址直接关联，而且

And this would, for example, be a privacy leak where the attacker could tell, hey, because I'm spying on all nodes in the network and I saw this node broadcast the transaction first, it's probably this node that or this IP address that initially created this transaction and, no, I can't tie the UTXO to this to this IP address, and that

据我回忆，这正是整个蒲公英协议背后的动机之一。

would be another As I recall, this is, like, part of the motivation for, like, the whole dandelion protocol thing.

我不认为dandelion方案被纳入了核心代码，但它的想法是，如果你有，比如说，

I don't think the dandelion thing made it into core, but the idea was, yeah, if you had, like,

一些，是的。

some Yeah.

遍布全球的超级节点，并且你积极地与所有人建立连接，以便找出交易首次出现的位置，然后你就可以大致 triangulate（三角定位），哦，它很可能来自这个位置。

Super nodes, like, all around the world and you were trying to aggressively aggressively connect to everybody, so you would find out where it first appeared, and then you could sort of triangulate, oh, it was very likely it came from this location.

如果这是一个家庭IP，那就完了。

And if it is a home IP, then boom.

他们已经能够通过其他信息，比如，是否可能推断出你的地址。

They already are able to figure out with a, you know, with other information, like, could they potentially figure out your address.

这显然也是一种曝光行为。

That's also obviously a doxie

或者如果这是一个大型交易所的节点，那么他们看到所有这些交易都首先从这个大型节点发出，于是他们就知道，哦，等等。

Or if it's like a big node from an exchange or so, then they see all these transactions first originate at this at this big node, and they know, oh, wait.

这笔交易实际上来自交易所X Y Z。

This transaction is actually from exchange x y z.

那么他们可以说，好吧。

Then they can say, okay.

我们可以实际上标记这个，对。

Well, we can actually tag this this Right.

这个IP地址。

This IP address.

交易所。

Exchange.

这是Coinbase的币。

This is a Coinbase coins.

这是Binance的币之类的。

This is Binance coins or whatever.

对吧？

Right?

对。

Yeah.

有趣。

Interesting.

是的。

Yeah.

当然，如今在 treasury 公司纷纷宣布‘我们刚买了这么多币’的时代，情况更是如此。

And, of course, the even now nowadays in the age of, you know, let's say, when treasury companies come out and announce, oh, we just bought this many coin.

人们试图通过链上数据来追踪，弄清楚：好吧。

Like, people are trying to, like, trace on chain to sort of understand, okay.

这些币是从哪里来的？

Where where are these coins coming from?

他们的场外交易提供商是谁？

What's their OTC provider?

他们的托管方是谁？

What what's their custodian?

人们正试图通过在后台、在底层观察这些情况，来弄清楚一些事情。

There are let's say, are things people are trying to figure out by kind of looking at these things in the background kind of under the hood.

所以，在预期行为的范畴内，你应该看到，不会。

So I guess in the realm of expected behaviors, you should see, no.

只是，你知道的，同步区块链、转发交易和区块，在需要的地方接收交易。

It's just, you know, syncing up the chain, transact you know, forwarding transactions and forwarding blocks and receiving transactions where they need to.

但在恶意行为方面，比如恶意节点或间谍节点可能会 aggressively 连接到所有人，或 aggressively 占用你的网络插槽，或即使不需要也 aggressively 索取信息，诸如此类的情况。

But then in the malicious side of things, let's say the malicious or spy node might be kind of aggressively connecting to everybody or aggressively, like, griefing your network slots or kind of aggressively asking for information even if it doesn't need it, this kind of thing.

对吧？

Right?

是的。

Yeah.

例如。

For example.

但我想我们在这样做时，正在寻找许多未知的未知因素。

But I think we're looking for While doing so, we're looking for a lot of unknown unknowns.

有人可以对你节点做的操作太多了。

There are so many things that someone can do to your node.

所以监控时，你必须关注那些未知的未知因素。

So monitoring it, you have to look for unknown unknowns.

你无法提前映射所有可能的攻击向量。

You don't know what You can't map all possible attack vectors beforehand.

明白了。

Gotcha.

是的。

Yeah.

所以你只是大致了解攻击者以前做过些什么。

So it's more just like you have some rough ideas of what they what attackers have done before

对。

Right.

但总会有他们可能尝试的新花样。

But there's always something new they could try.

或者他知道什么是正常行为。

Or he he know what, like, what normal behavior is.

如果你看到一些远远偏离基线的情况呢？

And if you see something that's way out of way out way out of the Out of the baseline?

嗯。

Yeah.

那么，好吧，这东西我需要研究或分析一下。

Then, okay, that's something I need to research or analyze.

对。

Right.

好的。

Okay.

而这通常是进入数据分析部分的常规流程。

And this is usually always the flow going into the data analysis part of it.

如果我看到一些像你说的、不在基线内的东西，我会深入查看：嘿，这真的更值得分析吗？

If I see something that's not, as you say, not in the baseline, I go into it and say, hey, is this actually worse analyzing?

这是否可能具有某种恶意或危险性？或者我们应该进一步深入调查？

Is this something that could be in some way malicious or dangerous, or should we dive deeper into it?

也许我会为此写一些博客文章，接下来的一步是：我们是否应该对此采取行动？

And maybe I write up some blog posts about it or so, and then the next step is also, should we react to it?

我们能做些什么来缓解这个问题吗？

Is there something we can do to mitigate this?

这是一种应对方式吗？

Is a way of reacting to it?

我们之前讨论过间谍节点的行为，实际上，我做的其中一个分析催生了一个拉取请求。

And we previously talked about the spy node behavior, and there's actually like a pull request that came out of one of these analyzers I did.

所以瓦西里正在做一个拉取请求，我们不再使用Dandelion，而是先通过Tor或I2P节点发送交易，然后观察它是否通过其他节点返回到我们的内存池，从而判断这笔交易是否已被广播。

So Vasil is working on a pull request where we don't do Dandelion, but we do send out transactions over Tor or I2P peers first and then see if it comes back to us and into our mempool through a through a different peer and then say, This transaction is broadcast.

我们不会首先向IPv4和IPv6节点发送交易。

We don't send it out to I p v four and I p v six peers first.

这是一种保护隐私的交易广播方式，我认为它源于我们与对等观察者项目相关的数据分析。

So that's a bit of a privacy preserving way of doing transaction broadcast, which I think originated from some of the data analysis we did with with the peer observer project.

明白了。

Gotcha.

我想知道这如何影响或受v2点对点加密的影响。

I'm curious how that impacts or is impacted by the v two peer to peer encryption.

因为我们不是从几个版本前就已经有了这个功能吗？

Because don't we already have that now as of, like, a few versions back?

所以这是不够，还是你觉得这只是某种正交的东西？

So is that, you know, not enough, or you see it as, like, that's just, like, some orthogonal thing?

对。

Right.

我认为这是完全正交的。

I I think it's completely orthogonal.

P2P v2的目的是隐藏来自ISP或能够读取所有网络流量的全球攻击者的信息。

The p two p v two thing is you want to hide from an ISP or, like, a a global attacker that can read all network traffic.

在v2之前，交换的消息通常是未加密的，而有了v2之后，这些消息就加密了。

So before v two, which tends to support, like, the the initial the the messages being exchanged were were private, and afterwards Before we do, the the message exchange were unencrypted, and with the two, they're encrypted.

因此，这可以隐藏那些坐在网络线路上的被动攻击者——他们只是记录所有网络流量——在何时何地广播了交易。

So this hides from from an attacker sitting on the wire, like a passive attacker just recording all the metro traffic sitting on the wire, this hides when the transaction was broadcast here and there.

但如果你是一个节点，并且连接到其他人，比如使用 IPv4，他们会看到：嘿。

But if you if you if you're a node and you connect to someone else, are I p v four, for example, they're going to see, hey.

这个 IP 地址来自另一个节点，比如从我的家庭节点到另一个节点。

This IP address arrived from this other node, from my home node, for example, to to this other node.

而另一个节点就能判断：嘿，这是我第一次看到这个交易。

And the other node is is is then able to tell, hey, okay, this is the first time I saw this transaction.

它一定来自 B10C。

It must be from B10C.

所以这是不同意义上的攻击者。

So different attackers in a sense.

一种是本地攻击者，另一种是全局攻击者。

So one is the Spinal attacker and one is the global attacker.

对于全局攻击者或 ISP 攻击者来说，监听节点要困难一些，因为现在协议消息的 V2 加密已经存在了。

The global attacker gotten is a bit harder for the global attacker or for the ISP attacker to spy on nodes because they're, yeah, because the V2 encryption of the protocol messages is is there now.

所以当我们讨论监听节点和其他实体时，我知道你写过一篇关于你称为 Linking Lion 的实体的文章。

So while we're talking about spy nodes and other entities, I know you did a post about this entity you named as Linking Lion.

所以给我们讲讲这个故事吧。

So tell us the story here.

我们对这个名为 Linking Lion 的实体了解多少？

What who or what do we know about Linking Lion?

是的，我最初注意到 Linking Lion，可能是因为它向网络上的所有节点发起了大量连接。

So, yeah, I first noticed Linking Lion probably because they're opening a lot of connections to all nodes on the network.

有时候，我从它们那里收到了三四个、五六个甚至七八个连接，这些连接来自不同的 IP 地址，但都属于同一个 IP 地址段，并且连接了我多个节点。

So I think at times I have three or four or five or six or seven connections from them, from different IP addresses, but all from the same IP address block, all reaching multiple of my nodes.

因此，在我所有的节点上，我都看到相同的 IP 地址段在连接我。

So on all of the nodes, I see the same IP address blocks being connected to me.

然后我开始研究：它们到底在做什么？

And then I started looking into, okay, what are they doing?

为什么它们要建立这么多连接？

Why are they opening these many connections?

它们只是待在那里，监听我的节点告诉它们的交易信息。

And they just sit there, and they listen for transactions my node tells them.

然后查看这些IP地址，发现这些IP地址都属于同一个自治系统，它们都注册在同一个实体名下。

And then looking at the IP addresses, found out, wait, actually, these IP addresses all belong to the same AS, so they all registered with the same with the same with the same party.

这个实体叫做LinkLine Networks。

This party happens to be called LinkLine Networks.

我不认为这些人就是实际操作者。

I don't think actually these are the people doing it.

我认为这些人只是提供了基础设施，因为很可能这些基础设施是租用他们的。

I think these are the people just providing infrastructure because probably the infrastructure is rented from them.

他们就像是在为进行这些操作的人提供ISP服务。

They're like an ISP for whoever is doing this.

是的，比如这种情况。

Yeah, for example.

后来发现，这些IP地址实际上出现在Craig Maxwell于2018年发布的一个封禁列表中。

And then it turns out these IP addresses actually are on a ban list Craig Maxwell published in 2018.

所以它们已经存在很长时间了。

So they have been around for a while.

然后发现这些IP地址也出现在门罗币的黑名单上。

And then it turns out these IP addresses also appear on, like, a Monero band list.

这时我就想，好吧，如果它们在比特币上存在已久，又在门罗币上长期出现，那这肯定是一家专门监控门罗币和比特币的渠道公司，我明白了。

And at this point, it was like, okay, if they appear on Bitcoin for ages and they appear the appear appear appear on Monero for ages, this must be some kind of channel business company spying on Monero and Bitcoin Oh, I see.

是的。

Yeah.

试图试图

Trying trying

Chainalysis 或者其他类似的公司，比如 Elliptic 之类的。

Chainalysis or one of these other ones, Elliptic or whatever.

具体来说，就是这个 Chainalysis 公司，但其实是某家公司

Specifically, like, this Chainalysis company, but, like like, some company

试图证明符合这个模式。

trying to prove fits the pattern.

这符合链式监控公司的特征。

It fits the pattern of a chain surveillance company.

是的。

Yeah.

所以某种程度上，他们通过整合这种多维数据——将区块链数据和交易的IP地址数据关联起来——来改进他们的产品。

So in in some way, trying to improve their products by by having this additional data, by linking, like, this multidimensional data, by having blockchain data and IP address data for transactions by linking them together.

我想，通过这样做，你可以建立一个很好的模型，来判断谁拥有哪些币，或者哪些IP地址与哪些币有过交互。

And I I guess you can you can create, like, a a good model of who owns which coins or which IP address interacted with with with which coins by doing so.

本集由CoinKite赞助播出，他们是我不二之选的比特币硬件钱包——Coldcard Q的制造商。

This episode is brought to you by CoinKite, the makers of my favorite Bitcoin hardware wallet, the Coldcard Q.

有些人觉得自托管太难了，但其实这关乎为你的比特币财富承担责任，并理解自托管能带来真正的自由感。

Now some people think self custody is too hard, but it's really about taking responsibility for your Bitcoin wealth and understanding that self custody gives you a true feeling of liberty.

Coldcard Q配备了全键盘和大屏幕，内置两个安全元件和真正的空气隔离功能，让你可以从助记词生成到交易签名全程实现完全离线操作，仅通过二维码进行交互。

The Coldcard Q has a full keyboard and big screen, it's got two secure elements and a true air gap allowing you to go fully air gapped using QR codes from seed generation to transaction signing.

你可以使用三节AAA电池为设备供电，甚至无需插墙充电。

You can power the device using three AAA batteries so you don't even have to plug it into the wall for power.

你可以轻松地将其与Sparrow Wallet（PC端）或Nunchuck（移动端）配合使用，并根据你的需求选择合适的安全级别和复杂度。

You can easily use it with Sparrow Wallet PC or Nunchuck on mobile and you can dial it into the right level of security and complexity that you choose.

如果你想要一个简单的设置，就使用12个单词的助记词和单签名。

If you want a simple setup just use 12 words and single signature.

如果你想要使用密码，也很方便。

If you want passphrases easy.

如果你想要添加多重签名或协同签名功能，这些也都支持。

If you want to add multisig or cosigning features you've got those too.

前往 coinkite.com，使用代码 LAVERRA 可享受冷钱包或其他设备10%的折扣，今天就升级你的自托管体验。

So go to coinkite.com use code LAVERRA to get 10% off on your cold card or other devices and level up your self custody today.

是的，很有趣。

Yeah, fascinating.

还有另一点，我相信你也很清楚，对于听众来说，过去乃至现在，许多公共的Electrum服务器可能也由这些链上监控公司运营，因为这是他们轻松获取信息的另一种方式：哦，原来如此。

And the other thing, as I'm sure you're well aware, just for listeners, it's known that in the past and probably nowadays, a bunch of the public Electrum servers might be run by some of these chain surveillance companies too because that's another way that they can easily find out, oh, okay.

你来自这个IP地址，并向我查询这些特定的币。

You you are coming from this IP address and you're asking me about these particular coins.

我因此推断你控制着这些币。

I'm gonna assume you control those coins.

对吧？

Right?

所以这对不知情的用户来说，是一种将他们的币暴露给链上监控公司的方法。

And so that's like a way for them for unsuspecting users to dox their coins to the chain surveillance firms.

是的。

Yeah.

所以如果你连接到一个Electrum服务器，你就会告诉他们：嘿，我这些地址上有资金。

So so if you if you connect to if you connect to an Electrum server, you're going to tell them, hey, I have funds on these addresses.

告诉我有没有资金变动。

Tell me if anything moved here.

未来，我会使用这些地址。

And in the future, I'm going to use these addresses.

你把它们一起发送过来，这样他们就能把它们关联起来。

And you send us in the same message so they then can cluster them together.

未来，我会使用这些地址来接收资金。

In the future, I'm going to use these addresses to receive funds.

你有没有看到什么？我这里收到什么了吗？

Have you seen anything on have I received anything here?

所以，对于一家链上公司来说，如果不运行一个记录一切的自定义Electrum服务器，那就太蠢了。

So it it would be pretty stupid of, like, chainless company of not not running, like, custom Electrum server infrastructure that just logs everything.

而且，我确实写了一个小项目想法，如果有人想参与开发的话。

And, yeah, I actually wrote up a small project idea if someone wants to hack on this.

你可以在节目笔记里附上链接，我写了一个小项目想法，用来找出那些行为非常相似的Electrum服务器。

Maybe you can link it in the show notes, but I wrote up a small project idea of actually finding out if there is Electrum servers that all behave very similarly.

例如，它们恰好在同一时间切换到新的区块。

So for example, they switch to a new block exactly the same time.

从这一点出发，我们实际上可以判断它是否是一个代理，以及弄清楚哪个

So from there on, we could actually tell if it's like a proxy or like and figure out which

哪些公共Electrum服务器可能是链上监控服务。

one which which of the public electrum servers are likely to be chain surveillance ones.

没错。

Correct.

是的。

Yeah.

正确。

Correct.

所以，我认为通过数据分析和监控，我们实际上可以反过来让这件事更加公开化，没错。

So we we I think with data analysis and monitoring, we can actually turn it around and make this more public and and yeah.

我还没时间去做，但我认为这是一个很棒的项目，适合有人去开发，甚至可以写成研究报告、博客文章之类的。

I haven't gotten the time to it for it, but I think that's an an awesome project for someone to hack on and maybe even, like, a research report on it or, like, a blog post or so.

有意思。

Interesting.

我想这也是更广泛问题的一部分，比如，典型的比特币支持者会说：嘿。

And I guess this is also part of the broader thing of, like, why, you know, typical, like, Bitcoiner, you know, advocates will will say, hey.

运行你自己的比特币节点，因为这样能获得更好的隐私。

Run your own Bitcoin node because you get more privacy that way.

对。

Right.

如果你在使用 Electrum，那就运行你自己的原生服务器。

And run your own Native server if you're if you're losing Electrum.

是的。

Yeah.

是的。

Yeah.

当然。

Of course.

当然。

Of course.

因此，对于那些还不愿意或无法运行自己的完整比特币节点的用户来说，也许这些紧凑区块过滤器技术，或者未来像 Floresta 这样的项目会很有意义，能让更多人快速完成自己的验证，而无需向公共的 Electrum 服务器泄露隐私。

And so maybe for that, let's say that user who is not willing or not able to run their own full Bitcoin node yet, that's where some of this compact block filter stuff or maybe in the future, who knows, like, maybe this Floresta project is gonna be interesting to get more people able to quickly, do their own validation without doxing to the public Electrum servers and things like this.

是的。

Yeah.

当然。

Definitely.

是的。

Yeah.

是的。

Yeah.

那我们来聊聊紧凑区块中继吧，因为我知道你在这方面做过一些研究和写作，这和区块传播有关。

So let's talk a little bit about compact block relay because I know this is another area you've done some research and some writing on this, and this kinda comes into, like, block propagation.

我的理解是，为了网络的去中心化，你希望区块传播具有极低的延迟，这样节点就不必手动去请求交易，而是可以自行完成。

And my understanding here is the general idea is for the decentralization of the network, you want this block propagation, you know, to be you know, you want it to be very low latency and, such that, nodes are not having to go out and manually ask for transactions that they can just, you know, do it on their own.

你能详细解释一下吗？

Can you just elaborate and explain this?

是的。

Yeah.

好的。

Okay.

让我退一步说，因为我们刚才谈到了紧凑区块过滤器，现在又谈到了紧凑区块中继。

Let me step back one step because we we just talked about block filters or compact block filters, and now we're talking about compact block relay.

我认为这些是完全不同的东西，但它们被命名得一模一样。

And I I think these are very different things, but they're named the same way.

所以，紧凑区块过滤器是BIP 158。

So Compact Block Filters, that's BIP 158.

五七和一百五十，对吧。

Five seven and one hundred fifty yeah.

是158吗？

158, is it?

对。

Yeah.

对。

Yeah.

还有152。

And 152.

所以非常令人困惑，名称相同，BIP编号范围也一样，但这是用于区块中继，而不是区块过滤。

So very confusing, same names, same number range for the bibs, but this is for Block Relay, not Block Filters.

区块过滤器是我们从关于输出和我们拥有的点的数据中获取的东西，而区块中继则是在区块被挖出后通过网络分发这些区块的过程。

Block Filters is something where we get data from about outputs and points we have, and Block Relay is where we actually distribute the blocks when they're mined across the network.

因此，对于紧凑型区块中继，其中一个想法是，在区块被挖出的过程中，你已经收到了大量交易。

So for Compact Block Relay, one the ideas is that while a block is mined, is being mined, you receive a bunch of the transactions already.

你已经在你的内存池中有了这些交易。

You already have them in your notes man pool.

现在，如果有人找到了一个区块并发送了完整的区块，其中包含所有这些交易，而这些交易会重复到达，因为你已经在内存池中有了它们。

And now if someone is finding a block and they send the full block, all of these transactions included, and these would arrive twice because you already have them in your mempool.

你就会觉得，同样的带宽被用了两次。

You're like, the same bandwidth twice.

你正在发送相同的数据两次。

You're sending the same data twice.

所以这对带宽是个问题，而且，发送完整的区块，一兆字节、两兆字节，甚至如果有大额铭文的话可能达到四兆字节。

So this is a problem for bandwidth, and also, like, sending the full block, one megabyte, two megabytes, maybe even four megabytes if there's a big inscription in it.

这只会更慢。

It just That's slower.

将整个区块在全球范围内传播比只发送一个简略的提示要慢得多，这个提示告诉你：你已经拥有这些交易，它们就在你的内存池里的这里、这里和这里。

Just sending this around the globe is very slower than just sending a small sketch of it saying, hey, you already have the transactions are in the event pool here, here, and here.

只需从中选取并尝试用这些交易构建出区块。

Just pick them up and try to construct the block from that.

所以你发送的是一个蓝图，提示说：你很可能已经拥有这些交易，它们就在你的内存池里。

So you do you you send a blueprint, say, hey, you have the transactions, probably have them already in your event pool.

尝试用你内存池中的这些交易来重建区块。

Try to reconstruct the block from from these transactions you have in your mempool.

如果这样通常能正常工作。

And if if you this this normally works fine.

这通常效果相当好。

This normally works quite well.

有时你缺少某笔交易，那就需要请求它，但这也无妨。

Sometimes you you don't have a transaction, then you need to request it, but that's also fine.

希望的是，如果网络中的内存池非常相似，那么大多数区块都不需要额外的请求。

The hope is that if the mempools across the network are very similar, then most of these blocks don't need an extra request.

如果我们不需要额外请求，这就相当于多了一次完整的往返，因为你收到一条消息，说：嘿，这里有一个新的紧凑区块，由这些交易重建而成。

If we don't need to do an extra request, this is like a whole additional round trip because you receive like the message, hey, here's a new compact block reconstructed with these selections.

如果你缺少某个交易，你就得说：嘿，我缺少这个交易。

And on the And if you don't have a transaction, you need to say, hey, I'm missing this transaction.

请把它发给我。

Please send it to me.

而在这样做时，你无法重建区块，也无法再次转发该区块。

And while doing so, you can't reconstruct the block, you can't forward the block again.

而这取决于你的对等节点有多远。

And, well, that's depending on how far away your your peer is.

它可能需要额外的约一百二十秒，而我们希望尽量减少这种延迟。

It needs, like, an extra, like, hundred twenty seconds or so, and we want to minimize this this delay.

好的。

Okay.

是的。

Yeah.

所以让我试着用简单的话总结一下，不仅为了我自己，也为了听众们。

So just let me try to recapitulate in simple terms, just, both myself and also for the listeners.

所以当你运行一个比特币节点时，你也在发送和接收你中继的交易。

So the idea is when you're running a Bitcoin node, you are also sending and receiving transactions that you're relaying.

其理念是，与其下载一个全新的区块，不如利用你已经收到的交易——因为这些交易本来就已经中继给你了，所以可以直接用它们来重建或生成区块，而无需手动请求：‘我缺少第99笔交易和第27笔交易’之类的。

And the idea is that instead of having to download a full new block, the idea is, actually, you might already have these transactions that have been relayed to you anyway, so just use that to help reconstruct or, create the block without needing to manually go and request, oh, I'm missing the ninety ninth transaction and the whatever, the twenty seventh transaction or whatever.

通过使用紧凑区块中继，你可以节省掉额外的往返过程，即不必再手动请求那些你尚未掌握的交易。

And the idea is by saving by doing this compact block relay, you're saving that extra round trip of having to go and manually ask for these transactions that you don't know about.

大致上是这样，对吧？

Is that broadly Yeah.

对吗？

Right?

对。

Yeah.

你节省了带宽，同时也普遍降低了延迟。

You're saving on bandwidth, and you're saving also, in general, on latency.

因此，你通过发送这些小型数据消息而不是巨大的几兆字节的消息，使区块传播更快。

So you're making block propagation faster because you can actually send out these small data messages and not these big, big few megabyte messages.

还有一些额外的事项。

There are a few additional things.

例如，对于某些连接，节点甚至可能在验证之前就发送紧凑区块。

So for example, to some connections, the note might send even the Compact Block before it's validated.

因此，你可能会收到一个无效区块的紧凑区块，这种情况确实可能发生，但提前发送未经验证的区块能大幅加快速度，值得这样做。

So you might receive a combat block of an invalid block that could happen, but this makes validation, sending it out before validation makes it so much faster than it's actually worthwhile doing.

是的。

Yeah.

而且

And

我想你想要表达的是，挖矿已经变得如此激烈的竞争，以至于矿池都在这么做，因为它们不想落后——即使这些微小的时间延迟也会严重影响它们的收益。

I guess the point you're getting at there is mining has become such a brutal competition that mining pools are doing this because they don't wanna lose out because even these small delays in timing can really cost them in their bottom line.

对吧？

Right?

是的。

Yeah.

这对小型矿工来说尤其如此。

And this is especially true for, like, small miners.

大型矿工找到区块的概率更高。

So a big miner has a higher chance of finding a block.

所以他们广播区块后，假设需要五秒钟才能到达小型矿工，而小型矿工在这五秒内仍在基于旧区块挖矿，无法获得任何奖励。

So they broadcast it and it takes, let's say, hypothetically five seconds to reach a small miner, the small miner would have mined on the old block, which is not going to get any reward for five seconds.

因此，大型矿工找到区块的几率更高。

So the big miners have a good or a higher rate of finding blocks.

他们找到的区块更多，所以这对他们来说问题较小。

They find more blocks, so that's less of a problem for them.

但对于那些接收新区块延迟很长的小型矿工来说，这才是更大的问题。

But for a really small miner where it takes a long while for them to reach or to receive the new block, that's the bigger problem.

这在某种程度上导致了挖矿的中心化，因为显然，大型矿工找到新区块的概率更高，因为他们能更早地基于新区块开始工作，而小型矿池则滞后得多。

And this causes mining centralization in some ways because, obviously, the big miners then have an even higher chance of finding the new block because they actually have the work of on like, they're they're building on the new block way earlier than than the the smaller mining pool.

我明白了。

I see.

那么，这现在涉及到一个因素：你认为这个因素有多重要？

And so this is coming now to how much of a I guess, much of a factor do you think that is?

比如，它是否严重到让小型矿池根本无法启动？

Like, is is it meaningful to the point that small mining pools can no longer start up?

或者说，我想从你这里了解的是，这仅仅是所谓的极客们在争论技术细节，还是这对矿池的实际商业模型有真正的相关性？

Or, like, I guess what I'm trying to get trying to understand from you is, is this just like, you know, quote, unquote, nerds arguing about technical minutiae, or how relevant is this to the actual real world business model of mining pools?

是的。

Yeah.

我觉得这介于两者之间。

I I I think it's somewhere in between.

而且，是的，我们最近也重新讨论过这个问题。

And, yeah, I think we we also revisited this recently.

所以，我们几位参与此事的PTP工程师坐下来，认真讨论了这个问题，并发布了一些相关数据。

So we we sat down and as a few or a few of the PTP engineers involved in this, we sat down and we actually spoke, talked through this, and put out some statistics on this.

我认为目前还不完全清楚这些更差的重建率。

And I think it's not 100% clear if these worse reconstruction rates.

重建率是指，如果我需要请求一笔交易，而所有操作都变慢了，这些因素是否会对实际的区块传播时间以及我们因提前发送区块（未验证）而获得的显著时间优势所导致的孤块率产生显著影响。

So reconstruction rates is if I have to request a transaction and everything is getting slower, if these actually make a meaningful or a big impact on the actual block propagation time and also on stale rates we see just because we have this sending out the block before we validate it, which is a huge gain in timings.

所以，我认为关键在于我们需要更深入地研究，实际分析哪些区块传播得快、哪些传播得慢，从而建立基于数据而非直觉和假设的模型。

So, yeah, I think the bottom line there was we need to dig a bit deeper and we actually need to look at which blocks propagate fast and which propagate slow to get an idea for Or a better database and not intuition and assumption based model allowances.

所以我认为这仍然是一个尚未完全解决的研究问题。

So I think this is even still a somewhat open research problem.

好的。

Okay.

而且

And

还有一些人争论说，这个值可能更高，那个值可能更低。

so It's also some people arguing about, oh, could be higher and this could be lower.

但同时，孤块太多也不是好事。

But also having a lot of stale blocks is not nice.

所以，是的。

So Yeah.

我想澄清一下，如果你是一个大型矿池，显然你希望拥有非常低甚至为零的孤块率，因为孤块率越高，就意味着你直接将算力投入到了一个无效的区块中。

And I guess just to clarify there, the point also there is that you want if you're a big mining pool, obviously, you wanna have a very low or zero stale rate because the more stale rate you have, that's just like directly you were point you were contributing or you were putting hash rate into a block that was not viable.

对吧？

Right?

没错。

Yep.

所以他们基本上希望最小化这种情况，或者尽可能完全避免、消除它。

And so basically they want to minimize that or avoid it completely, eliminate it if possible.

我认为不可能完全消除它，但总会有一些延迟，你希望尽量减少它。

I think it's not possible to eliminate it completely, but there's always going to be some delay, but you want to minimize it.

是的， definitely。

Yeah, definitely.

好的。

Okay.

所以，我知道你写过博客文章，还制作过完整的图表，但你能跟听众分享一下关于重建率、成功率和失败率的一些总体趋势吗？

And so can you just obviously, I know you've written like blog posts and put up whole diagrams about it, but do you have any broad trends you can share with listeners on, you know, the reconstruction rates and the success rates and the failure rates there?

可以。

Yes.

关于工作重建率，我查看了某一天内，有多少区块作为紧凑区块被发送到我的节点，其中有多少需要额外的一次往返？

With the work reconstruction rates, I just looked at for a given day, how many of the blocks that were relayed to my notes as compact blocks, how many of them needed an extra round trip?

有多少需要请求交易？

How many of them needed the transaction to be requested?

将这些数据随时间绘制成图，你会发现有些月份情况非常好，因为所有人都对他们的内存池策略达成一致。

Just plotting this over time, you see in some months, it's really good because everybody agrees on what their mempool policy is.

而显然，比如在每虚拟字节一聪的费率下，一些矿池会包含某些交易，而其他矿池或大多数节点却不包含这些交易，你就必须请求它们。

And, obviously, doing, for example, like, one Satoshi per v byte summer where some mining pools include transactions, others are not including or even nodes, the the majority of nodes are not including, you're going to need to request them.

因此，这些重建率会变得非常糟糕，直接暴跌。

So these reconstruction rates, they're going to be deep red, so they're going to tank.

总会有一些交易，至少一两笔，需要额外请求，这会导致一次额外的往返，从而使传播速度略微变慢。

There's always a transaction, at least one transaction or a few transactions you have to request, which does the extra round trip, which makes propagation just a tiny bit slower.

好的。

Okay.

你能感觉到这造成了多大的延迟吗？

Do you have a sense of how much of a delay that was causing?

我并没有这方面的数据，但这确实是一个活跃的研究课题。

I don't really have any data on this, but this is, like, an a active, like, research topic.

明白了。

Gotcha.

一般来说，这没问题。

Generally, that's okay.

网络上的事件，比如所谓的‘SubSAT夏季’，对于听众来说，我简单解释一下，如果你觉得我哪里说错了请纠正。

That events on the network such as, quote, unquote, SubSAT summer, which for listeners, there was, like, let's say, a social phenomenon of okay, so I guess I'm just gonna quickly explain it, and you correct me if I'm getting something wrong here.

但长期以来，在比特币中，人们普遍认为每字节虚拟大小1聪是最低费率。

But for a long time in Bitcoin, it was kind of just assumed that one sat per v byte was the floor.

因此，这一点被硬编码到了许多钱包和其他系统中。

And so this is kind of hard coded into a bunch of wallets and everything.

但后来，我觉得有人在推特上发了这条消息，或者讨论了这件事，这变成了一种社会现象，有人说道：嘿。

But then I think someone tweeted it or posted about this, and it it was like a social phenomena that someone said, hey.

实际上，网络上还有一些节点愿意中继低于每字节1聪的交易。

Actually, there are other peers on the network who are willing to relay transactions below one SAT per V byte.

于是这引发了一种趋势，许多矿池都降低了它们的最低中继交易费，使得费率现在低于1聪。

And then this kind of kicked off a trend where a lot some a bunch of pools all, like, lowered their min relay TX fee such that it was now below one sat.

其中一些降到0.1聪，有些则降到0.1聪后又回升到0.5聪。

And some of them were going to point one, some of them, like, went down to point one, but back up to point five.

总之，重点是，这成了一种社会现象，导致大量交易的费率突破了以往几乎被普遍视为不可逾越的1聪底线。

Anyway, the point is this was like a social phenomenon that then resulted in many, many transactions where previously one sat was just kind of unquestionably the floor for most for most things.

现在实际上有大量交易以低于1聪的费率通过了。

It was like now there were actually a lot of transactions going through at below one sat.

我这样复述得对吗？或者你还有什么要补充的吗？

Have I recapitulated it correctly there or anything you wanna add there?

没有。

No.

所以，仅仅因为所有节点都有相同的默认策略，如果你不更改默认策略，你就会继续使用一萨特的限制。

So so just because, like, the nodes all had the the same default policy in them, and if you don't change the default policy, you you you stick with the one sat we buy.

但你可以更改，或者设法将它改为零点一。

But you could have changed or you can manage to change the the to point one

配置文件。

The config.

对吧？

Right?

对于听众来说，这就像你进入你的 bitcoin.conf 文件，输入我认为是 minrelaytxfee 等于某个值。

Like, just for listeners, this is like if you go into your bitcoin dot conf file and you type in I think it's min relay TXV equals whatever.

如果你手动更改这个设置，我们这里讨论的就是这个，只是让你了解一下。

And if you manually change that, that's what we're talking about here, just so you know.

是的。

Yeah.

继续。

Go on.

而且，这种情况并不需要这样，这通常适用于不同的策略变更。

And and there is like, this this doesn't need to be, like this is generally true for for different policy changes.

所以还有机会性策略变更，还有完全RBF策略变更，对于所有这些，我们都能在某种程度上看到。

So there is also the opportune policy change, and there was the full RBF policy change, and for all of them, we see it in some capacity.

例如，对于完全RBF，矿池都——或者许多矿池，我认为超过95%的算力都在挖取完全RBF交易。

So for example, for the full RBF, the mining pools were all, or many of the mining pools, I think more than 95% of the hash rate were all mining full RBF transactions.

它只是偏离了Bitcoin Core的默认策略，而事实证明，如果你更改了节点的策略，实际上会更贴近矿池的做法，从而获得更好的紧凑区块重建率。

And it just deviated from the default policy in, for example, Bitcoin Core, and it turns out if you change the policy on your node, you're actually better aligning with what the mining pools do, and you get a better or you can get better compact block reconstruction rates.

显然，这并不是我们唯一想要优化的东西。

Obviously, that's not the only thing we want to optimize for.

这并不是万能钥匙，但重要的是要记住，紧凑区块传播是快速的，或者区块传播

That's not the holy grail, but it's it's important to keep in mind that compact block propagation is is fast or a block

传播，你所指的正是，在完全RBF的情况下，这可以说是矿工主导的。

propagation that a little, it's what you're getting at there is that in the case of full RBF, that was arguably kind of mining led.

实际上，并不是Core主动更改了默认设置。

It wasn't actually Core who kind of came out and changed the default.

是矿工们意识到，也许彼得·托德或其他人正在推动全RBF这个想法。

It was that, you know, the miners had either realized that maybe Peter Todd or someone was kind of pushing that idea of, full RBF.

然后因为网络上已经实际在使用，所以当时Core更改了默认设置。

And then because it was already in practice on the network, then at that time, Core changed the default.

是的，就我记忆所及，这大概是在2022年底左右。

And, yes, at that time, off the top of my head, I think this is, like, late twenty twenty two ish around there.

当时有几个人反对这一做法。

There were a few people in opposition of that.

像约翰·卡瓦略或BitRefill的谢尔盖等人就反对这个改变。

So people like John Carvalho or Sergei from BitRefill were against that.

我认为MoonWallet团队也不喜欢这个变化，但最终大家觉得，网络趋势就是如此。

And I think the MoonWallet guys also didn't like that, but I think it eventually was seen like, the network is just going this way.

我们只能接受它。

We're just gonna have to deal with it.

你对此有什么补充吗？或者关于这个背景的其他看法？

Do you wanna add anything there or on the kind of, I guess, the context around that?

我认为，是的，如果网络的很大一部分都在使用，那么切换为默认设置是有道理的，或者更新网络大部分节点的默认设置也是合理的。

I think, yeah, I think it makes sense to switch to a default if a huge part of the network does it or update default of a huge part of network makes it.

这总会带来一些摩擦，因为有些人可能依赖这种机制来构建他们的基础设施，或者有些人不喜欢在交易中包含多个OP_RETURN，或者交易中包含更大的OP_RETURN。

There's always definitely friction there because some some people maybe relied on this for their infrastructure or maybe some people don't like having multiple op returns in in in their in their transactions or, like, bigger op returns in the transaction.

因此，进行这些更改时总会存在一些摩擦。

So there's always going to be some some friction doing these changes.

但没错。

But yeah.

需要优化的不同方面。

Different different things to optimize for.

是的。

Yeah.

但从观察和分析的角度来看，你有没有注意到，比如在全RBF的情况下，或者当时你有没有做过一些相关的统计，哪怕是在全RBF时期？

But I guess from an observation and analytical standpoint, did you notice that when it was like, so let's say in the full RBF case or even were you you doing some of these stats even back then in the full RBF days?

是的。

Yeah.

我想我有一些数据。

I I think I have some of them.

是的。

Yeah.

是的。

Yeah.

好的。

Okay.

那么我很好奇。

So I'm curious then.

你会说，当矿工们只是在他们自己的层面这样做，而不是在核心默认级别时，紧凑区块重建率较低，而当核心更改默认设置后，重建率上升了，这种说法公平吗？

Would you say would you say it's fair to say that when the miners were just doing it on their side, not at the core default level, Compact block reconstruction rates were lower, and then after core changed the default, they went up.

是的。

Is that Yeah.

这个说法公平吗？

A fair statement?

所以我运行了几个具有不同配置的节点。

So I I did I I ran different nodes with different configurations there.

例如，我运行了一个完全启用RBF的节点，在相同的时间段内，这个节点重建这些区块的成功率要高得多。

So I ran one node with, for example, full RBF enabled, and this node, over the same time span, had a much better rate at reconstructing these blocks.

这清楚地表明，完全启用RBF是问题所在，但你也可以通过观察哪些交易需要从对等节点请求来发现这一点：如果你能判断，这个交易实际上是一个完全RBF替换，而我之前没有见过它，因为我拒绝了它。

So this clearly indicated that the full RBF was the problem here, but you can also see this from just looking at what's which transaction need to be requested from the peer by if you can tell, this transaction actually is a full RBF replacement, and I haven't seen it before because I rejected it.

或者我见过但因为不支持完全RBF而从我的内存池中拒绝了它，你也可以从那里获取到这些信息。

Or I have seen it and rejected it from my mempool because I wasn't allowing full RBFs, and then you can also get it from there.

拥有多个节点并能够以不同配置运行它们，使得这件事容易多了。

Having multiple nodes and being able to run them in different configuration makes this much easier.

好的。

Okay.

那么谈到更近一些的辩论或争论，比如子集夏季（Subset Summer）是一个有趣的议题，还有op_return的限制或默认值变更。

And so bringing it to the more recent, let's say, debates or arguments, I guess, the subset summer is an interesting one and also the op return limit or default change.

所以你在子集夏季这个问题上注意到了什么模式？据我回忆，你提到过同样的情况。

So what pattern did you notice there on the, let's say, on the subset summer, I as as as I'm recalling, you were saying there was that same dynamic.

对吧？

Right?

比如，矿池首先发生了转变。

Like, mining pools had shifted first.

区块重建率下降了，也就是我们所期望的好的情况减少了。

Block reconstruction rates went down in terms of, you know, the good, like, what we want.

然后，随着越来越多的人开始更改自己的设置，你会说区块重建率回升了吗？你观察到了什么？

And then after it became or at least after more and more people started changing their own setting, would you say the block reconstruction rate came back up, or what are you seeing?

当我把我的监控节点切换到不同配置时，我注意到了这一点。

I I saw it when I switched my monitoring notes into a different configuration.

所以，当我开启或采用更低的默认值（如DPR），或者当我将节点配置切换为更低的默认值时，我可能在第二天就立即注意到了。

So if I when I turned on or when I included DPR for the lower default, for example, or when I switched my nodes configuration to a lower default, then I saw it immediately maybe on the next day or so.

当我的内存池中包含低费率交易时，我能够以极高的成功率重建这些区块，而无需请求额外的交易。

When I had the lower fee rate transactions in my mempool, I was able to reconstruct these blocks with a very higher success rate without needing to request an additional additional transaction.

很有趣。

Interesting.

是啊。

So yeah.

所以你的意思是，这确实对区块传播和区块重建率产生了影响。

So you're saying it really did make a difference on block propagation and the block re block reconstruction rates.

没错。

Right.

确实如此， definitely 产生了影响。

It it definitely it definitely did.

它提高了重建率。

It improved the reconstruction rates.

而且，我们也不完全确定这是影响区块传播的唯一且最主要的因素。

And then again, we're not 100% sure that this is the only and the biggest factor of plot propagation.

所以我们认为有各种不同的因素会影响

So we think there there's there's different different things affect

因素。

factors.

嗯。

Yeah.

嗯。

Yeah.

好的。

Okay.

说得有道理。

Fair fair enough.

我只是在思考这背后的影响。

So I'm just trying to think through the implications.

所以，是的。

So then yeah.

那么，在op_return的情况下，你有没有注意到什么？还是觉得op_return太少了，根本没产生影响？

Now in the, you know, op return case, did you notice anything there, or do you think it was just too, like, there weren't enough op returns that it made a difference?

我觉得情况是一样的。

I think it was the same thing.

我不记得具体有多少个，我觉得我们没看到太多这种特别大的 OP_RETURN，甚至同一个交易中多次出现 OP_RETURN 的情况也不多，但只要有其中一个，就需要额外的往返通信。

I don't recall how many of I don't think we saw many of these really big op returns and even not many of the multiple OP returns in the same transaction, but just having one is enough for needing the extra round trip.

所以切换之后，也显示出性能有所提升。

So switching it over also showed that it improved.

有意思。

Interesting.

一般来说，如果网络上存在更宽松的中继策略，而你的节点采用更严格的策略，拒绝了一些内容，这总会造成影响，因为你总是需要请求那些你的严格策略拒绝了、但网络上更宽松的策略允许的内容。

Generally, if there is if there's something like a broader policy, if you have a broader relay policy active on the network and you have a stricter policy, you reject some stuff on your node, it's always going to make a difference because you're always going to have to request stuff that your stricter policy rejected, but the broader network policy allows.

即使是微小的策略差异也会有影响。

So Or minor policy even.

好的。

Okay.

是的。

Yeah.

所以，我想把这个问题和一些网上至今仍在争论的观点联系起来，比如，现在 Knott 派的人可能会认为，也许他们会辩称不会。

So and I guess bringing it to some of the kind of arguments online about, you know, even nowadays, the people in the Knott's camp would see that as maybe the maybe they they would argue no.