p2p: Evict outbound peers with high minFeeRate #28488

naumenkogs · 2023-09-15T09:28:31Z

See issue #28371

Having no peers with sufficiently broad mempool limits may prevent our low-fee transactions from propagating, even though they would seem perfectly valid for us locally.

Having too few such peers may cause privacy leaks.

We should periodically check that we have sufficient peers with mempool limits comparable to ours.
If that's not true, we should evict some high-minFeeRate outbound peers to make room for a new peer with hopefully broader limits.

DrahtBot · 2023-09-15T09:28:34Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	vasild

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#29415 (Broadcast own transactions only via short-lived Tor or I2P connections by vasild)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

src/net_processing.cpp

darosior

I don't think it's as simple as disconnecting from peers with a minfee filter X% larger than ours. A minfee filter X% larger doesn't mean the peer's mempool is X% smaller. Take a simple extreme example: our mempool is filled with 299MB of >10sats/vb txs, and 1MB of 1sats/vb transaction. Out peer sets -maxmempool=299. It advertizes a minfee filter >=10sats/vb. That's at least 10 times ours, but we really shouldn't disconnect it.

What i was thinking about with my suggestion in #28371 was to get a conservative maximum size of the peer's mempool based on their advertized minfee filter and our own mempool. And disconnect it if it's unreasonably small. (Like 80% smaller than our own -maxmempool.)

src/net_processing.cpp

naumenkogs · 2023-09-18T07:21:01Z

@darosior m_total_fee / totalTxSize (instead of GetMinFee()) would kinda solve the example you point out, but it's not perfect either. I agree that what you suggest is ideal. I just haven't found a way to apply other peer's minfeerate to our mempool in a reasonable way.
Maybe this:

Every time we consider evicting (say every hour), traverse through our mempool and apply the peer's minfeerate, then see how many transactions are dropped. (A slightly optimized way would be to use a binary search to find at what exact feerate we're at 80% of mempool size — that would be faster, and also will better apply across peers).

Is that roughly what you're thinking about?

ariard · 2023-09-18T15:26:46Z

If that's not true, we should evict some high-minFeeRate outbound peers to make room for a new peer with hopefully broader limits.

I think this is coming with the downside of dropping outbound peers, which might be otherwise stable and fast block-relay peers. If an adversary is able to discover our 8 full-relay peers and drop high-feerate conflicting transactions in their mempools, we’ll evict those peers, potentially opening new outbound slots to puppets controlled by the adversary.

I don’t know if a better direction would be to announce the local maxmempool at p2p connection, sounds this is less prone to manipulation by external peers flowing high-feerate transactions in a targeted fashion.

naumenkogs · 2023-09-19T06:33:34Z

@ariard

If an adversary is able to discover our 8 full-relay peers and drop high-feerate conflicting transactions in their mempools, we’ll evict those peers, potentially opening new outbound slots to puppets controlled by the adversary.

I'm not convinced this is a problem yet. If you assume an attacker can easily take new outbound slots, then our peers might belong to an attacker in the first place... Outbound peer eviction should not be too cheap (say, an attacker should not be able to roll a hundred of peers in a day), but for that I think algorithm can be tuned.

I'm not 100% sure I understand your precise attack scenario. Let's say mempools are equal-size and half empty. What it will take for your attack to force at least one eviction? In fees and capital locked, I guess (dropping the spying effort for now).

I don’t know if a better direction would be to announce the local maxmempool at p2p connection, sounds this is less prone to manipulation by external peers flowing high-feerate transactions in a targeted fashion.

Doesn't it have a similar risk? Feed those peers with high-feerate conflicts and they won't be able to accept txs from my mempool, even though everything seems fine? They won't be dropped, but the relay won't work, at the same cost.

Having no peers with sufficiently broad mempool limits may prevent our low-fee transactions from propagating, even though they would seem perfectly valid for us locally. Having too few such peers may cause privacy leaks. We should periodically check that we have sufficient peers with mempool limits comparable to ours. If that's not the case, we should evict some high-minFeeRate outbound peers to make room for a new peer with hopefully broader limits.

ariard · 2023-09-19T14:40:29Z

Outbound peer eviction should not be too cheap (say, an attacker should not be able to roll a hundred of peers in a day), but for that I think algorithm can be tuned.

