5
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?
7
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.
1
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.
This is true in practice, the mempool and its associated unconfirmed tx relay are used to actually inform the receiver about a payment. But not doing so is not in contradiction to OP's question; you could a transaction to the recipient and miners (somehow). If the recipient doesn't believe it was sent to miners he could do it himself as well. – Pieter Wuille – 2018-12-19T22:40:06.490
Once a node receives the 'new' transactions from the mined block, the node could theoretically verify all the transactions by itself without a need for a mempool of transactions correct? Just following the same procedure it does before adding it to the mempool currently? – Herofire – 2018-12-19T23:05:50.260
0
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.
I'm talking about sending the transaction to all the mining nodes within the network, so no matter what node mined the new block, they will have all the latest transactions in their pool to choose from. Is it theoretically necessary for all the other nodes who aren't mining a block to know about the transactions before it is mined within the block? – Herofire – 2018-12-19T20:36:47.253
Ah, well there isn't a security reason this wouldn't work, really, other than the transaction relay to all mining nodes may take longer if it hits dead ends. Also, some nodes are used to make block explorers who usually can tell you the tx is pending, but they wouldn't have the tx until is was mined. You can already whitelist nodes if you want in bitcoind using the -whitelist flag. – JBaczuk – 2018-12-19T21:02:51.157
I think you mean -addnode instead of -whitelist. – Pieter Wuille – 2018-12-19T21:12:05.020
addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right? – JBaczuk – 2018-12-19T21:16:36.743
1Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode. – Murch – 2018-12-19T21:24:25.910
Thanks for the reply. I was looking into this solution in order to somehow reduce the 'waste' that currently happens when transactions are being relayed across the network as nodes currently will receive many INV for a transaction that they already have. In this proposed solution, non-mining nodes will only receive transactions once they are in the mined block and hence no duplication of tx INV – Herofire – 2018-12-19T21:32:58.233
2@Herofire I'm actually working myself on a solution to that redundancy, using set reconciliation algorithms to find differences between known invs instead of just broadcasting them all. – Pieter Wuille – 2018-12-19T22:01:47.927