refactor: Header sync optimisations & simplifications #32740

danielabrozzoni · 2025-06-12T20:20:06Z

This is a partial* revival of #25968

It contains a list of most-unrelated simplifications and optimizations to the code merged in #25717:

Avoid an IsAncestorOfBestHeaderOrTip call: Just don't call this function when it won't have any effect.
Compute work from headers without CBlockIndex: Avoid the need to construct a CBlockIndex object just to compute work for a header, when its nBits value suffices for that. Also use some Spans where possible.
Remove useless CBlock::GetBlockHeader: There is no need for a function to convert a CBlock to a CBlockHeader, as it's a child class of it.

It also contains the following code cleanups, which were suggested by reviewers in #25968:

Remove redundant parameter from CheckHeadersPoW: No need to pass consensusParams, as CheckHeadersPow already has access to m_chainparams.GetConsensus()
Remove unused parameter in ReportHeadersPresync
Use initializer list in CompressedHeader, also make GetFullHeader const
Use reference for chain_start in HeadersSyncState: chain_start can never be null, so it's better to pass it as a reference rather than a raw pointer

*I decided to leave out three commits that were in #25968 (4e7ac7b, ab52fb4, 7f1cf44), since they're a bit more involved, and I'm a new contributor. If this PR gets merged, I'll comment under #25968 to note that these three commits are still up for grabs :)

DrahtBot · 2025-06-12T20:20:17Z

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

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32740.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	hodlinator, l0rinc

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:

#32579 (headerssync: Preempt unrealistic unit test behavior by hodlinator)

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.

ajtowns · 2025-06-13T02:43:25Z

Maybe change the title to describe what's actually going on for those of us who don't memorise every pr number? :) ("Header sync optimisations/simplifications" ?)

hodlinator

Reviewed 13e123e

Thanks for picking this up!

Conflicts somewhat with #32579 where I was aiming to change the headers-parameter to a span. But if we follow through and also take my enum suggestion I would still see it as an improvement on balance (see inline comment).

hodlinator · 2025-06-16T08:42:30Z

src/headerssync.h

