<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper <span dir="ltr">&lt;<a href="mailto:peter.tschipper@gmail.com" target="_blank">peter.tschipper@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <span class=""></span><span class=""></span>There are better ways of sending new blocks, that&#39;s certainly true
    but for sending historical blocks and seding transactions I don&#39;t
    think so.  This PR is really designed to save bandwidth and not
    intended to be a huge performance improvement in terms of time spent
    sending.<span class=""><br></span></blockquote><div><br></div><div>If the main point is for historical data, then sticking to just blocks is the best plan.<br><br></div><div>Since small blocks don&#39;t compress well, you could define a &quot;cblocks&quot; message that handles multiple blocks (just concatenate the block messages as payload before compression).  <br><br>The sending peer could combine blocks so that each cblock is compressing at least 10kB of block data (or whatever is optimal).  It is probably worth specifying a maximum size for network buffer reasons (either 1MB or 1 block maximum).<br><br></div><div>Similarly, transactions could be combined together and compressed &quot;ctxs&quot;.  The inv messages could be modified so that you can request groups of 10-20 transactions.  That would depend on how much of an improvement compressed transactions would represent. <br><br></div><div>More generally, you could define a message which is a compressed message holder.  That is probably to complex to be worth the effort though.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
    <blockquote type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Nov 10, 2015 at 5:40 AM,
          Johnathan Corgan via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank"></a><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr"><span>
                <div style="font-size:small">On
                  Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
                  <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>
                  wrote:<br>
                </div>
              </span>
              <div class="gmail_extra">
                <div class="gmail_quote"><span>
                    <div> </div>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div dir="ltr">I think 25% bandwidth savings is
                        certainly considerable, especially for people
                        running full nodes in countries like Australia
                        where internet bandwidth is lower and there are
                        data caps.</div>
                    </blockquote>
                    <div><br>
                    </div>
                  </span>
                  <div>
                    <div style="font-size:small;display:inline">​This
                      reinforces the idea that such trade-off decisions
                      should be be local and negotiated between peers,
                      not a required feature of the network P2P.​</div>
                     </div>
                </div>
                <span>
                  <div><br>
                  </div>
                  -- <br>
                  <div>
                    <div dir="ltr">
                      <div>
                        <div dir="ltr">
                          <div dir="ltr">
                            <div dir="ltr">
                              <div dir="ltr">
                                <div dir="ltr">
                                  <div>Johnathan Corgan<br>
                                    Corgan Labs - SDR Training and
                                    Development Services</div>
                                  <div><a href="http://corganlabs.com" style="font-size:12.8px" target="_blank">http://corganlabs.com</a><br>
                                  </div>
                                </div>
                              </div>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </span></div>
            </div>
            <br>
            _______________________________________________<br>
            bitcoin-dev mailing list<br>
            <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
            <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
bitcoin-dev mailing list
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </span></div>

</blockquote></div><br></div></div>