Sending transactions to mining nodes only?

Question

Instead of propagating transactions across all nodes in the bitcoin network, would it be theoretically better to just send transactions to mining nodes as transactions are only confirmed and 'used' when confirmed inside a block. The other nodes would then be able to confirm and validate these transactions when they learn about the new mined block with the 'confirmed' transactions?

Answer 1

In theory, that would be ideal if your goal is solely getting the transaction to mine.

Hurts permissionless mining However it does require knowing how to reach miners directly. Mining is designed to be a permissionless business, accessible for anyone with the right hardware. Your solution would require publishing the IP addresses of miners to all transaction creators.

Hurts sender privacy It would also hurt privacy, as miners would learn the sender IP of transaction creators; possibly enabling them to censor based on that information.

Not relaying transactions doesn't gain you much The marginal cost of relaying every transaction to every node is low since the introduction of algorithms like BIP152 (compact blocks). Assuming a transaction will eventually be mined anyway, that transaction needs to reach every full node eventually (as part of a block). Relaying it as a separate transaction ahead of time doesn't cost anything, if the relay of the block can refer to the earlier transaction instead. There are some costs related to 'inv' messages that can be reduced though, without removing transaction relay.

Hurts block propagation speed And lastly, only broadcasting transaction to miners directly would worsen block propagation speed very significantly. Modern block relay protocols (like BIP152 and FIBRE) rely on nodes knowing the bulk of blocks' transaction ahead of time to quickly relay those blocks.

Answer 2

In the case of confirming that a transaction has been successfully submitted, failure to use mempool as a distributed pool means you'd have to query that one "mining node". Example: I send a transaction with my wallet directly to that 1 node to pay for a service. The service gives 10 minutes to see the transaction before invalidating the entire thing. Unless the service is looking right at that node, then how would it know's it's been submitted to the network?

Basically there are many use cases where confirming that a transaction exists (but not mined) can be particularly important. Interacting with a network that all shares the same mempool means no matter where you send it from/to it'll be visible everywhere to everyone.

Imagine how many times you'd end up telling a person "I sent it, you'll have to wait to see it." As it is now block explorers will detect the transaction in most cases within seconds. You can almost instantly point and say "See, it's processing". Thanks to mempool.

Answer 3

That could significantly lower the chances of the transaction being mined if, say that mining node's miners represented a very small fraction of the hashpower of the network. If only a small subset of the network hashpower is mining a specific transaction, it may take very long or never get mined at all. You'd have to calculate how often those miners win a block to know the average confirmation time sending to that node.

Edit: Misunderstood the question. Relaying transactions to all "mining" nodes shouldn't really affect security other than relaying the transaction to all mining nodes may take longer if it hits dead ends (with "non-mining" nodes). Also, some nodes are used to make block explorers and wallets who usually can tell you the tx is pending, but they wouldn't have the tx until is was mined. Also, you can already whitelist nodes from which you will relay transactions in bitcoind using the -whitelist flag.