š
Original date posted:2015-11-09
š Original message: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.
I absolutely would not dismiss 25% compression. gzip and bzip2 compression
is relatively standard, and I'd consider the point of implementation
complexity tradeoff to be somewhere along 5-10%.
On Tue, Nov 10, 2015 at 8:04 AM, Bob McElrath via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I would expect that since a block contains mostly hashes and crypto
> signatures,
> it would be almost totally incompressible. I just calculated compression
> ratios:
>
> zlib -15% (file is LARGER)
> gzip 28%
> bzip2 25%
>
> So zlib compression is right out. How much is ~25% bandwidth savings
> worth to
> people? This seems not worth it to me. :-/
>
> Peter Tschipper via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]
> wrote:
> > This is my first time through this process so please bear with me.
> >
> > I opened a PR #6973 this morning for Zlib Block Compression for block
> > relay and at the request of @sipa this should have a BIP associated
> > with it. The idea is simple, to compress the datastream before
> > sending, initially for blocks only but it could theoretically be done
> > for transactions as well. Initial results show an average of 20% block
> > compression and taking 90 milliseconds for a full block (on a very slow
> > laptop) to compress. The savings will be mostly in terms of less
> > bandwidth used, but I would expect there to be a small performance gain
> > during the transmission of the blocks particularly where network latency
> > is higher.
> >
> > I think the BIP title, if accepted should be the more generic, "Support
> > for Datastream Compression" rather than the PR title of "Zlib
> > Compression for block relay" since it could also be used for
> > transactions as well at a later time.
> >
> > Thanks for your time...
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > !DSPAM:5640ff47206804314022622!
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/0d844af0/attachment.html>;
gladoscc [ARCHIVE] /
npub138ā¦4h7my
2023-06-07 17:44:22
in reply to nevent1qā¦53y4
Author Public Key
npub138yeqaf7leywengpmjy44kcv08cers44gu784mhum2h7u8yw8sns74h7myPublished at
2023-06-07 17:44:22Event JSON
{
"id": "897c43453c2ac7cf6d50e985be02ad9aa96261367961e47d30838d807bd05b92",
"pubkey": "89c990753efe48eccd01dc895adb0c79f191c2b5473c7aeefcdaafee1c8e3c27",
"created_at": 1686159862,
"kind": 1,
"tags": [
[
"e",
"135d35eb642f6996f1dd35c63783ed01db4ec3c84bf3636c660d5a16e2852ec0",
"",
"root"
],
[
"e",
"6f12831672442b426ab2ae2ab97ee8c517e3910dc0c563f45bc385d66689eef1",
"",
"reply"
],
[
"p",
"a4fc2fc2bfc061e75a1b6e17dfc4b3c93b85fab2fc91001f44fd8499d672b169"
]
],
"content": "š
Original date posted:2015-11-09\nš Original message:I think 25% bandwidth savings is certainly considerable, especially for\npeople running full nodes in countries like Australia where internet\nbandwidth is lower and there are data caps.\n\nI absolutely would not dismiss 25% compression. gzip and bzip2 compression\nis relatively standard, and I'd consider the point of implementation\ncomplexity tradeoff to be somewhere along 5-10%.\n\nOn Tue, Nov 10, 2015 at 8:04 AM, Bob McElrath via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I would expect that since a block contains mostly hashes and crypto\n\u003e signatures,\n\u003e it would be almost totally incompressible. I just calculated compression\n\u003e ratios:\n\u003e\n\u003e zlib -15% (file is LARGER)\n\u003e gzip 28%\n\u003e bzip2 25%\n\u003e\n\u003e So zlib compression is right out. How much is ~25% bandwidth savings\n\u003e worth to\n\u003e people? This seems not worth it to me. :-/\n\u003e\n\u003e Peter Tschipper via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]\n\u003e wrote:\n\u003e \u003e This is my first time through this process so please bear with me.\n\u003e \u003e\n\u003e \u003e I opened a PR #6973 this morning for Zlib Block Compression for block\n\u003e \u003e relay and at the request of @sipa this should have a BIP associated\n\u003e \u003e with it. The idea is simple, to compress the datastream before\n\u003e \u003e sending, initially for blocks only but it could theoretically be done\n\u003e \u003e for transactions as well. Initial results show an average of 20% block\n\u003e \u003e compression and taking 90 milliseconds for a full block (on a very slow\n\u003e \u003e laptop) to compress. The savings will be mostly in terms of less\n\u003e \u003e bandwidth used, but I would expect there to be a small performance gain\n\u003e \u003e during the transmission of the blocks particularly where network latency\n\u003e \u003e is higher.\n\u003e \u003e\n\u003e \u003e I think the BIP title, if accepted should be the more generic, \"Support\n\u003e \u003e for Datastream Compression\" rather than the PR title of \"Zlib\n\u003e \u003e Compression for block relay\" since it could also be used for\n\u003e \u003e transactions as well at a later time.\n\u003e \u003e\n\u003e \u003e Thanks for your time...\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e !DSPAM:5640ff47206804314022622!\n\u003e --\n\u003e Cheers, Bob McElrath\n\u003e\n\u003e \"For every complex problem, there is a solution that is simple, neat, and\n\u003e wrong.\"\n\u003e -- H. L. Mencken\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/0d844af0/attachment.html\u003e",
"sig": "90abcbf15453cf3e159291af1592a25158aba20e3af370ab2656970664150a277c0e6f09b5369f42f4dc8460b3e6502250f341bdf93cb8c1e9e59ea73cdf1c71"
}