I think this is where in my mind this PR is affecting the reliability of our outbound peers topology, as CheckForLimitedMempoolAndEvictPeers() will kick out outbound peers with high-feerate every 60s so at max 1440 outbound peers per day. Assuming we have 50k reachable nodes in the network, it will take a month to browse the whole outbound peers space. If an adversary can control a minimal number of peers in this 50k set, it sounds after a bit more than a month our whole outbound peer topology could be controlled. I agree the algorithm can be fine tuned to slow down the peers worst-case roll up.

What it will take for your attack to force at least one eviction?

We assume 1 MB of max mempool size, both locally and for our outbound peers. The adversary broadcasts "set A" 500 parents at 1 sat/vb of size 100 KB (0.5 MB) in our outbound peers mempools, and then simulatenously broadcasts "set B” 500 parents at 1 sat/vb of size 100 KB (0.5 MB), the 500 parents A conflicting with the 500 parents B. Then the adversary broadcast a "set C" of 500 child at 3 sat/vb of size 100 KB (0.5 MB) in our outbound peers mempools, and then simultaneously a "set D" of 500 child at 1 sat/vb of size 100 KB (0.5 MB).

When the adversary broadcast one more transaction at 1 sat sat/vb, our outbound peers mempool min fee should jump to 2 sat/vb (descendant score of set A txn) and our local mempool min fee should jump to 1 sat/vb (TrimToSize()), our outbound peers will be disconnected due to high minFeeRate. Fees cost for the adfversary is in the order of 0.02 BTC if my maths are correct.

I agree the cost for the adversary is significant if you assume outbound peers are using default setting (300 MB so 6 BTC), and might not be opportun unless you're eclipsing a high-loaded Lightning node's chain view. Still the interdependency if added, doesn't sounds great.

Doesn't it have a similar risk? Feed those peers with high-feerate conflicts and they won't be able to accept txs from my mempool, even though everything seems fine?

With this direction, you would only disconnect based on the maxmempool announced, not the seen fee filters. Of course, there is similar risk of transaction propagation issue interference, though at least you're not loosing full-relay peers that are good for the honesty of your chain view, I think.

vasild

Concept ACK

What about triggering this only if it is needed - if we have such a low fee transaction of ours that we want to broadcast? Otherwise it looks like we will be kicking peers unnecessary (a low fee local tx may never be created).

Could this partition the network, having big mempools on one side and small mempools on the other side?

vasild · 2023-09-20T08:25:32Z

src/net_processing.cpp

+    // Ideally we want to compare mempool sizes, not fee filters.
+    // Otherwise we easily get confused: e.g. at empty mempools this is less
+    // critical, but that'd be impossible to account for.
+    const auto our_min_feerate = WITH_LOCK(m_mempool.cs, return m_mempool.GetMinFee());


I don't get it why it is better to compare mempool sizes.

If the peer's minfee is larger than the tx fee, then the tx will be dropped by that peer (irrelevant of their mempool size)

If the peer's minfee is smaller than the tx fee, then the tx will be accepted by that peer (irrelevant of their mempool size).

No? I see how the mempool size affects minfee, but is it not minfee what we care about?

Now I realize that the assumption here is that we don't have yet a problematic low-fee local tx that we cannot broadcast. In that case, yes, I agree that the best approach is to compare the sizes of the mempools.

vasild · 2023-09-20T08:35:26Z

src/net_processing.cpp

