📅 Original date posted:2015-11-10
📝 Original message:The network protocol is not quite consensus critical, but it is important.
Two implementations of the decompressor might not be bug for bug
compatible. This (potentially) means that a block could be designed that
won't decode properly for some version of the client but would work for
another. This would fork the network.
A "raw" network library is unlikely to have the same problem.
Rather than just compress the stream, you could compress only block
messages only. A new "cblock" message could be created that is a
compressed block. This shouldn't reduce efficiency by much.
If a client fails to decode a cblock, then it can ask for the block to be
re-sent as a standard "block" message.
This means that it is a pure performance improvement. If problems occur,
then the client can just switch back to uncompressed mode for that block.
You should look into the block relay system. This gives a larger
improvement than simply compressing the stream. The main benefit is
latency but it means that actual blocks don't have to be sent, so gives a
potential 50% compression ratio. Normally, a node receives all the
transactions and then those transactions are included later in the block.
On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> 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 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/81ba0c7c/attachment-0001.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 17:44:22
in reply to nevent1q…fzxs
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 17:44:22Event JSON
{
"id": "63eb70f5482fa0cdaa4abcef240dbede668ea743a9b70a4caa382cdbda3079fa",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686159862,
"kind": 1,
"tags": [
[
"e",
"135d35eb642f6996f1dd35c63783ed01db4ec3c84bf3636c660d5a16e2852ec0",
"",
"root"
],
[
"e",
"0f4946d7fdd6e68a610405eb8b48500fc052e1d52c3713aae528e9dbec968c6e",
"",
"reply"
],
[
"p",
"96b5dcd8eedfa403b3a94c15f3bab1cb084736a0f2f1301119d1819109ecc06d"
]
],
"content": "📅 Original date posted:2015-11-10\n📝 Original message:The network protocol is not quite consensus critical, but it is important.\n\nTwo implementations of the decompressor might not be bug for bug\ncompatible. This (potentially) means that a block could be designed that\nwon't decode properly for some version of the client but would work for\nanother. This would fork the network.\n\nA \"raw\" network library is unlikely to have the same problem.\n\nRather than just compress the stream, you could compress only block\nmessages only. A new \"cblock\" message could be created that is a\ncompressed block. This shouldn't reduce efficiency by much.\n\nIf a client fails to decode a cblock, then it can ask for the block to be\nre-sent as a standard \"block\" message.\n\nThis means that it is a pure performance improvement. If problems occur,\nthen the client can just switch back to uncompressed mode for that block.\n\nYou should look into the block relay system. This gives a larger\nimprovement than simply compressing the stream. The main benefit is\nlatency but it means that actual blocks don't have to be sent, so gives a\npotential 50% compression ratio. Normally, a node receives all the\ntransactions and then those transactions are included later in the block.\n\n\n\nOn Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\n\u003e\u003e I think 25% bandwidth savings is certainly considerable, especially for\n\u003e\u003e people running full nodes in countries like Australia where internet\n\u003e\u003e bandwidth is lower and there are data caps.\n\u003e\u003e\n\u003e\n\u003e This reinforces the idea that such trade-off decisions should be be local\n\u003e and negotiated between peers, not a required feature of the network P2P.\n\u003e\n\u003e\n\u003e --\n\u003e Johnathan Corgan\n\u003e Corgan Labs - SDR Training and Development Services\n\u003e http://corganlabs.com\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/81ba0c7c/attachment-0001.html\u003e",
"sig": "2b9aa7691d5e89946fd07fb445301c4c37eb4dc8101139b84762f9a93721bdfd037fd717ef6db1f5d3d2e6f74c7d1b1bc678b7aec4b7a62bf170c50d726c177e"
}