Are transactions compressed?

[JasonWoods]

I've been playing around some with raw transactions; one of them had a size of 4401 bytes when signed. So for a test, I compressed it with bzip2, and the resulting (hex) was only 1680 bytes

Code:

cat signed.txt | bzip2 | openssl enc -base64 -A -out signedbz2.txt

That's almost a third of space that's saved, so the fee would go down noticeable too, and more transactions would fit into a block.

I know keys can be compressed, but what about a transaction itself?

[1701405574]

1701405574

[ranochigo]

The reason for the public keys to be able to be compressed or uncompressed is due to the property of the ECDSA curve. The curve has the x and y coordinates but the compressed keys only specify the x coordinate and the client can figure out what is the correct y coordinate, of the two possible coordinates. This isn't computationally intensive and its easily implemented.

With transaction, it is a different case. If you were to compress it like that, the client would have to uncompress the transactions, every single time they validate it. Same thing with when someone mines a block. A side effect of this is the increase in the rate of transactions, which wouldn't be good, considering the tradeoff for it.

[aleksej996]

Compression will be very useful for some specific transactions, but for most it will not, so it is not worth it.
If you ever tried compressing entire blockchain, you will quickly see why. It takes a lot of time and it results not so impressive decrease in size, not even half the original size.

Transactions use a lot of cryptography and in good cryptography results are most often very random looking.
This goes for signatures,keys, etc. It just tends not to be very secure if there is a pattern.

[JasonWoods]

With transaction, it is a different case. If you were to compress it like that, the client would have to uncompress the transactions, every single time they validate it. Same thing with when someone mines a block. A side effect of this is the increase in the rate of transactions, which wouldn't be good, considering the tradeoff for it.

Compression will be very useful for some specific transactions, but for most it will not, so it is not worth it.

The transactions have to be decoded anyway, so pushing them through a bunzip2 should not be that dramatic.

In exchange, you could reduce fees to about a third and increase transactions per block 3 times (more or less, one would have to test with a significant number of transactions to get the average compression rate).

With fees going through the roof and tx/s being rather low, I don't see why increasing the tx rate would be bad.

[pebwindkraft]

The transactions have to be decoded anyway, so pushing them through a bunzip2 should not be that dramatic.

In exchange, you could reduce fees to about a third and increase transactions per block 3 times (more or less, one would have to test with a significant number of transactions to get the average compression rate).

With fees going through the roof and tx/s being rather low, I don't see why increasing the tx rate would be bad.

There must be some soft facts, that were not yet expressed, which prevents from doing so. Where would compression/decompression affect the ecosystem?

- a full node at the initial load of blockchain: verifies each tx - so the time get's increased
- during creation of new blocks: each miner has to decompress the tx, adding a bit of time
- a small block with only a few tx will not benefit much (but currently vast majority of blocks are filled with a substantiate amount of tx)
- it might be a hardfork (ugh), or vice versa, serious thoughts must be put into making it a soft fork
(approach/thought/idea: similiar to the way, segwit tx are forwarded to non-segwit nodes, same logic could apply to compressed tx)

+ with Moore's law: processing power is increasing faster than network bandwidth, so a good point for compression
+ compression during transfer on the network: decreases the amount of data to be transferred, reducing load, reducing latency, positive network effects
+ for the "end user": reduced tx size reduces fees, a quick bargain at current times (but against interests of miners?)
+ the bigger blocks get (with many tx), the better size reduction is achieved

there are way more... 
I searched through the forum, if this wasn't discussed already. Nothing really found. Whenever such a topic is discussed, it quickly runs into overly complex discussion about possible implications in the future, which boils down into sovereignty over the interpretation of implications.

Only response to this would be a real "measurement": how much impact?
--> do a test setup and proof