+            if (tx_relay->m_fee_filter_received) {
+                peer_fee_filters.push_back(std::make_pair(pnode, tx_relay->m_fee_filter_received.load()));


This looks like a boolean and got me confused "if fee filter has been received". It is actually an integer. When dealing with atomics it is better to read once into a local variable and later refer the local variable to avoid the value changing in the meantime.

Suggested change

if (tx_relay->m_fee_filter_received) {

peer_fee_filters.push_back(std::make_pair(pnode, tx_relay->m_fee_filter_received.load()));

const auto minfee = tx_relay->m_fee_filter_received.load();

if (minfee > 0) {

peer_fee_filters.push_back(std::make_pair(pnode, minfee));

vasild · 2023-09-20T08:40:44Z

src/net_processing.cpp

+
+    if (peer_fee_filters.size() == 0) return;
+
+    std::sort(peer_fee_filters.begin(), peer_fee_filters.end());


Is this sorting by the CNode* pointers instead of the fees? https://en.cppreference.com/w/cpp/utility/pair/operator_cmp
Looks like it would only compare the fees if the pointers are equal.

If std::map<CAmount, CNode*> is used, then this std::sort can be dropped.

Wouldn't it make sense to sort this only if our threshold is met? It seems that the only reason why this is sorted is so we can pick the highest fee filter, but we only need this if (around_our_percent_fee_filter < 4)

vasild · 2023-09-20T08:41:37Z

src/net_processing.cpp

+    std::sort(peer_fee_filters.begin(), peer_fee_filters.end());
+
+    for (auto [node_id, fee_filter] : peer_fee_filters) {
+        if (fee_filter == 0) ++around_our_percent_fee_filter;


This line can be dropped, only elements with != are added to peer_fee_filter.

instagibbs · 2023-09-20T17:29:12Z

Maybe we want to look at peers that aren't announcing a lot of INV relative to other peers of the same type and use it as some sort of apples-to-apples tie breaker? I'd be extremely careful of self-partitioning if we've already found what we believe to be useful outbound peers for blocks.

naumenkogs · 2023-09-21T13:14:51Z

@ariard

With this direction, you would only disconnect based on the maxmempool announced, not the seen fee filters. Of course, there is a similar risk of transaction propagation issue interference, though at least you're not losing full-relay peers that are good for the honesty of your chain view.

My point was that even though you continue to receive blocks, the same exact cost (6 BTC or whatever) would apply to censoring transactions (through spamming peer's mempool) seamlessly. However, with my patch, an attacker has to repeat it until all outbound connections are occupied. With your patch, it's a one-time cost (assuming no other fix is applied). Right?
I agree we should continue comparing these two solutions.

@vasild

What about triggering this only if it is needed - if we have such a low-fee transaction

With time-sensitive transactions, I think you don't want to deal with it at the last moment. Although you're right, we should be careful with adding structure to the network. That's why my initial policy was 4 peers should have a similar mempool, but I'm open to discussing it.

@instagibbs

That would be partitioning based on latency instead of just mempool size... Is it any better?

ariard

My point was that even though you continue to receive blocks, the same exact cost (6 BTC > or whatever) would apply to censoring transactions (through spamming peer's mempool)
seamlessly. However, with my patch, an attacker has to repeat it until all outbound
connections are occupied. With your patch, it's a one-time cost (assuming no other fix is
applied). Right?
I agree we should continue comparing these two solutions.

So I think mempool partitioning attack is a sufficient concern to weigh in the design of outbound peers eviction based on low-mempool limits. From my understanding you have few ways to implement it:

current solution: on the received bip133 feefilter and some margin
proposed solution 1: extend p2p protocol to announce mempool size (i.e make maxmempoolsize) a p2p parameter
proposed solution 2 (instagibbs) iiuc: based on the INV traffic received or as a tie-breaker only about current solution

I think all solutions can be targeted by mempool partitioning attack, the difference between the first solution (feefilter-based) and the second one (maxmempoolsize) sounds low-limit mempool (and as such higher feefilter) sounds cheaper in satoshis amount has to locked up in the mempool. It sounds the same one-time cost or repeating the partitioning the peer for each full-outbound peer, as here the adversary constraint is the real value in satoshi that has to be locked up no, it can be reused for each partition ?

Beyond Lightning nodes and time-sensitive transactions, I think miners mempools can be a source of concern, they need to receive new blocks while at the same time be informed of the best transaction feerate. If all their transaction-relay peers can be hijacked based on mempool-limits eviction, I believe you can downgrade their marginal income.

ariard · 2023-10-03T16:43:11Z

src/net_processing.cpp

+    size_t around_our_percent_fee_filter = 0;
+
+    m_connman.ForEachNode([&](CNode* pnode) {
+        if (!pnode->IsFullOutboundConn() || pnode->fDisconnect) return;


Currently we have at max 2 block-relay-only connections (MAX_BLOCK_RELAY_ONLY_CONNECTIONS) and 8 full-relay connections, whatever of the eviction frequency and fee differential that can be adopted as parameters to known when to severe an outbound connection, I think it would be good to have more than 2 outbound block-relay peers strictly protected.

One protection heuristic I believe can be to pick-up randomly 2 more IsFullOutboundConn() on their sockets and mark them as protected from CheckForLimitedMempoolAndEvictPeers.

dergoegge · 2023-10-12T12:51:23Z

src/net_processing.cpp

+
+        if (auto tx_relay = peer->GetTxRelay(); tx_relay != nullptr) {
+            if (tx_relay->m_fee_filter_received) {
+                peer_fee_filters.push_back(std::make_pair(pnode, tx_relay->m_fee_filter_received.load()));


Pretty sure you need to call pnode->AddRef() before storing it in the vector and Release() at the end of CheckForLimitedMempoolAndEvictPeers for each CNode you stored. This can otherwise result in use-after-free, when a CNode is disconnected and deleted from a different thread after the ForEachNode loop.

I think in practice this won't happen because cs_main is locked but that looks accidental.

dergoegge · 2023-10-12T13:03:09Z

src/net_processing.cpp

+    size_t around_our_percent_fee_filter = 0;
+
+    m_connman.ForEachNode([&](CNode* pnode) {
+        if (!pnode->IsFullOutboundConn() || pnode->fDisconnect) return;


Disconnection is already filtered in ForEachNode

Suggested change

if (!pnode->IsFullOutboundConn() || pnode->fDisconnect) return;

if (!pnode->IsFullOutboundConn()) return;

dergoegge · 2023-10-12T13:41:44Z

test/functional/p2p_out_eviction.py

+    def mock_forward(self, delta):
+        self.mock_time += delta
+        self.nodes[0].setmocktime(self.mock_time)


Since #28199 we have bumpmocktime, so you can just call self.node[0].bumpmocktime(delta).

dergoegge · 2023-10-12T13:50:49Z

src/net_processing.cpp

@@ -5194,6 +5197,62 @@ void PeerManagerImpl::CheckForStaleTipAndEvictPeers()
    }
 }

+void PeerManagerImpl::CheckForLimitedMempoolAndEvictPeers()
+{
+    LOCK(cs_main);


Why is cs_main locked for all of this?

dergoegge · 2023-10-12T13:53:47Z

src/net_processing.h

+     * transactions constructed according to our mempool. Otherwise, the lower-fee transactions
+     * will never be relayed to the network.
+     */
+    virtual void CheckForLimitedMempoolAndEvictPeers() = 0;


This does not need to be part of PeerManager's public interface (unless you add unit tests).

sr-gi · 2023-10-11T18:01:57Z

src/net_processing.cpp

+    size_t around_our_percent_fee_filter = 0;
+
+    m_connman.ForEachNode([&](CNode* pnode) {
+        if (!pnode->IsFullOutboundConn() || pnode->fDisconnect) return;


pnode->fDisconnect shouldn't be needed here. CConnman::ForEachNode already filters based on CConnman::NodeFullyConnected, which checks !pnode->fDisconnect

sr-gi · 2023-10-11T19:07:30Z

src/net_processing.cpp

+
+    if (peer_fee_filters.size() == 0) return;
+
+    std::sort(peer_fee_filters.begin(), peer_fee_filters.end());


Wouldn't it make sense to sort this only if our threshold is met? It seems that the only reason why this is sorted is so we can pick the highest fee filter, but we only need this if (around_our_percent_fee_filter < 4)

sr-gi · 2023-10-11T19:20:54Z

src/net_processing.cpp

+
+        if (auto tx_relay = peer->GetTxRelay(); tx_relay != nullptr) {
+            if (tx_relay->m_fee_filter_received) {
+                peer_fee_filters.push_back(std::make_pair(pnode, tx_relay->m_fee_filter_received.load()));


Do we really need to store this in a vector and loop over it later? If the goal is to evict a single peer, can we not just perform the comparisons here?

Instead of storing every <CNode*, CAmount> pair we just store the one with the highest filter, starting with the first we see and comparing any other that matches our criteria. That way we don't have to:

Loop twice

Store all the relevant pairs

Sort the vector to pick the highest fee filter peer

Given @vasild's comment (https://github.com/bitcoin/bitcoin/pull/28488/files#r1331255189) this should just be replacing the current highest fee filter, or if (CFeeRate{fee_filter} <= our_min_feerate) ++around_our_percent_fee_filter

sr-gi · 2023-10-11T19:24:10Z

src/net_processing.cpp

@@ -5194,6 +5197,62 @@ void PeerManagerImpl::CheckForStaleTipAndEvictPeers()
    }
 }

+void PeerManagerImpl::CheckForLimitedMempoolAndEvictPeers()


I wonder how would this interfere with #28538 and whether this logic should be part of CConnman::GetExtraFullOutboundCount instead.

sr-gi · 2023-10-11T19:36:45Z

test/functional/p2p_out_eviction.py

+        peers = []
+        for id in range(8):
+            peers.append(node.add_outbound_p2p_connection(P2PDataStore(), p2p_idx=id, connection_type="outbound-full-relay"))


nit: You can simply inline this:

Suggested change

peers = []

for id in range(8):

peers.append(node.add_outbound_p2p_connection(P2PDataStore(), p2p_idx=id, connection_type="outbound-full-relay"))

peers = [node.add_outbound_p2p_connection(P2PDataStore(), p2p_idx=id, connection_type="outbound-full-relay") for id in range(8)]

sr-gi · 2023-10-11T19:46:49Z

test/functional/p2p_out_eviction.py

+import time
+
+from test_framework.blocktools import (
+    create_block,
+    create_coinbase,
+)
+from test_framework.messages import (
+    msg_pong,
+    msg_tx,
+    msg_feefilter,
+)
+from test_framework.p2p import (
+    P2PDataStore,
+    P2PInterface,
+)
+from test_framework.test_framework import BitcoinTestFramework
+from test_framework.util import assert_equal, check_node_connections
+from test_framework.wallet import MiniWallet


A lot of these are not being used:

None from blocktools

msg_pong, msg_tx from messages

P2PInterface from p2p

MiniWallet from wallet

sr-gi · 2023-10-11T19:49:05Z

test/functional/p2p_out_eviction.py

The code path of not reaching the limit of outbound connections but reaching the threshold of peer over the fee filter limit is not being tested (i.e. GetExtraFullOutboundCount > 0 and around_our_percent_fee_filter < 4)

sr-gi · 2023-10-12T15:10:25Z

test/functional/p2p_out_eviction.py

+        peers[4].send_and_ping(msg_feefilter(10))
+        node.mockscheduler(60)
+        self.mock_forward(60)
+        self.wait_until(lambda: len(self.nodes[0].getpeerinfo()) == 7, timeout=10)


If we are going to be opinionated about what peer is being evicted (the one with the most restrictive filter) it may be worth setting up the test so we can check that is the case.

sr-gi · 2023-10-12T16:33:10Z

test/functional/p2p_out_eviction.py

+        # Set one more filter, but make it borderline acceptable.
+        peers[4].send_and_ping(msg_feefilter(81))
+        node.mockscheduler(60)
+        check_node_connections(node=node, num_in=0, num_out=8)


I think this is wrong. Setting the filter for the fifth node is already triggering the eviction. You can check by just adding self.wait_until(lambda: len(self.nodes[0].getpeerinfo()) == 7, timeout=10) here. Looks like there is a race between the peer being marked for disconnection and the check being performed.

This is mainly because setting the filter to one additional peer makes the threshold to be met. Also, I don't think 81 is borderline acceptable, that is actually the highest filter you have set so far.

instagibbs · 2023-10-12T16:37:35Z

That would be partitioning based on latency instead of just mempool size... Is it any better?

I'm not sure I get the question. We should think very carefully about messing with outbounds that are otherwise deemed important for avoiding chainsplit reasons

mzumsande

I think it would be good to have some kind of limiting factor (maybe by fee estimation for a reasonably large target?) so that if someone decides to run with a much larger mempool size than the default, they don't keep on dropping outbound peers that run with the default. Otherwise they could spend a long time circling through outbounds until they have found enough peers with a mempool of a similar size than theirs.

vasild · 2023-10-13T06:57:30Z

I second @mzumsande above, plus I see this as too aggressive change that will affect all nodes whereas few will benefit. In other words, this is not needed if a node does not have problems propagating its transactions. For such problems to happen a node must be running with larger than the default mempool or all its peers with smaller than default. Further, if the node's mempool is much larger than default then it may never find a peer with a comparable mempool, so it may loop through peers needlessly while such low fee transactions have not been created yet (and may never be). So this only helps if the node's mempool is larger, but not too large and it creates very low fee transactions.

I am not saying that this should be dropped, but does it make sense to enable it conditionally, under a configuration parameter? With a suggestion to turn it on if the mempool is larger than default and very low fee, time sensitive transactions are expected to be generated.

DrahtBot · 2024-02-05T14:34:39Z

🤔 There hasn't been much activity lately and the CI seems to be failing.

If no one reviewed the current pull request by commit hash, a rebase can be considered. While the CI failure may be a false positive, the CI hasn't been running for some time, so there may be a real issue hiding as well. A rebase triggers the latest CI and makes sure that no silent merge conflicts have snuck in.

DrahtBot · 2025-01-02T13:48:00Z

Are you still working on this?

fanquake · 2025-02-20T17:13:11Z

Closing for now, due to no followup. Please leave a comment, if you want this reopened.

DrahtBot added the P2P label Sep 15, 2023

glozow reviewed Sep 15, 2023

View reviewed changes

src/net_processing.cpp Outdated Show resolved Hide resolved

darosior suggested changes Sep 15, 2023

View reviewed changes

src/net_processing.cpp Outdated Show resolved Hide resolved

DrahtBot added the CI failed label Sep 15, 2023

DrahtBot mentioned this pull request Sep 15, 2023

net: introduce block tracker to retry to download blocks after failure #27837

Draft

naumenkogs force-pushed the 2023-9-evict-minfee branch from c3353c6 to 6b4c4ae Compare September 19, 2023 13:52

vasild reviewed Sep 20, 2023

View reviewed changes

mzumsande mentioned this pull request Sep 26, 2023

p2p: attempt to fill full outbound connection slots with peers that support tx relay #28538

Closed

ariard reviewed Oct 3, 2023

View reviewed changes

dergoegge reviewed Oct 12, 2023

View reviewed changes

sr-gi reviewed Oct 12, 2023

View reviewed changes

mzumsande reviewed Oct 12, 2023

View reviewed changes

DrahtBot mentioned this pull request Feb 9, 2024

Broadcast own transactions only via short-lived Tor or I2P connections #29415

Open

fanquake closed this Feb 20, 2025

		if (tx_relay->m_fee_filter_received) {
		peer_fee_filters.push_back(std::make_pair(pnode, tx_relay->m_fee_filter_received.load()));

-            if (tx_relay->m_fee_filter_received) {
-                peer_fee_filters.push_back(std::make_pair(pnode, tx_relay->m_fee_filter_received.load()));
+            const auto minfee = tx_relay->m_fee_filter_received.load();
+            if (minfee > 0) {
+                peer_fee_filters.push_back(std::make_pair(pnode, minfee));


		if (peer_fee_filters.size() == 0) return;

		std::sort(peer_fee_filters.begin(), peer_fee_filters.end());

	if (!pnode->IsFullOutboundConn() \|\| pnode->fDisconnect) return;
	if (!pnode->IsFullOutboundConn()) return;

p2p: Evict outbound peers with high minFeeRate #28488

p2p: Evict outbound peers with high minFeeRate #28488

Uh oh!

Conversation

naumenkogs commented Sep 15, 2023

Uh oh!

DrahtBot commented Sep 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage

Reviews

Conflicts

Uh oh!

Uh oh!

darosior left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

naumenkogs commented Sep 18, 2023

Uh oh!

ariard commented Sep 18, 2023

Uh oh!

naumenkogs commented Sep 19, 2023

Uh oh!

ariard commented Sep 19, 2023

Uh oh!

vasild left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

instagibbs commented Sep 20, 2023

Uh oh!

naumenkogs commented Sep 21, 2023

Uh oh!

ariard left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

DrahtBot commented Sep 15, 2023 •

edited

Loading

vasild left a comment •

edited

Loading

ariard left a comment •

edited

Loading

instagibbs commented Oct 12, 2023 •

edited

Loading

mzumsande left a comment •

edited

Loading