@@ -140,33 +140,30 @@ class HeadersSyncState {

    /** Result data structure for ProcessNextHeaders. */
    struct ProcessingResult {
-        std::vector<CBlockHeader> pow_validated_headers;


Not thrilled by increasing the number of in/out parameters - it pushes readers towards having to lean on comments more, rather than having the code somewhat self-documenting. It also makes the unit tests more cumbersome. What makes the change somewhat acceptable is that it conforms to the style of net_processing.cpp.

If we keep this, I would also suggest further simplification of ProcessingResult through converting it to an enum: f2a6179

Thanks for dropping the commit introducing the in/out parameter!

src/validation.cpp

src/headerssync.cpp

src/headerssync.h

danielabrozzoni · 2025-06-24T12:40:49Z

@hodlinator thank you for your review!

I like the idea of converting ProcessingResult to an enum, I think it makes the code easier to read.

As for pow_validated_headers, I don’t have a strong preference between using a span or an argument for I/O just yet. I’ll take a closer look at #32579 over the next few days and should have a more informed opinion afterward :) I’d also be interested to hear what other reviewers think!

Latest push:

style improvements based on review comments

l0rinc

I'd like to review this - can you tell me how to measure the effect of the "optimizations" using either the microbenchmarks or a reindex or anything that shows the magnitude of change?
Would be helpful if you could publish your measurements if you have any.

src/headerssync.h

src/test/headers_sync_chainwork_tests.cpp

danielabrozzoni · 2025-07-07T16:49:48Z

Last push:

Reformat to address refactor: Header sync optimisations & simplifications #32740 (comment)
Rebase on master

I'd like to review this - can you tell me how to measure the effect of the "optimizations" using either the microbenchmarks or a reindex or anything that shows the magnitude of change?
Would be helpful if you could publish your measurements if you have any.

I don't have any, working on it!

l0rinc

Concept ACK, I'm not sure about the first change but the rest make sense.

reviewed f4b33a1, left some comments for most commits, my main concern is the commit where we're reusing the headers vector, making the code significantly more contrived.
It would also be great if we could extract the common parts of this and @hodlinator's change and merge that (or his change) before we do this.

src/headerssync.h

src/headerssync.cpp

src/test/headers_sync_chainwork_tests.cpp

src/headerssync.cpp

src/net_processing.cpp

l0rinc · 2025-07-23T23:43:02Z

src/net_processing.cpp

@@ -4365,7 +4365,7 @@ void PeerManagerImpl::ProcessMessage(CNode& pfrom, const std::string& msg_type,
                MaybeSendGetHeaders(pfrom, GetLocator(m_chainman.m_best_header), *peer);
            }
            return;
-        } else if (prev_block->nChainWork + CalculateClaimedHeadersWork({{cmpctblock.header}}) < GetAntiDoSWorkThreshold()) {
+        } else if (prev_block->nChainWork + GetBlockProof(cmpctblock.header) < GetAntiDoSWorkThreshold()) {


src/merkleblock.cpp

src/test/blockfilter_index_tests.cpp

src/headerssync.h

src/test/headers_sync_chainwork_tests.cpp

danielabrozzoni · 2025-08-01T15:41:52Z

After some thinking, I decided to drop the first commit, and let ProcessNextHeaders take the headers argument and return it, instead of using it as a I/O argument. I tried to write a benchmark to measure how much using the vector as I/O argument would optimize the code, but it convinced me that the new interface would be too hard to work with, as reviewers pointed out. While it might still be a performance improvement, I'm not sure if it's really worth it.

For anyone interested, here's my attempt at writing a benchmark: 852aca5 and my branch
(Unfortunately, since ProcessNextHeaders changes the content of the headers vector passed in, I had to copy the vector every single time, which I suppose could make the benchmark a bit unreliable? There are also a few assertions in the bench.run() function, which I used to make sure that my code wasn't bugged, but I'm not sure if they should be there in any serious attempt at benchmarking)

Will update the PR in the next few days :)

danielabrozzoni

In my last push (f33bd2f):

Removed first commit as per my last comment (#32740 (comment))
Addressed review comments

src/test/headers_sync_chainwork_tests.cpp

danielabrozzoni · 2025-08-08T15:00:16Z

src/validation.h

@@ -394,7 +394,7 @@ bool TestBlockValidity(BlockValidationState& state,
                       bool fCheckMerkleRoot = true) EXCLUSIVE_LOCKS_REQUIRED(cs_main);

 /** Check with the proof of work on each blockheader matches the value in nBits */
-bool HasValidProofOfWork(const std::vector<CBlockHeader>& headers, const Consensus::Params& consensusParams);
+bool HasValidProofOfWork(const std::span<const CBlockHeader> headers, const Consensus::Params& consensusParams);


That makes a lot of sense, thank you!
I only removed the const, I prefer to keep the argument names

danielabrozzoni · 2025-08-08T15:02:01Z

src/validation.cpp

@@ -4159,9 +4159,9 @@ std::vector<unsigned char> ChainstateManager::GenerateCoinbaseCommitment(CBlock&
    return commitment;
 }

-bool HasValidProofOfWork(const std::vector<CBlockHeader>& headers, const Consensus::Params& consensusParams)
+bool HasValidProofOfWork(const std::span<const CBlockHeader> headers, const Consensus::Params& consensusParams)


Thanks, I removed the const and put this change in a separate commit

l0rinc

code review ACK f33bd2f

nit: the PR isn't really an optimization anymore, consider updating the title

l0rinc · 2025-08-08T23:37:24Z

src/validation.cpp

@@ -4149,8 +4149,8 @@ std::vector<unsigned char> ChainstateManager::GenerateCoinbaseCommitment(CBlock&

 bool HasValidProofOfWork(const std::vector<CBlockHeader>& headers, const Consensus::Params& consensusParams)
 {
-    return std::all_of(headers.cbegin(), headers.cend(),
-            [&](const auto& header) { return CheckProofOfWork(header.GetHash(), header.nBits, consensusParams);});
+    return std::ranges::all_of(headers,


nit: this change could either be merged with the vector-to-std::span or moved over to that commit, it's not needed in 80c63c9

~~I can see it belonging in either commit, as one modifies the container and the other modifies what operators we apply to it.~~

Edit after #32740 (comment) below: Now realize I was mixing up CheckProofOfWork with GetBlockProof - we are still applying the same thing.

I think it fits slightly better with the span change... since in c++20 span doesn't have a cbegin method, we needed to change the initial code, and update to ranges::all_of

l0rinc · 2025-08-08T23:38:39Z

src/primitives/block.h

@@ -101,18 +101,6 @@ class CBlock : public CBlockHeader
        m_checked_merkle_root = false;
    }

-    CBlockHeader GetBlockHeader() const


l0rinc · 2025-08-08T23:41:19Z

src/headerssync.cpp

-    m_current_chain_work(chain_start->nChainWork),
-    m_last_header_received(m_chain_start->GetBlockHeader()),
-    m_current_height(chain_start->nHeight)
+                                   const CBlockIndex& chain_start, const arith_uint256& minimum_required_work) : m_commit_offset(FastRandomContext().randrange<unsigned>(HEADER_COMMITMENT_PERIOD)),


nit: if you touch again, please format this differently

Agree using style much closer to the original would be very welcome. Listing the member initializers at the indentation level where the function arguments end makes potential comments to the right of those arguments disappear out of sight etc.

Would also be nice to use more common style for CompressedHeader but at least there the initializer list didn't exist before.

Thanks, I didn't like the initial formatting either, but I thought it was common (looking at other constructors in the repository, no, it's not...)

I updated the formatting both in HeadersSyncState and CompressedHeaders!

(Still have a slight preference for using the original way of formatting the HeadersSyncState initializer-list for optimal git blame integrity, but this is tolerable compared to the previous push, I see it matches PeerManagerImpl).

I would still keep the reformatting as clang-format doesn't like the one on master, and reformats it as I previously did (with the member initializers pushed to the right). At least this reformat is nice and clang-format doesn't try to modify it.

I hadn't considered git blame though, I don't love the idea of polluting it...

Oh, so clang-format was pushing for it... seems it could do with some reconfiguration in the initializer-list aspect.

After #32813 we could customize the list formatting as well

hodlinator

Reviewed f33bd2f

hodlinator · 2025-08-12T13:28:17Z

src/net_processing.cpp

(Inline comment in random place).

It seems like the PR has an odd parent commit? Being based upon 11a2d3a which is within another PR's commits, rather than the merge into master which was 9f3dcac.

Ooops, not sure what happened there, thanks for noticing!

hodlinator · 2025-08-12T13:46:21Z

src/headerssync.h

@@ -140,33 +140,30 @@ class HeadersSyncState {

    /** Result data structure for ProcessNextHeaders. */
    struct ProcessingResult {
-        std::vector<CBlockHeader> pow_validated_headers;


Thanks for dropping the commit introducing the in/out parameter!

src/merkleblock.cpp

hodlinator · 2025-08-12T13:55:55Z

src/validation.cpp

@@ -4149,8 +4149,8 @@ std::vector<unsigned char> ChainstateManager::GenerateCoinbaseCommitment(CBlock&

 bool HasValidProofOfWork(const std::vector<CBlockHeader>& headers, const Consensus::Params& consensusParams)
 {
-    return std::all_of(headers.cbegin(), headers.cend(),
-            [&](const auto& header) { return CheckProofOfWork(header.GetHash(), header.nBits, consensusParams);});
+    return std::ranges::all_of(headers,


~~I can see it belonging in either commit, as one modifies the container and the other modifies what operators we apply to it.~~

Edit after #32740 (comment) below: Now realize I was mixing up CheckProofOfWork with GetBlockProof - we are still applying the same thing.

hodlinator · 2025-08-12T13:59:00Z

src/headerssync.cpp

-    m_current_chain_work(chain_start->nChainWork),
-    m_last_header_received(m_chain_start->GetBlockHeader()),
-    m_current_height(chain_start->nHeight)
+                                   const CBlockIndex& chain_start, const arith_uint256& minimum_required_work) : m_commit_offset(FastRandomContext().randrange<unsigned>(HEADER_COMMITMENT_PERIOD)),


Agree using style much closer to the original would be very welcome. Listing the member initializers at the indentation level where the function arguments end makes potential comments to the right of those arguments disappear out of sight etc.

Would also be nice to use more common style for CompressedHeader but at least there the initializer list didn't exist before.

hodlinator · 2025-08-12T14:14:10Z

src/validation.h

@@ -393,7 +393,7 @@ bool TestBlockValidity(BlockValidationState& state,
                       bool fCheckMerkleRoot = true) EXCLUSIVE_LOCKS_REQUIRED(cs_main);

 /** Check with the proof of work on each blockheader matches the value in nBits */


nit: Could fix typo as suggested by LLM (#32740 (comment)).

Suggested change

/** Check with the proof of work on each blockheader matches the value in nBits */

/** Check that the proof of work on each blockheader matches the value in nBits */

Just don't call this function when it won't have any effect.

Avoid the need to construct a CBlockIndex object just to compute work for a header, when its nBits value suffices for that. Co-Authored-By: Pieter Wuille <pieter@wuille.net>

Co-Authored-By: Pieter Wuille <pieter@wuille.net>

There is no need for a function to convert a CBlock to a CBlockHeader, as it's a child class of it.

No need to pass consensusParams, as CheckHeadersPow already has access to m_chainparams.GetConsensus() Co-Authored-By: maflcko <6399679+maflcko@users.noreply.github.com>

Co-Authored-By: Aurèle Oulès <aurele@oules.com>

Also mark GetFullHeader as const Co-Authored-By: Aurèle Oulès <aurele@oules.com>

chain_start can never be null, so it's better to pass it as a reference rather than a raw pointer Co-Authored-By: maflcko <6399679+maflcko@users.noreply.github.com>

danielabrozzoni

Thanks for the reviews!

In my last push:

Rebased onto the right commit 😅 (see #32740 (comment))
Addressed review comments

danielabrozzoni · 2025-08-15T16:35:12Z

src/validation.cpp

@@ -4149,8 +4149,8 @@ std::vector<unsigned char> ChainstateManager::GenerateCoinbaseCommitment(CBlock&

 bool HasValidProofOfWork(const std::vector<CBlockHeader>& headers, const Consensus::Params& consensusParams)
 {
-    return std::all_of(headers.cbegin(), headers.cend(),
-            [&](const auto& header) { return CheckProofOfWork(header.GetHash(), header.nBits, consensusParams);});
+    return std::ranges::all_of(headers,


I think it fits slightly better with the span change... since in c++20 span doesn't have a cbegin method, we needed to change the initial code, and update to ranges::all_of

danielabrozzoni · 2025-08-18T09:12:19Z

src/net_processing.cpp

Ooops, not sure what happened there, thanks for noticing!

danielabrozzoni · 2025-08-18T10:01:36Z

src/headerssync.cpp

-    m_current_chain_work(chain_start->nChainWork),
-    m_last_header_received(m_chain_start->GetBlockHeader()),
-    m_current_height(chain_start->nHeight)
+                                   const CBlockIndex& chain_start, const arith_uint256& minimum_required_work) : m_commit_offset(FastRandomContext().randrange<unsigned>(HEADER_COMMITMENT_PERIOD)),


Thanks, I didn't like the initial formatting either, but I thought it was common (looking at other constructors in the repository, no, it's not...)

I updated the formatting both in HeadersSyncState and CompressedHeaders!

hodlinator

ACK 50e61f4

PR improves the code in several minor ways, such as:

Computing PoW for a CBlockHeader (or CBlock) without having to jump through temporarily constructed CBlockIndex (552b9c3).
Removing CBlock::GetBlockHeader() leaves less room for forgetting to properly set fields in the new CBlockHeader instance (67aa62c).
Changes const CBlockIndex* HeadersSyncState::m_chain_start to a reference as it is never null and never changed (50e61f4).

hodlinator · 2025-08-18T15:10:46Z

src/headerssync.cpp

-    m_current_chain_work(chain_start->nChainWork),
-    m_last_header_received(m_chain_start->GetBlockHeader()),
-    m_current_height(chain_start->nHeight)
+                                   const CBlockIndex& chain_start, const arith_uint256& minimum_required_work) : m_commit_offset(FastRandomContext().randrange<unsigned>(HEADER_COMMITMENT_PERIOD)),


(Still have a slight preference for using the original way of formatting the HeadersSyncState initializer-list for optimal git blame integrity, but this is tolerable compared to the previous push, I see it matches PeerManagerImpl).

l0rinc · 2025-08-21T03:01:19Z

recrACK 50e61f4

I only left nits, I'm fine with merging it as is.

l0rinc · 2025-08-21T02:44:28Z

src/net_processing.cpp

-        if (IsAncestorOfBestHeaderOrTip(last_received_header)) {
-            already_validated_work = true;
-        }
+        already_validated_work = already_validated_work || IsAncestorOfBestHeaderOrTip(last_received_header);


nit: if you touch again, you could explain in the commit message why the LookupBlockIndex cannot be eliminated as well

l0rinc · 2025-08-21T02:49:22Z

src/headerssync.h

@@ -31,16 +31,17 @@ struct CompressedHeader {
        hashMerkleRoot.SetNull();
    }

-    CompressedHeader(const CBlockHeader& header)
+    explicit CompressedHeader(const CBlockHeader& header)


nit: if touching again, the commit message should probably mention the explicit as well. No that important, just noticed it.

l0rinc · 2025-08-21T02:50:45Z

src/headerssync.cpp

@@ -41,7 +44,7 @@ HeadersSyncState::HeadersSyncState(NodeId id, const Consensus::Params& consensus
    // exceeds this bound, because it's not possible for a consensus-valid
    // chain to be longer than this (at the current time -- in the future we
    // could try again, if necessary, to sync a longer chain).
-    m_max_commitments = 6*(Ticks<std::chrono::seconds>(NodeClock::now() - NodeSeconds{std::chrono::seconds{chain_start->GetMedianTimePast()}}) + MAX_FUTURE_BLOCK_TIME) / HEADER_COMMITMENT_PERIOD;
+    m_max_commitments = 6 * (Ticks<std::chrono::seconds>(NodeClock::now() - NodeSeconds{std::chrono::seconds{chain_start.GetMedianTimePast()}}) + MAX_FUTURE_BLOCK_TIME) / HEADER_COMMITMENT_PERIOD;


nit: as mentioned this should be synchronized with the other PR to simplify the merge conflicts

I'm happy to put this in draft and wait for #32579 to be merged first... This PR is smaller, and probably easier to rebase. What do you think?

I personally would let the maintainers decide the order, ank keep both open

Yeah, I don't mind the order much, especially now that it seems like neither will be in v30. Thanks for asking!

l0rinc · 2025-08-21T02:59:44Z

src/net_processing.cpp

another super-nit: CheckHeadersPow -> CheckHeadersPoW in commit message. Only change if you modify the PR for any other reason.

DrahtBot added the Refactoring label Jun 12, 2025

DrahtBot mentioned this pull request Jun 13, 2025

headerssync: Preempt unrealistic unit test behavior #32579

Open

danielabrozzoni changed the title ~~refactor: Optimizations & simplifications following #25717~~ refactor: Header sync optimisations & simplifications #25717 Jun 13, 2025

danielabrozzoni changed the title ~~refactor: Header sync optimisations & simplifications #25717~~ refactor: Header sync optimisations & simplifications Jun 13, 2025

hodlinator reviewed Jun 16, 2025

View reviewed changes

danielabrozzoni force-pushed the upforgrabs/25968 branch from 13e123e to 7634d81 Compare June 24, 2025 12:31

l0rinc reviewed Jul 4, 2025

View reviewed changes

src/headerssync.h Outdated Show resolved Hide resolved

src/test/headers_sync_chainwork_tests.cpp Outdated Show resolved Hide resolved

danielabrozzoni force-pushed the upforgrabs/25968 branch from 7634d81 to f4b33a1 Compare July 7, 2025 16:49

l0rinc suggested changes Jul 24, 2025

View reviewed changes

danielabrozzoni force-pushed the upforgrabs/25968 branch 2 times, most recently from 4d95119 to f33bd2f Compare August 8, 2025 12:46

danielabrozzoni commented Aug 8, 2025

View reviewed changes

l0rinc approved these changes Aug 8, 2025

View reviewed changes

hodlinator reviewed Aug 12, 2025

View reviewed changes

sipa and others added 8 commits August 15, 2025 18:38

p2p: Avoid an IsAncestorOfBestHeaderOrTip call

6f3c9ce

Just don't call this function when it won't have any effect.

refactor: Compute work from headers without CBlockIndex

552b9c3

Avoid the need to construct a CBlockIndex object just to compute work for a header, when its nBits value suffices for that. Co-Authored-By: Pieter Wuille <pieter@wuille.net>

refactor: Use std::span in HasValidProofOfWork

95e7284

Co-Authored-By: Pieter Wuille <pieter@wuille.net>

refactor: Remove useless CBlock::GetBlockHeader

67aa62c

There is no need for a function to convert a CBlock to a CBlockHeader, as it's a child class of it.

refactor: Remove redundant parameter from CheckHeadersPoW

29df83d

No need to pass consensusParams, as CheckHeadersPow already has access to m_chainparams.GetConsensus() Co-Authored-By: maflcko <6399679+maflcko@users.noreply.github.com>

refactor: Remove unused parameter in ReportHeadersPresync

a07db1c

Co-Authored-By: Aurèle Oulès <aurele@oules.com>

refactor: Use initializer list in CompressedHeader

b58b255

Also mark GetFullHeader as const Co-Authored-By: Aurèle Oulès <aurele@oules.com>

refactor: Use reference for chain_start in HeadersSyncState

50e61f4

chain_start can never be null, so it's better to pass it as a reference rather than a raw pointer Co-Authored-By: maflcko <6399679+maflcko@users.noreply.github.com>

danielabrozzoni force-pushed the upforgrabs/25968 branch from f33bd2f to 50e61f4 Compare August 18, 2025 14:21

danielabrozzoni commented Aug 18, 2025

View reviewed changes

hodlinator approved these changes Aug 18, 2025

View reviewed changes

DrahtBot requested a review from l0rinc August 18, 2025 15:41

l0rinc approved these changes Aug 21, 2025

View reviewed changes

l0rinc mentioned this pull request Aug 22, 2025

rpc: followups for 33106 #33189

Open

		@@ -393,7 +393,7 @@ bool TestBlockValidity(BlockValidationState& state,
		bool fCheckMerkleRoot = true) EXCLUSIVE_LOCKS_REQUIRED(cs_main);

		/** Check with the proof of work on each blockheader matches the value in nBits */

	/** Check with the proof of work on each blockheader matches the value in nBits */
	/** Check that the proof of work on each blockheader matches the value in nBits */

refactor: Header sync optimisations & simplifications #32740

Are you sure you want to change the base?

refactor: Header sync optimisations & simplifications #32740

Uh oh!

Conversation

danielabrozzoni commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage & Benchmarks

Reviews

Conflicts

Uh oh!

ajtowns commented Jun 13, 2025

Uh oh!

hodlinator left a comment

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!

Uh oh!

Uh oh!

Uh oh!

danielabrozzoni commented Jun 24, 2025

Uh oh!

l0rinc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

danielabrozzoni commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

l0rinc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

danielabrozzoni commented Aug 1, 2025

Uh oh!

danielabrozzoni left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

l0rinc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hodlinator Aug 12, 2025 • 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

danielabrozzoni commented Jun 12, 2025 •

edited

Loading

DrahtBot commented Jun 12, 2025 •

edited

Loading

danielabrozzoni commented Jul 7, 2025 •

edited

Loading

hodlinator Aug 12, 2025 •

edited

Loading

hodlinator Aug 12, 2025 •

edited

Loading

hodlinator left a comment •

edited

Loading