Mixing
How are transactions propagated through the bitcoin network? (In-depth)
I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
Any help would be great, thanks!
transactions network
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
add a comment |
I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
Any help would be great, thanks!
transactions network
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
add a comment |
I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
Any help would be great, thanks!
transactions network
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
Any help would be great, thanks!
transactions network
transactions network
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
asked Jan 27 at 16:43
DonalDraperDonalDraper
473
473
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.
When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.
However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.
The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
1
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
2
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
add a comment |
Each full-node will send an INV message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.
In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:
- 1)
INVmessage from peer - 2)
TXmessage from peer - 3) Local Mempool organisation event (new TX accepted)
If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).
I know of no individual channel transaction queues in any Bitcoin implementation.
answered Jan 27 at 16:57
James C.James C.
1,8751214
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f84035%2fhow-are-transactions-propagated-through-the-bitcoin-network-in-depth%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.
When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.
However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.
The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
1
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
2
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
add a comment |
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.
When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.
However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.
The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
1
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
2
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
add a comment |
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.
When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.
However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.
The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.
Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.
When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.
However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.
Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?
The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.
The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
edited Jan 27 at 22:57
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
answered Jan 27 at 17:35
Andrew Chow♦Andrew Chow
33k42462
33k42462
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
1
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
2
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
add a comment |
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
1
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
2
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
I did not know this. Thank you.
– James C.
Jan 27 at 17:49
1
1
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
– Pieter Wuille
Jan 27 at 18:13
2
2
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
– G. Maxwell
Jan 27 at 21:53
add a comment |
Each full-node will send an INV message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.
In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:
- 1)
INVmessage from peer - 2)
TXmessage from peer - 3) Local Mempool organisation event (new TX accepted)
If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).
I know of no individual channel transaction queues in any Bitcoin implementation.
answered Jan 27 at 16:57
James C.James C.
1,8751214
add a comment |
Each full-node will send an INV message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.
In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:
- 1)
INVmessage from peer - 2)
TXmessage from peer - 3) Local Mempool organisation event (new TX accepted)
If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).
I know of no individual channel transaction queues in any Bitcoin implementation.
answered Jan 27 at 16:57
James C.James C.
1,8751214
add a comment |
Each full-node will send an INV message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.
In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:
- 1)
INVmessage from peer - 2)
TXmessage from peer - 3) Local Mempool organisation event (new TX accepted)
If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).
I know of no individual channel transaction queues in any Bitcoin implementation.
answered Jan 27 at 16:57
James C.James C.
1,8751214
Each full-node will send an INV message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.
In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:
- 1)
INVmessage from peer - 2)
TXmessage from peer - 3) Local Mempool organisation event (new TX accepted)
If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).
I know of no individual channel transaction queues in any Bitcoin implementation.
answered Jan 27 at 16:57
James C.James C.
1,8751214
answered Jan 27 at 16:57
James C.James C.
1,8751214
answered Jan 27 at 16:57
James C.James C.
1,8751214
answered Jan 27 at 16:57
James C.James C.
1,8751214
1,8751214
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f84035%2fhow-are-transactions-propagated-through-the-bitcoin-network-in-depth%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
