📅 Original date posted:2021-04-24
📝 Original message:https://bitcointalk.org/index.php?topic=5303978.msg55946632#msg55946632
Blockstream satellite codebase includes an alternative serialization
that works a single transaction at a time and saves ~20%. This avoids
violating layering, preserves single txn access, is compatible with
transaction relay. (and if you wanted could also be fed to a
multiple txn at a time compressor for additional savings). This
format makes intelligent use of the entirety of the transaction
format, not just amount encodings but even optimizing predictable
hashes (e.g. for p2sh embedded segwit) -- achieving savings that *no*
generic compressor could ever achieve.
Most of the savings from generic compressors comes from repeated
pubkeys and addresses, so it's highly variable, depends on address
reuse, and will likely be diminished by taproot (due to shrinking
multisig) and very much reduced by signature aggregation in the
future.
If you're thinking about use across networks generic compression
interfaces like zlib have had a pretty disappointing security track
record.
If you search the list archive and bitcoin-core github you'll find
many prior discussions of using generic compressors.
On Sat, Apr 24, 2021 at 6:12 PM NITSOPOULOS KONSTANTINOS via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi, I can compress new blocks by up to 18% using the 7z file type. I use wxHexEditor to dump a block's raw hex onto my disk, and then compress that with 7-Zip. I'd like to see 7z built into Bitcoin Core, for block compression (storage & propagation). The entire blockchain could be under 290GB if it's converted into a 7z archive-chain ("7z-chain"). I can compress some recent example blocks (hex -> less hex) if anyone wants. A future BIP could try increase the block Weight Units limit by up to 21% if 7z blocks are smaller & quick.
>
> Programming compression seems too difficult for me, so I'm hoping somebody else does it!
>
> Eventually I think transactions can be compressed by replacing addresses (& public keys) and coins, wherever possible, with just their own unique sequential index. TX amounts can also be compressed if they contain only a decimal digit or two, e.g. 00000000.10000000 XBT. A TX of 0.1 XBT between two existing addresses could be somehow compressed to half or maybe a quarter of its current size!
>
> -Tinos
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Greg Maxwell [ARCHIVE] /
npub1c9…hzwwn
2023-06-07 22:52:21
in reply to nevent1q…awzk
Author Public Key
npub1c9wgsqxhgl9fjfsvyflg5tj9rzd78ptkpjjkhmyqghj2r045vyasthzwwnSeen on
wss://relay.nostr.bandPublished at
2023-06-07 22:52:21Event JSON
{
"id": "b23379ec8de8e82b53d79f4f8d32075f207c32ac5a2228f6b9abddb57995596e",
"pubkey": "c15c8800d747ca99260c227e8a2e45189be385760ca56bec8045e4a1beb4613b",
"created_at": 1686178341,
"kind": 1,
"tags": [
[
"e",
"60d9b6811484c0b8a441bbbe733177ab8ce199857b0394ae7c71c6c242599aa7",
"",
"root"
],
[
"e",
"3350b56b85dc7d7137382dd7d6ea557426e1435f78e090c60edd2e6a86f72a8a",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2021-04-24\n📝 Original message:https://bitcointalk.org/index.php?topic=5303978.msg55946632#msg55946632\n\nBlockstream satellite codebase includes an alternative serialization\nthat works a single transaction at a time and saves ~20%. This avoids\nviolating layering, preserves single txn access, is compatible with\ntransaction relay. (and if you wanted could also be fed to a\nmultiple txn at a time compressor for additional savings). This\nformat makes intelligent use of the entirety of the transaction\nformat, not just amount encodings but even optimizing predictable\nhashes (e.g. for p2sh embedded segwit) -- achieving savings that *no*\ngeneric compressor could ever achieve.\n\nMost of the savings from generic compressors comes from repeated\npubkeys and addresses, so it's highly variable, depends on address\nreuse, and will likely be diminished by taproot (due to shrinking\nmultisig) and very much reduced by signature aggregation in the\nfuture.\n\nIf you're thinking about use across networks generic compression\ninterfaces like zlib have had a pretty disappointing security track\nrecord.\n\n\nIf you search the list archive and bitcoin-core github you'll find\nmany prior discussions of using generic compressors.\n\n\n\nOn Sat, Apr 24, 2021 at 6:12 PM NITSOPOULOS KONSTANTINOS via\nbitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi, I can compress new blocks by up to 18% using the 7z file type. I use wxHexEditor to dump a block's raw hex onto my disk, and then compress that with 7-Zip. I'd like to see 7z built into Bitcoin Core, for block compression (storage \u0026 propagation). The entire blockchain could be under 290GB if it's converted into a 7z archive-chain (\"7z-chain\"). I can compress some recent example blocks (hex -\u003e less hex) if anyone wants. A future BIP could try increase the block Weight Units limit by up to 21% if 7z blocks are smaller \u0026 quick.\n\u003e\n\u003e Programming compression seems too difficult for me, so I'm hoping somebody else does it!\n\u003e\n\u003e Eventually I think transactions can be compressed by replacing addresses (\u0026 public keys) and coins, wherever possible, with just their own unique sequential index. TX amounts can also be compressed if they contain only a decimal digit or two, e.g. 00000000.10000000 XBT. A TX of 0.1 XBT between two existing addresses could be somehow compressed to half or maybe a quarter of its current size!\n\u003e\n\u003e -Tinos\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",
"sig": "5e0940acd82e095aca5f45387af5eda732c90220c19aa7a10fb47be65b6c5aefbb91132305522783913733fee658199001478f882c6f3d9fb6b451a90e299346"
}