public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Briar <tombriar11@protonmail.com>
To: Peter Todd <pete@petertodd.org>,
	Andrew Poelstra <apoelstra@wpsoftware.net>,
	"bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compressed Bitcoin Transactions
Date: Tue, 05 Sep 2023 18:30:42 +0000	[thread overview]
Message-ID: <hd13VCUTiTaX_Z4oeZpzwjdVOcmkbcg-kgfThk9b1LUt2YUCEXrwVuEq8BiNWtfzeAafo6GdsrFzGg3pQI5kSjuRc4TtFGmRndvVukAwAiY=@protonmail.com> (raw)
In-Reply-To: <ZPdswQ7uAJr35YbC@petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Hi Peter,

Currently, if we’re given a lock time that is non zero, we drop the 16 most significant bits and grind through until we have a valid signature. Therefore I am hesitant to add more fields to grind through, because it can get out of hand in decompression time really quickly. That said our ideal use case for transaction compression is small high security transactions, I doubt they will need a lock time in most cases. Perhaps we should drop grinding the lock time in favor of grinding the block height.

Either way assuming both parties agree on the block height(which is a must right now) having a single block height for the transaction might save us several bytes.

I’m working on adding an ideal transaction spec to the doc right now.

Thanks!-
Tom.

On Tue, Sep 5, 2023 at 12:00 PM, Peter Todd via bitcoin-dev <[bitcoin-dev@lists.linuxfoundation.org](mailto:On Tue, Sep 5, 2023 at 12:00 PM, Peter Todd via bitcoin-dev <<a href=)> wrote:

> On Fri, Sep 01, 2023 at 01:56:18PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>> We can swag what the space savings would be: there are 122MM utxos right
>> now, which is a bit under 2^27. So assuming a uniform distribution of
>> prefixes we'd need to specify 28 bits to identify a UTXO. To contrast,
>> to identify a blockheight we need 20 bits and then maybe 12 more bits to
>> specify a TXO within a block. Plus whatever varint overhead we have.
>> (I've been working on this project but busy with family stuff and don't
>> remember exactly where we landed on the varints for this. I think we
>> agreed that there was room for improvement but didn't want to hold up
>> posting the rest of the concept because of it.)
>
> Since most transactions spend txouts that are similar in height to each other,
> you could save further bits by specifying a reference height and then encoding
> the exact txout with a delta.
>
> If you're sending multiple txins or multiple transactions in a single packet,
> you could achieve this by starting the packet with the reference block height.
>
> If your application tends to send just a single transaction, you could use a
> reference height that is a function of the current time. Since sender and
> receiver might not agree on the exact time, you could try slightly difference
> reference heights via bruteforcing until the transaction signatures validate.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3121 bytes --]

  reply	other threads:[~2023-09-05 18:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-31 21:30 [bitcoin-dev] Compressed Bitcoin Transactions Tom Briar
2023-09-01  0:49 ` Andrew Poelstra
2023-09-01 10:24 ` Fabian
2023-09-01 10:43   ` Fabian
2023-09-01 13:56   ` Andrew Poelstra
2023-09-01 14:12     ` Tom Briar
2023-09-05 18:00     ` Peter Todd
2023-09-05 18:30       ` Tom Briar [this message]
2024-01-05 15:06         ` Tom Briar
2024-01-05 15:19           ` Andrew Poelstra
2024-01-09 15:31             ` Tom Briar
2024-01-16 17:08               ` Tom Briar
2024-01-18  9:24                 ` Jonas Schnelli
2024-01-19 21:09                   ` Tom Briar
2023-09-01 16:56 ` Jonas Schnelli
2023-09-01 17:05   ` Tom Briar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='hd13VCUTiTaX_Z4oeZpzwjdVOcmkbcg-kgfThk9b1LUt2YUCEXrwVuEq8BiNWtfzeAafo6GdsrFzGg3pQI5kSjuRc4TtFGmRndvVukAwAiY=@protonmail.com' \
    --to=tombriar11@protonmail.com \
    --cc=apoelstra@wpsoftware.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox