On 10/11/2015 8:45 AM, Peter Tschipper wrote: > On 10/11/2015 8:30 AM, Tier Nolan via bitcoin-dev wrote: >> >> >> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper >> wrote: >> >> There are better ways of sending new blocks, that's certainly >> true but for sending historical blocks and seding transactions I >> don'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. >> >> >> If the main point is for historical data, then sticking to just >> blocks is the best plan. >> > at the beginning yes. >> Since small blocks don't compress well, you could define a "cblocks" >> message that handles multiple blocks (just concatenate the block >> messages as payload before compression). >> > Small block are rare these days (but plenty of historical block), but > still they get a 10% compression, not bad and I think worthwhile and > the time it takes to compress small blocks is less that a millisecond > so no loss there in time. But still you have a good point and > something worthy of doing after getting compression to work. I think > it's wise to keep it simple at first and build on the success later. >> 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). > Good idea. Same answer as above. >> Similarly, transactions could be combined together and compressed >> "ctxs". 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. >> > Good idea. Same answer as above. >> More generally, you could define a message which is a compressed >> message holder. That is probably to complex to be worth the effort >> though. > That's actually pretty easy to do and part of the plan. Sending a > cmp_block rather than a block makes it all easier to implement. It's > just a matter of doing pnode->pushmessage("cmp_block", > compressed_block); and handling the "cmp_block" command string at the > other end. >> >> >> >>> >>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via >>> bitcoin-dev >> > wrote: >>> >>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev >>> wrote: >>> >>> >>> 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. >>> >>> >>> ​ 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.​ >>> >>> >>> -- >>> Johnathan Corgan >>> Corgan Labs - SDR Training and Development Services >>> http://corganlabs.com >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >