Feedback-ID: i525146e8:Fastmail
Date: Fri, 20 Oct 2023 17:34:28 +0000
From: Peter Todd <pete@petertodd.org>
To: Fabian <fjahr@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZTK6JINSo6WyvJL0@petertodd.org>
References: <kxXtwQMByYbMavS5P9a2tAUd8wz0yTUifost_txwTiQfNKTBtgdepLmAyV4XN6m4wY74cdZLX4EtsiEJ-jpZsnSxPIrCAN5wK8eK8xx1WGw=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="hIYWMfa3kkDKACtz"
Content-Disposition: inline
In-Reply-To: <kxXtwQMByYbMavS5P9a2tAUd8wz0yTUifost_txwTiQfNKTBtgdepLmAyV4XN6m4wY74cdZLX4EtsiEJ-jpZsnSxPIrCAN5wK8eK8xx1WGw=@protonmail.com>
Subject: Re: [bitcoin-dev] Breaking change in calculation of
	hash_serialized_2
Precedence: list


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

On Fri, Oct 20, 2023 at 05:19:19PM +0000, Fabian via bitcoin-dev wrote:
> Hello list,
>=20
> on Wednesday I found a potential malleability issue in the UTXO set dump =
files
> generated for and used by assumeutxo [1]. On Thursday morning theStack had
> found the cause of the issue [2]: A bug in the serialization of UTXOs for=
 the
> calculation of hash_serialized_2. This is the value used by Bitcoin Core =
to
> check if the UTXO set loaded from a dump file matches what is expected. T=
he
> value of hash_serialized_2 expected for a particular block is hardcoded i=
nto
> the chainparams of each chain.

<snip>

> [1] https://github.com/bitcoin/bitcoin/issues/28675
> [2] https://github.com/bitcoin/bitcoin/issues/28675#issuecomment-17703894=
68[3] https://github.com/bitcoin/bitcoin/pull/28685

James made the following comment on the above issue:

> Wow, good find @fjahr et al. I wonder if there's any value in committing =
to a
> sha256sum of the snapshot file itself in the source code as a
> belt-and-suspenders remediation for issues like this.

Why *isn't* the sha256 hash of the snapshot file itself the canonical hash?
That would obviously eliminate any malleability issues. gettxoutsetinfo alr=
eady
has to walk the entire UTXO set to calculate the hash. Making it simply
generate the actual contents of the dump file and calculate the hash of it =
is
the obvious way to implement this.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmUyuiEACgkQLly11TVR
Lze/uQ/9FwPyc/O06kMIhT0kf17QE3Dg9AYOXR5D9Dqiz9EoLigfcmfD9VEhbEM9
IWUYNhiLzoPhAAFIIF8ypzfYrnhuT/JnoNKLsX0lC3z6CBnBMabfcEGg+aqjGIyi
iOhaDtdIVRNq7nXchSdsY6BuNrxUMauqguRJzKiR391V43jhJ2GrCtG+Wa1u+KhE
S0x4Pr4Yc8RQ4423WMh1KdblHEYz/zO41XP8V9/liWHBqRSohkmypgKD4Uq4FYAJ
K7uxkWu0Eqyv3h8rOtSautbIm6LQwXhhiXiWHdKz/9xlkNUd4BO+CoWWfp2Cet93
99Dgo9Y3Tlk4S3PlNv4REgCLE74WPXerX1Rnvhe1Nmfq+gjMnUHLfLKtWk95f/uY
4ejpHznNK3+OeYSBWA/jx3GUHnqjto6wC3ycITgMIxsY7Spzdfs3psowxUIOUYgL
6YJHpqJu3iOnyFFh037/EkPEmAk/ytoxkPvQXljqw88ub5tQbiMB5c2VxERXgXUz
EqAw4vREmyjFfemgkPyaPqKCJCeCSPtnlJDd1edm1G/MIsACbDZHSx8XWnH9YyBm
IAXG3HNQpZ+qxOBcbR46wwfadI+ULcw1h+yslWE0mbk5DpPxDARk7qg4NEUgo/6N
jjqI4t8vgasFqnogMdk3m1aQ47RiHJpndYP/gCIR4OErOfOZJr4=
=dHmq
-----END PGP SIGNATURE-----

--hIYWMfa3kkDKACtz--