Message-ID: <53470E65.5080402@jcea.es>
Date: Thu, 10 Apr 2014 23:34:29 +0200
From: Jesus Cea <jcea@jcea.es>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP04O7EqB=TqyTiC7O1K2A9R0nKJ_ssANHKg=Byum8-LtA@mail.gmail.com>	<CA+s+GJDbYjwhpsV15a+7kCO_vTstEewVrwvqbnB=a5zOSwFC6Q@mail.gmail.com>	<CAAS2fgStmEpiUV4Yh-qqu6sZ+VZ5SiQPwp+QA=3X5zR52ia3OA@mail.gmail.com>	<CA+s+GJBxEC2MifJQY5-vn2zSOHo-UOm8B1vYHHOfuxq26=VscQ@mail.gmail.com>	<CAADm4BDDJkS_xdjUn=2Yzs4B0RXTvpzpd5Z_kDRorzrn1HWSng@mail.gmail.com>	<CANEZrP1rPZYkTLmx5GOdj67oQAgFjeaF-LCKAXpg5XsEhXYFuQ@mail.gmail.com>	<CAADm4BB8y=k_f7CG3tyX6ruWF0w3+hU2Szv7ajLp1x7KhS56GA@mail.gmail.com>
	<CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
In-Reply-To: <CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="e5xqQTnI34g4V5lIfVSkMPbANEBg52bqO"
Subject: Re: [Bitcoin-development] Chain pruning
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--e5xqQTnI34g4V5lIfVSkMPbANEBg52bqO
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 10/04/14 18:59, Pieter Wuille wrote:
> It's important to
> note that this is a strict reduction in security: we're now trusting
> that the longest chain (with most proof of work) commits to a valid
> UTXO set (at some point in the past).

AFAIK, current bitcoin code code already set blockchain checkpoints from
time to time. It is a garanteed that a longer chain starting before the
checkpoint is not going to be accepted suddently. See
<https://bitcointalk.org/index.php?topic=3D194078.0>.

Could be perfectly valid to store only unspend wallets before last
checkpoint, if during the blockchain download the node did all the checks=
=2E

Would be interesting, of course, to be able to verify "unspend wallet
accounting" having only that checkpoint data (the merkle tree can do
that, I guess). So you could detect a data corruption or manipulation in
your local harddisk.

--=20
Jes=FAs Cea Avi=F3n                         _/_/      _/_/_/        _/_/_=
/
jcea@jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea@jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz


--e5xqQTnI34g4V5lIfVSkMPbANEBg52bqO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJTRw5mAAoJEGjgN61Khv5D8tsH/iXF38P3V4L9SlFI5UQhrKuS
B7AAA7klhXSRIlsMHU6+k1yhY/K7vVnjdp32l9bBOP3dclAHPo2dsS4Wg4jth8Yv
4o4naOrjmvXwofB84FlQWYGSNkMKcviJePMNLI+1wDAkyMjvC5yhGNUQTuHJ4PUY
ovSKCrSX7vwFsXpurNQLqC11SNpWD8iU0wj4Ht1/oG8fiGQ8UwvvOP4rrBuV9ud1
+5SnNi7pGLN/r8HUCI49qJFRfVD+epsOZrdxHK6NpDQbzpP+craDY0dxckSYNJKR
ISC8H6KORwancs6VxxCGrkzUHskOXKUS2XyMEDWpFfL7hdTCkq3xP7yySEm5X9w=
=e+RR
-----END PGP SIGNATURE-----

--e5xqQTnI34g4V5lIfVSkMPbANEBg52bqO--