Published on: 2023-09-05T18:30:42+00:00
In the email exchange, Tom discusses various aspects of transaction compression in Bitcoin. He mentions that currently, if a lock time is non-zero, they drop the 16 most significant bits and continue until a valid signature is obtained. Tom expresses hesitancy to add more fields to this process as it can significantly increase decompression time. He suggests dropping grinding the lock time in favor of grinding the block height, which could potentially save several bytes in transactions. Tom is working on adding an ideal transaction specification to the documentation.Tom also discusses the possibility of saving bits by specifying a reference height and encoding the exact transaction output with a delta. He suggests using the reference block height at the beginning of a packet for multiple transactions. If only a single transaction is sent, a reference height based on the current time could be used. Tom mentions that sender and receiver agreement on the exact time may require trying slightly different reference heights until the transaction signatures validate.The email exchange between Tom and the sender includes a discussion about obtaining numbers based on historical data and fuzz tests. Tom mentions updating the code to align with the documentation and estimates completing it before the end of the week. He also mentions estimating 100 blocks as safe from reorg and plans to include this limit in the compressrawtransaction RPC endpoint. Tom expresses gratitude for the feedback received.Another part of the email exchange revolves around discussions related to size numbers and the inclusion of a definition in the BIP. The sender expresses interest in having size numbers for comparison purposes and suggests adding a definition clarifying when it is not advisable to use height/index due to reorganizations. Tom responds by agreeing with Andrew's point about using a prefix tree requiring more space compared to using just the block height and an index. They have implemented a flattened index over all transactions and outputs per block, aligning with the suggestion. Tom suggests potentially reducing the number of bits needed for the block height by using a threshold indicator. The email does not provide any specific links or additional context beyond the discussion on encoding and reducing required bits.The email from Andrew Poelstra discusses the consideration of indexing all transaction outputs using ordinals but ultimately deciding against it due to extra index requirements for the decompressor. Andrew mentions their previous exploration of putting the UTXO set into a trie for prefix lookups but discarded the idea due to similar reasons and potential user behavior issues. He also acknowledges being put off by the complexity of the data structure as it no longer fits in RAM. Implementing a new index would require significant effort and decrease chances of getting code into Core. Andrew estimates saving slightly less than a byte per input on average but concludes that it's not worth the decreased user experience and increased complexity.In an email response, Fabian acknowledges simplifying his previous message and clarifies that an index of the UTXO set would require a height. He suggests considering a composite reference or a short hash, but acknowledges that Tom's current scheme may be more space efficient. Another email from Fabian suggests using an index from a sorted UTXO set instead, potentially saving space and making the scheme compatible with pruning. He mentions this as a future research topic but hasn't explored it yet.Tom is thanked for his research and implementation efforts in another email. The sender suggests analyzing the compression strength of a certain application and requests Tom to create a chart showing uncompressed/compressed sizes for different types of transactions. Andrew emphasizes the importance of including "optimum" transactions such as wpkh and Taproot transactions, as well as p2sh-wpkh and p2pkh transactions, even though they are less common. He provides his contact information and signs off with a quote about the sun always shining in space.Lastly, Tom has been working on a compression schema specifically designed for Bitcoin transactions that can be transmitted through low bandwidth channels with high CPU availability on decompression. The schema ensures that no transaction will become malformed or corrupted and Tom has provided a pull request for its implementation.Please note that the extracted information is presented in multiple paragraphs, follows formal tone, retains links, and summarizes the main points discussed in each email.
Updated on: 2023-09-06T01:55:10.447975+00:00