Replying to 763a3d56...

📅 Original date posted:2023-09-01

🗒️ Summary of this message: Tom thanks Fabian for his effort in the research and implementation. Fabian suggests using an index from a sorted UTXO set for potential space saving and compatibility with pruning.

📝 Original message:

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.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230901/5c5c8657/attachment-0001.html>

📅 Original date posted:2023-09-01

🗒️ Summary of this message: Fabian suggests using an index from a sorted UTXO set instead of a block height and index to save space in bitcoin transactions.

📝 Original message:

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.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230901/ea64af6d/attachment-0001.html>

Reply to this note

Please Login to reply.

Discussion

No replies yet.