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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
