A Bitcoin transaction is a transfer of value between two Bitcoin addresses. A transaction is typically initiated by a payee sending over a public address to a payer who wants to send Bitcoin to the payee. The payer will use the software wallet of their choice to compile the transaction, stipulating the amount of funds to be sent, the fee rate they are willing to pay miners and the intended address to send the payment.
Once all the information is compiled to form the transaction, it is broadcast via a full node to the mempool, where it will remain until a miner picks up the transaction and adds it to a block. The transaction is broadcast to the Bitcoin network and is verified by miners. Once a transaction is confirmed, it becomes part of the historical data of the Bitcoin blockchain and new blocks are added on top of it.
When creating a transaction, you’re compiling data locally and sending it to the Bitcoin network via an internet connection. While most of us will follow a variation of the steps above, there might be other ways to transfer Bitcoin soon.
Where does TX compression come from?
Tom Briar and Andrew Poelstra have been working on a proposed implementation of compressed Bitcoin transactions. Smaller transactions would be more practical to relay through bandwidth-constrained mediums, such as by satellite or steganography (e.g., encoding a transaction in a bitmap image).
The idea originated from the idea of using steganography in combination with Bitcoin. Steganography is used to conceal information within another message or physical object to avoid detection. Content concealed through steganography is sometimes encrypted before being hidden within another file format. If it isn’t encrypted, it may be processed somehow to make it harder to detect.
Steganography can be used to hide virtually any type of digital content, including text, image, video, or audio content or, in this case, a Bitcoin transaction.
The data can be passed on through any medium or platform and avoid detection of its true intent, and the hidden data is then extracted at its destination.
Compressing Bitcoin transactions
Traditional compression algorithms take advantage of most structured data having some elements that occur more frequently than other elements. Typical Bitcoin transactions consist largely of uniform elements—data that looks random—like public keys and hash digests, so finding ways to use the data cleverly can result in saving space.
The Transaction Compression Schema uses several methods to compress transactions, including dropping data and recovering it on decompression by grinding until we obtain valid signatures.
The bulk of our size savings come from replacing the prevout of each input with a block height and index. This requires the decompression to have access to the blockchain and also means that compression is ineffective for transactions that spend unconfirmed or insufficiently confirmed outputs.
Even without compression, Taproot keyspends are very small: as witness data, they include only a single 64/65-byte signature and do not repeat the public key or any other metadata. By using pubkey recovery, one could obtain Taproot-like compression for legacy and Segwit transactions.
Briar’s proposal addresses this using several approaches:
- For the parts of a transaction where an integer is currently represented by 4 bytes (e.g., transaction version and outpoint index), these are replaced by a variable-length integer that can be as small as 2 bits.
- The uniformly distributed 32-byte outpoint TXID in each input is replaced by a reference to the location of that transaction in the blockchain using its block height and location within the block, e.g. 123456 and 789 would indicate the 789th transaction in block 123,456. Because the block at a particular height can change due to a blockchain reorganisation (breaking the reference and making it impossible to uncompress the transaction), this method is only used when the referenced transaction has at least 100 confirmations.
- For P2WPKH transactions where the witness structure needs to include a signature plus a 33-byte public key, the public key is omitted, and a technique of reconstructing it from the signature is used.
Early tests of these transaction compression methods have reported up to a 35% reduction in size, with some other techniques proposed that could save additional bytes in typical transactions.
What would compressed transactions be used for?
Bitcoin transactions are compressed to reduce their size and make them more efficient while encrypting the data so it cannot be extracted easily. This is done by removing any unnecessary data from the transaction, such as the sender’s and receiver’s addresses.
An example of how these transactions could work is when Alice encrypts her transaction into an image and sends it to Bob; Bob would then need to use his Bitcoin full node to decrypt the image and the transaction data to redeem the funds.
Transaction compression can be useful in situations where a user might not have easy access to high-bandwidth internet, such as when they are using a satellite connection, radio wave broadcasting or transferring a transaction via another network like SMS, MMS or RCS.
These transactions are not only ideal for places with limited connection, bringing Bitcoin transactions to parts of the world without modern communications infrastructure, but it could be a method of getting around capital controls as users transfer concealed payments across methods not known for Bitcoin transactions.
Limitations of Bitcoin transaction compression
One downside is that processing a compressed transaction requires more CPU, memory, and I/O when compared to a regular serialised transaction. Converting a compressed transaction back into something that full nodes and other software can understand will require more resources.
This means that high-bandwidth connections will likely continue to use the regular transaction format, and this method would be relegated to only low-bandwidth transmission, where it is your only option.
Do your own research.
If you want to learn more about compressed transactions, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
