Improvements that could be made to how bitcoin propagates its transactions and blocks?
up vote
6
down vote
favorite
As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?
network relay compact-blocks fibre
asked Nov 11 at 22:00
G. Maxwell
3,137629
add a comment |
up vote
6
down vote
favorite
As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?
network relay compact-blocks fibre
asked Nov 11 at 22:00
G. Maxwell
3,137629
Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
Nov 11 at 22:00
add a comment |
up vote
6
down vote
favorite
up vote
6
down vote
favorite
As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?
network relay compact-blocks fibre
asked Nov 11 at 22:00
G. Maxwell
3,137629
As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?
network relay compact-blocks fibre
network relay compact-blocks fibre
asked Nov 11 at 22:00
G. Maxwell
3,137629
asked Nov 11 at 22:00
G. Maxwell
3,137629
asked Nov 11 at 22:00
G. Maxwell
3,137629
asked Nov 11 at 22:00
G. Maxwell
3,137629
asked Nov 11 at 22:00
G. Maxwell
3,137629
3,137629
Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
Nov 11 at 22:00
add a comment |
Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
Nov 11 at 22:00
Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
Nov 11 at 22:00
Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
Nov 11 at 22:00
add a comment |
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.
BIP 152, avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default. The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?
On the other hand, transaction relay clearly has room for improvement. The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed using set reconciliation (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.
Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion.
answered Nov 11 at 22:00
G. Maxwell
3,137629
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',
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%2f80927%2fimprovements-that-could-be-made-to-how-bitcoin-propagates-its-transactions-and-b%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.
BIP 152, avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default. The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?
On the other hand, transaction relay clearly has room for improvement. The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed using set reconciliation (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.
Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion.
answered Nov 11 at 22:00
G. Maxwell
3,137629
add a comment |
up vote
5
down vote
accepted
The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.
BIP 152, avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default. The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?
On the other hand, transaction relay clearly has room for improvement. The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed using set reconciliation (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.
Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion.
answered Nov 11 at 22:00
G. Maxwell
3,137629
add a comment |
up vote
5
down vote
accepted
up vote
5
down vote
accepted
The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.
BIP 152, avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default. The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?
On the other hand, transaction relay clearly has room for improvement. The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed using set reconciliation (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.
Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion.
answered Nov 11 at 22:00
G. Maxwell
3,137629
The answer partially depends on on what you mean by "how bitcoin propagates" and "improvements"-- Fibre transmits blocks vanishingly close to the lowest latency possible, but at the expense of using extra bandwidth. It doesn't seems likely that significantly greater protocol wise improvement to latency is possible, beyond more widespread usage of it.
BIP 152, avoids the bandwidth waste, but doesn't achieve quite as as low a latency by default. The bandwidth usage of BIP152-like transmission could be improved further, but improvements seem kinda pointless: Right now with BIP-152 blocks are transferred with an average of 11802 bytes each... I have code that reduces it to about 550 bytes/block on average, at considerable CPU expense. But who really cares about saving 1.54 MB/day against a >>288MB background (transaction data) except perhaps for specialized applications like satellite transmission that use their own protocols?
On the other hand, transaction relay clearly has room for improvement. The existing approach is not very efficient especially for nodes with many peers. The issue there is that to be robust against malicious peers nodes announce all transactions to all peers. Transactions are announced by sending short hashes rather than whole transactions, but this still results in a ton of duplication. Effectively Bitcoin nodes use O(peers*transactions) bandwidth for tx relay, the use of short inv hashes only shrinks the bandwidth a constant factor (of 10-ish). A long time back I proposed using set reconciliation (also described on the forum post above in less detail) to make the relay of lose transactions more efficient without compromising robustness. Gleb Naumenko, Pieter Wuille, and I have spent much of the last year designing and implementing practical protocol based on this idea and should have something out somewhat soon.
Relay can also be improved in ways other than bandwidth efficiency. E.g. There have been several recent efforts to improve the privacy of TX relay, including the outbound peer grouping in 0.17 and the ongoing work on low fanout relay in dandelion.
answered Nov 11 at 22:00
G. Maxwell
3,137629
answered Nov 11 at 22:00
G. Maxwell
3,137629
answered Nov 11 at 22:00
G. Maxwell
3,137629
answered Nov 11 at 22:00
G. Maxwell
3,137629
3,137629
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f80927%2fimprovements-that-could-be-made-to-how-bitcoin-propagates-its-transactions-and-b%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
Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
Nov 11 at 22:00