📅 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 <fjahr at 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 at lists.linuxfoundation.org> 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>;
Fabian [ARCHIVE] /
npub1wc…ehvcp
2023-09-07 11:52:35
in reply to nevent1q…xl8y
Author Public Key
npub1wcar64n6956qjf28fxpepytx89up2ty4gex0zqzntpxnt7djydvsyehvcpSeen on
wss://nos.lolPublished at
2023-09-07 11:52:35Event JSON
{
"id": "1d79ea5f5e316280ec9ef40ac772c83d7d89de646aa7a8c9582853d003999687",
"pubkey": "763a3d567a2d3409254749839091663978152c95464cf10053584d35f9b22359",
"created_at": 1694087555,
"kind": 1,
"tags": [
[
"e",
"78fe78a45d9bfe314bbcb6fae22953a0d8cd7b75e1607bd1dafdcafde1e45cfb",
"",
"root"
],
[
"e",
"c2417943cafb8c8ee976472d466ed87dd61dc6172bfd8970be72f0ccaa22e4ee",
"",
"reply"
],
[
"p",
"763a3d567a2d3409254749839091663978152c95464cf10053584d35f9b22359"
]
],
"content": "📅 Original date posted:2023-09-01\n🗒️ 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.\n📝 Original message:\nHi Tom,\n\nI 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.\n\nFabian\n------- Original Message -------\nOn Friday, September 1st, 2023 at 12:24 PM, Fabian \u003cfjahr at protonmail.com\u003e wrote:\n\n\u003e Hi Tom,\n\u003e\n\u003e without having gone into the details yet, thanks for the great effort you have put into this research and implementation already!\n\u003e\n\u003e\u003e The bulk of our size savings come from replacing the prevout of each input by a block height and index.\n\u003e\n\u003e 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.\n\u003e\n\u003e Thanks,\n\u003e Fabian\n\u003e ------- Original Message -------\n\u003e On Thursday, August 31st, 2023 at 11:30 PM, Tom Briar via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hey everyone,\n\u003e\u003e\n\u003e\u003e I've been working on a way to compress bitcoin transactions for transmission throughsteganography, satellite broadcasting,\n\u003e\u003e and other low bandwidth channels with high CPU availability on decompression.\n\u003e\u003e\n\u003e\u003e [compressed_transactions.md](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md)\n\u003e\u003e\n\u003e\u003e In the document I describe a compression schema that's tailored for the most common transactions single parties are likely to make.\n\u003e\u003e In every case it falls back such that no transaction will become malformed or corrupted.\n\u003e\u003e Here's a PR for implementing this schema.\n\u003e\u003e\n\u003e\u003e [2023 05 tx compression](https://github.com/TomBriar/bitcoin/pull/3)\n\u003e\u003e Thanks-\n\u003e\u003e Tom.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230901/ea64af6d/attachment-0001.html\u003e",
"sig": "5803d86a7718b1011d23b0182246630834cdef3d0264e2ebd829aab48d2578c14157b13b99f1167943e8f2685357bc7bba3688e6db83e10160b3987edbc6ede2"
}