pull down to refresh
100 sats \ 0 replies \ @0xB10C 3h \ parent \ on: Peer-observer: A tool and infrastructure for monitoring the Bitcoin P2P network bitcoin
It's perfect for this. You know exactly what's running on the hosts and you can scale it up easily by running the same (or similar) configuration on a different host.
See https://github.com/0xb10c/peer-observer-infra-demo and https://github.com/0xb10c/peer-observer-infra-library
Just saw this now. Feel free to ping me (you'll find contact info on b10c.me) if you're still interested @spiderman
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/