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 <fjahr@protonmail.com> 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:

Hey everyone, 

I've been working on a way to compress bitcoin transactions for transmission through steganography, satellite broadcasting, 
and other low bandwidth channels with high CPU availability on decompression. 


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.


Thanks-
Tom.