0

I have two similar questions

  • Why aren't transactions compressed in the P2P layer (and why wasn't this discussed in the agenda)?
  • Why aren't transactions compressed before they're added to a block? (Effectively a block size increase) Are there reasons other than avoiding a hard fork?
3
  • What agenda are you talking about?
    – Claris
    Feb 27 at 19:45
  • Any discussion today including bips and fork altcoins
    – MCCCS
    Feb 27 at 20:48
  • 1
    Asking about agendas is pointless - there isn't any entity that can set one. People, and organizations may have agendas, but those may conflict, or just go nowhere for unrelated reasons. In general the answer to questions like this, as stated, is simply "nobody has found it important enough to work on and/or push for". A more informative question would be asking about known difficulties or other limitations, rather than asking why it isn't done. Feb 27 at 22:46
3
  • Transactions themselves do not compress well, they are mostly cryptographic hashes and signatures. You can save a couple of bytes here and there by bit-packing, but generally speaking there's not a lot of reason to introduce massive complexity for moderate savings. Many wallets today grind the signatures to save an extra byte, but this is possible without changing any of the other software in the network.

    A good portion of the transactions (30%) are produced by wallets which do not use compressed ECDSA keys, which is a more obvious optimization to make. The majority of these are likely produced by blockchain.com wallets.

  • See above. Compression at the block level also does not present significant improvements. It is possible to compress ECDSA public keys (that are in the uncompressed format) before storing them on disk, but this is very computationally expensive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.