Feedback-ID: i525146e8:Fastmail
Date: Tue, 5 Sep 2023 18:00:33 +0000
From: Peter Todd <pete@petertodd.org>
To: Andrew Poelstra <apoelstra@wpsoftware.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZPdswQ7uAJr35YbC@petertodd.org>
References: <WJoM7dyrk0o8ujOZOo462r66wS2Kl3L1ZZRodvaLK-HKEUc90yvwOqXbUUrGbV1lk6cOywTqLoCyHzk2Tm3TtBFyUL0NZ6D7v9NmTXypJPA=@protonmail.com>
 <KSmH1MBTPLuXMF4TWbWq6vaft_K_7IZS2YcoZ1iHwtHY06It1DjExVgSdrLBMQZA8mLGz8xdOzyXRHAZ2qCAugwG8gMtEGsGj-XNTPN0v0w=@protonmail.com>
 <ZPHtgiJQ4Yqrr941@camus>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="jhBCJUTj0zdymhQa"
Content-Disposition: inline
In-Reply-To: <ZPHtgiJQ4Yqrr941@camus>
Subject: Re: [bitcoin-dev] Compressed Bitcoin Transactions
Precedence: list


--jhBCJUTj0zdymhQa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 01, 2023 at 01:56:18PM +0000, Andrew Poelstra via bitcoin-dev w=
rote:
> 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 oth=
er,
you could save further bits by specifying a reference height and then encod=
ing
the exact txout with a delta.

If you're sending multiple txins or multiple transactions in a single packe=
t,
you could achieve this by starting the packet with the reference block heig=
ht.

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 differen=
ce
reference heights via bruteforcing until the transaction signatures validat=
e.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--jhBCJUTj0zdymhQa
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmT3bL8ACgkQLly11TVR
LzdQGQ/8DEjgazwJ82CA5NG5djwTF1pybNs3bjowdFC8uLmUjSGeK3Mwjve9M7Pl
irN6qMKwGtgoMCbRJvUVxuqgkra7LEy8wR+Z/e36AeP9oFDq3k6gzU5UtLnnQeqM
LMLofg9f9xrf8NKo1zC/DOAQ+jAH0RYZhHBlNFRYQEo0VpViKByqhSsKaCZarpCh
H4dHMof/j1x0AIVnqvdSKR8kb0PUm22RHLIgVZVzrecJarAkO91unDvJnq+1N1tX
/AAmIaJLVjhO9q2V1i2vW+q6n9wxJYdDiwEHoMnR0QkO0qMm5XjlFCnETPiWy3Zh
WkEBcIqZgXuZlTrSzpQaizQb4FyIB+hE9lihaZ9Xz2/DxfkmqtOqh7FG8xCLRiVi
Kpx/J0ZDLm+L13c7GmQaLLonfarx6iRRIf/F30R6GuvuUepN7qZ2BEGpNg7plDMq
KTthYUoKbuBZCO4GwtoM71JOAv/Sa3915+7G5hc4Gh0YZg7TkpwAb3CPVDlMsRM+
lCfrH06Xw7yGcmD+vbiR7G8r7fN0J5PzNrXnWyButiz/RfsiYkkv0cOdbDk4ylS+
qej3V1sL4/B1GGUrtXctr8ajowVtfblhhpuqvsEKlh48FTn3Cn2pV9BE9ywlEPox
UC281gECd6piiU0Oo3AtUIGT1qmHwM6mHUw8owrcpiblMn3a/WQ=
=jT/j
-----END PGP SIGNATURE-----

--jhBCJUTj0zdymhQa--