I’m trying to think why it’s advantageous to core. Light weight startup - no need to wait for sync. Lighter network footprint - core if it’s not over Tor lets your ISP know your into bitcoin. Avoids sticking to the same peers *feels* more private. Yet I would assume core’s node selection is also private. What am I missing?
I have released a unique privacy tool and code library that broadcasts Bitcoin transactions **directly** into the P2P network.
1. No external dependencies whatsoever.
2. No centralized backends.
3. Uses Tor if found running on the same system. Having the Tor Browser open in the background is enough.
Find the CLI here:
https://crates.io/crates/pushtx-cli
And the Rust crate here:
Discussion
Broadcasting through Core has always worked well, if you have Core. This is meant for situations where Core isn't available or where you have serious privacy concerns.
Think mobile and desktop wallets that need to send out a set of transaction quickly and privately. Core is a massive dependency with a long bootstrap time and not available in many situations.
But how does this improve privacy? Because it uses tor? Is that it? Why can't Bitcoin Core do that too?
I believe it is because most mobile wallets connect to someone else's public (centralized) node to broadcast transactions. That node can therefore see all your transactions.
It is not as useful if you run your own node and your mobile wallet connects back to it, but more useful as a default option for mobile wallets rather than connecting to a public node to broadcast.
It could probably also be used for projects like #meshtastic to broadcast transactions sent on the mesh to the Bitcoin network via any reachable mesh devices with an internet connection.
I'd put a bounty on it....but appears meshtastic is too low bandwidth. How to store n forward..hmm...it will be an engineering marvel for whoever can solve for it. This is the missing link to an actual parallel economy. Otherwise all hardware and networks are compromised.
Too low for Bitcoin p2p connections? Yes. But I was suggesting sending a Tx over a mesh with a flag (e.g. btc:'tx hex'). When a mesh node receives the flagged message, it could check to see if it has an internet connection (LTE on paired device) and if so, use this to broadcast the tx to the Bitcoin network. Use case might be too spefic and limited to warrant development though.