Still reading, but I found this...
The proof of work consists of finding a cryptographic hash value for a block of transactions which starts with a certain number of leading zero bits (32 when Bitcoin was first proposed, 67 zero bits at present).
That misconception will never die.
Can you explain for the noobs?
The paper says that running Tor and clearnet together mitigates the attack so just so that. Other short-term solutions I can think of:
- "Glitch" the address buckets - randomly drop addresses from the bucket on an hourly interval even when they are not full.
- Require all peers to submit their block height block hash of their longest tip, and ban nodes that don't have info that matches what is stored locally.
- glitch the banlist by randomly deleting some banned peers which weren't added manually.
- Reply to GETADDR messages with randomized ADDR messages that changes on each request.
Another advice for a user would be to run two Bitcoin nodes, one over Tor and one without, and compare their blockchains and unconfirmed transactions. This would prevent from creation of virtual reality for Tor-only users.
So are you saying I just allow my node to connect on both clearnet and Tor, or create two separate nodes and some method of comparing the respective states, as suggested in the paper?
Thanks for all your suggestions. Unfortunately I'm not super tech savvy and so I imagine these will be beyond my ability to integrate.
[moderator's note: consecutive posts merged]