Hi Tom, I realized I simplified my message a bit too much. Of course an index of the UTXO set would also need a height, so I rather meant some kind of composite reference I guess. An index alone might be enough if a height has been pre-agreed which could still be compatible with the use-cases you might have in mind, this might be very interesting in combination with assumeutxo. Otherwise a short hash could be used but then I also think your current scheme might be more space efficient than this. Fabian ------- Original Message ------- On Friday, September 1st, 2023 at 12:24 PM, Fabian wrote: > Hi Tom, > > without having gone into the details yet, thanks for the great effort you have put into this research and implementation already! > >> The bulk of our size savings come from replacing the prevout of each input by a block height and index. > > Have you also considered using just an index from a sorted UTXO set instead? The potential additional space saving might be minor but this would make the scheme compatible with pruning. I had this on my list as a future research topic but didn't get around to it yet. > > Thanks, > Fabian > ------- Original Message ------- > On Thursday, August 31st, 2023 at 11:30 PM, Tom Briar via bitcoin-dev wrote: > >> Hey everyone, >> >> I've been working on a way to compress bitcoin transactions for transmission throughsteganography, satellite broadcasting, >> and other low bandwidth channels with high CPU availability on decompression. >> >> [compressed_transactions.md](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md) >> >> In the document I describe a compression schema that's tailored for the most common transactions single parties are likely to make. >> In every case it falls back such that no transaction will become malformed or corrupted. >> Here's a PR for implementing this schema. >> >> [2023 05 tx compression](https://github.com/TomBriar/bitcoin/pull/3) >> Thanks- >> Tom.