pull down to refresh
100 sats \ 0 replies \ @0xB10C OP 30 Jul \ parent \ on: peer-observer: A tool and infrastructure for monitoring the Bitcoin P2P network bitcoin
I agree and have thought about this myself. I started packaging fork-observer for Umbrel, but couldn't really test it without an Umbrel node myself. Ideally, that's something someone else could do that a) has an Umbrel / Start9 node setup and b) has the time to do it.
Transaction relay between nodes works by announcing (
inv msg) that there is a transaction with (w)txid X, the peer requesting X (getdata msg), and us sending X (tx msg).A spy node only every receives INVs and records where they heard X first. They never request the transaction as they for now only care about the (w)txid.
They also (normally) never INV any transactions to us, as this would mean we don't INV the transaction to them (so giving them less data).
Maybe we can automatically disconnect or ban peers that behave like spy nodes, but there is always the risk that a heuristic is off or a peer behaves like a spy node due to an edge case. For example, a peer might already have all transactions you announce, and doesn't have any to announce to you. This would look like a spy node to use (at least on a shortish time frame, until the peer learns about a tx we don't yet have and can announce to us), but is actually a worthwhile peer to keep.
I'm a little confused about spy node amplification.
Thanks for the feedback. I think I can expand on this in the post a bit. I seem to have assumed that all readers are familiar with transaction relay with spy nodes, which is probably something I should explain.
Stratum jobs don’t contain the full list of transactions included in the block template. A miner only needs to construct a block header, which can be done without knowing the full template contents. Modern miners exhaust the 32-bit nonce in the block header quite fast and can then either update the timestamp in the header, roll the version a la overt ASICBoost, or change the so-called extranonce in the coinbase transaction, which causes the Merkle root to change. For this, miners need the coinbase transaction, information about the extranonce, and the Merkle branches to calculate a new Merkle root.
The list of Merkle branches in stratum jobs contains just the information required to calculate the Merkle root. To build the Merkle root, the coinbase transaction is hashes together with the first Merkle branch, the result is then hashed with the second Merkle branch, which is then again hashed with the third Merkle branch. The Merkle root is reached once all Merkle branches have been hashed together.
On the mempool.space/stratum page, each colored column is a merkle branch (marked in red in my image). Normally, these are hashes, but I've started to color them at some point to make it easier to distinguish them. Equal color in a column means equal hash means equal merkle tree branch. If all merkle tree branches are equal, then the block template is the same too. If the block template is frequently the same, you can assume that the pools are the same.
I link to, for example, https://ofac.treasury.gov/recent-actions/20231003 when discussing the first block. This itself links to https://home.treasury.gov/news/press-releases/jy1779
Earlier this year, I wrote about the mutated blocks ViaBTC is sending out: https://b10c.me/observations/10-viabtc-blocks-without-witness-data/
I think it's important to note that this is a pre-release in form of the first release canidate (thats what rc1 means). These binaries should be used to test the release, not necessarily for production deployments as they can still contain bugs.
Companies or projects relying on Bitcoin Core might want to update a part of their infrastructure to v28.0rc1 now (and other release candidates later) to be sure they are compatible with the release. The hope is that bugs and other problems are catched with the release candidates and not the final release!