Improvements that could be made to how bitcoin propagates its transactions and blocks?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite












As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?










share|improve this question





















  • Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
    – G. Maxwell
    7 hours ago














up vote
3
down vote

favorite












As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?










share|improve this question





















  • Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
    – G. Maxwell
    7 hours ago












up vote
3
down vote

favorite









up vote
3
down vote

favorite











As of 2018 what are the known improvements that could be made to how bitcoin propagates its transactions and blocks?










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 7 hours ago









G. Maxwell

1,942321




1,942321











  • Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
    – G. Maxwell
    7 hours ago
















  • Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
    – G. Maxwell
    7 hours ago















Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
7 hours ago




Someone asked this on reddit: reddit.com/r/Bitcoin/comments/9w7i95/…
– G. Maxwell
7 hours ago










1 Answer
1






active

oldest

votes

















up vote
3
down vote













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.






share|improve this answer




















    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
    );



    );













     

    draft saved


    draft discarded


















    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






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote













    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.






    share|improve this answer
























      up vote
      3
      down vote













      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.






      share|improve this answer






















        up vote
        3
        down vote










        up vote
        3
        down vote









        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 7 hours ago









        G. Maxwell

        1,942321




        1,942321



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay