Nostr Web Client

📅 Original date posted:2023-08-31

🗒️ Summary of this message: Tom Briar has developed a compression schema for bitcoin transactions that can be transmitted through low bandwidth channels without corruption.

📝 Original message:

On Thu, Aug 31, 2023 at 09:30:16PM +0000, 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)

Hey Tom,

Thank you for posting this. Could you put together a chart with some

size numbers so we can get a picture of how strong this compression is?

I understand that because this is targeted at stego/satellite

applications where the user is expected to "shape" their transaction,

that you won't get great numbers if you just look at the historical

chain or try to analyze "average" transactions. But it would be great to

post a chart with uncompressed/compressed sizes for "optimum"

transactions. At the very least, a 2-in-2-out wpkh transaction, and a

2-in-2-out Taproot transaction.

Since the scheme includes explicit support for p2sh-wpkh and p2pkh it

would also be great to see numbers for those, though they're less common

and less interesting.

Cheers

Andrew

Andrew Poelstra

Director of Research, Blockstream

Email: apoelstra at wpsoftware.net

Web: https://www.wpsoftware.net/andrew

The sun is always shining in space

-Justin Lewis-Webster

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

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 488 bytes

Desc: not available

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230901/1a0ba0e7/attachment.sig>

Reply to this note

Please Login to reply.

Discussion

763a3d56... 2y ago

📅 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>

763a3d56... 2y ago

📅 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>