Sending transactions to mining nodes only?












4















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?










share|improve this question





























    4















    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?










    share|improve this question



























      4












      4








      4








      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?










      share|improve this 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?







      transaction-propagation






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 19 '18 at 21:25









      Murch

      34.8k27114325




      34.8k27114325










      asked Dec 19 '18 at 20:23









      HerofireHerofire

      332




      332






















          3 Answers
          3






          active

          oldest

          votes


















          6














          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.






          share|improve this answer





















          • 1





            Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

            – Murch
            Dec 19 '18 at 21:24











          • 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
            Dec 19 '18 at 21:32






          • 1





            @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
            Dec 19 '18 at 22:01



















          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.






          share|improve this answer
























          • 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
            Dec 19 '18 at 22:40











          • 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
            Dec 19 '18 at 23:05



















          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.






          share|improve this answer


























          • 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
            Dec 19 '18 at 20:36











          • 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
            Dec 19 '18 at 21:02











          • I think you mean -addnode instead of -whitelist.

            – Pieter Wuille
            Dec 19 '18 at 21:12











          • addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

            – JBaczuk
            Dec 19 '18 at 21:16













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "308"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83054%2fsending-transactions-to-mining-nodes-only%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          6














          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.






          share|improve this answer





















          • 1





            Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

            – Murch
            Dec 19 '18 at 21:24











          • 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
            Dec 19 '18 at 21:32






          • 1





            @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
            Dec 19 '18 at 22:01
















          6














          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.






          share|improve this answer





















          • 1





            Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

            – Murch
            Dec 19 '18 at 21:24











          • 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
            Dec 19 '18 at 21:32






          • 1





            @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
            Dec 19 '18 at 22:01














          6












          6








          6







          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.






          share|improve this answer















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 19 '18 at 23:09

























          answered Dec 19 '18 at 21:18









          Pieter WuillePieter Wuille

          45.7k394154




          45.7k394154








          • 1





            Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

            – Murch
            Dec 19 '18 at 21:24











          • 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
            Dec 19 '18 at 21:32






          • 1





            @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
            Dec 19 '18 at 22:01














          • 1





            Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

            – Murch
            Dec 19 '18 at 21:24











          • 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
            Dec 19 '18 at 21:32






          • 1





            @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
            Dec 19 '18 at 22:01








          1




          1





          Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

          – Murch
          Dec 19 '18 at 21:24





          Good answer. You might want to mention that full nodes can opt out of relaying unconfirmed transactions by running in blocks-only mode.

          – Murch
          Dec 19 '18 at 21:24













          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
          Dec 19 '18 at 21:32





          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
          Dec 19 '18 at 21:32




          1




          1





          @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
          Dec 19 '18 at 22:01





          @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
          Dec 19 '18 at 22:01











          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.






          share|improve this answer
























          • 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
            Dec 19 '18 at 22:40











          • 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
            Dec 19 '18 at 23:05
















          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.






          share|improve this answer
























          • 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
            Dec 19 '18 at 22:40











          • 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
            Dec 19 '18 at 23:05














          1












          1








          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Dec 19 '18 at 22:34









          cleanmarkercleanmarker

          2858




          2858













          • 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
            Dec 19 '18 at 22:40











          • 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
            Dec 19 '18 at 23:05



















          • 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
            Dec 19 '18 at 22:40











          • 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
            Dec 19 '18 at 23:05

















          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
          Dec 19 '18 at 22:40





          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
          Dec 19 '18 at 22:40













          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
          Dec 19 '18 at 23:05





          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
          Dec 19 '18 at 23:05











          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.






          share|improve this answer


























          • 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
            Dec 19 '18 at 20:36











          • 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
            Dec 19 '18 at 21:02











          • I think you mean -addnode instead of -whitelist.

            – Pieter Wuille
            Dec 19 '18 at 21:12











          • addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

            – JBaczuk
            Dec 19 '18 at 21:16


















          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.






          share|improve this answer


























          • 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
            Dec 19 '18 at 20:36











          • 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
            Dec 19 '18 at 21:02











          • I think you mean -addnode instead of -whitelist.

            – Pieter Wuille
            Dec 19 '18 at 21:12











          • addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

            – JBaczuk
            Dec 19 '18 at 21:16
















          0












          0








          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.






          share|improve this answer















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 20 '18 at 2:46

























          answered Dec 19 '18 at 20:27









          JBaczukJBaczuk

          4,2141321




          4,2141321













          • 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
            Dec 19 '18 at 20:36











          • 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
            Dec 19 '18 at 21:02











          • I think you mean -addnode instead of -whitelist.

            – Pieter Wuille
            Dec 19 '18 at 21:12











          • addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

            – JBaczuk
            Dec 19 '18 at 21:16





















          • 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
            Dec 19 '18 at 20:36











          • 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
            Dec 19 '18 at 21:02











          • I think you mean -addnode instead of -whitelist.

            – Pieter Wuille
            Dec 19 '18 at 21:12











          • addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

            – JBaczuk
            Dec 19 '18 at 21:16



















          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
          Dec 19 '18 at 20:36





          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
          Dec 19 '18 at 20:36













          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
          Dec 19 '18 at 21:02





          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
          Dec 19 '18 at 21:02













          I think you mean -addnode instead of -whitelist.

          – Pieter Wuille
          Dec 19 '18 at 21:12





          I think you mean -addnode instead of -whitelist.

          – Pieter Wuille
          Dec 19 '18 at 21:12













          addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

          – JBaczuk
          Dec 19 '18 at 21:16







          addnode will still allow other nodes to connect and relay txs if they are connected to the node you added, right?

          – JBaczuk
          Dec 19 '18 at 21:16




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Bitcoin Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83054%2fsending-transactions-to-mining-nodes-only%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Plaza Victoria

          Puebla de Zaragoza

          Musa