Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.56 as permitted sender)
	client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
	helo=outmail149056.authsmtp.com; 
Date: Wed, 27 Nov 2013 10:24:58 -0500
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Message-ID: <20131127152458.GA10884@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Bitcoin-development] Proof-of-storage txouts
Precedence: list


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

So Sarchar and I were talking about his Bitstorage scheme(1) and we came
to the conclusion that it wouldn't work. However he came up with a less
abitious idea that I thought would work: force people to prove they were
still holding your data D by publishing transactions with scriptPubKeys
of the form:

    HASH160 H(D[i:i+n]) EQUALVERIFY {<pubkey> OP_CHECKSIG}

Where pubkey optionally lets you pick a specific person to hold your
data. (so the scheme isn't restricted to miners - hash-only
scriptPubKeys aren't secure) Basically you'd publish the data and store
a much smaller random set of D[] samples. If you ever needed the data in
full, you know it's out there, so it's just a matter of haggling on the
price to get it back. (you may want to do some dry-runs for negotiation
leverage...)

However, I realized you can improve upon this greatly by deriving the
ECC privkeys from the random samples of data instead using H(E_k(D)),
that is, use a block cipher with key k, and then hash that to form the
privkey. Then create a perfectly normal txout paying to the appropriate
pubkey. Now only people who actually have the data can claim the txout,
and everyone doesn't even know the scheme exists at all.

Furthermore you can create key k using k_i=3DHMAC(i, K), where i in [0,
n], so rewards for the proof can be released incrementally while only
storing a single secret key. Again, actual retrivial isn't necessarily
guaranteed, but the odd dry-run is simple enough.

One last issue is how to distribute k_i, although this is made easier by
the fact that they can be tiny 128-bit numbers - they should however be
signed to avoid DoS attacks as only by processing all the data can the
storage node know if k_i works for the given txout.


1) https://bitcointalk.org/index.php?topic=3D348868.new#new

--=20
'peter'[:-1]@petertodd.org
00000000000000056738baba2d1f0fb2638555529e0735e41e1ce9e0c946d48a

--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJSlg7KAAoJEBmcgzuo5/CFhyEH/jxo9D8urxQT8f0BlIb5qAYJ
Or0G/zFtzA7h2VNVDLnO4JxeAm3j6PGpBQVbbM8yLh4VpRNrgmbgge9go/O94HZg
qfXYX8v8eVPXrFDBryCuL0t4TvPaUTW8bDCvnaYE21JxJFVu6Gd++Enfvpm0cXnI
F7Z5w3ll1KMo0IqDsAJeR1DZ//OUf0J1IxbIVHaE52sUzOF0B9QIRoojF+w7s0JW
JBexMi+vJfOrIp4wN2AUWltx3qhHj8nphTeY4feosXisVHuqISb50er9W1o3ie/w
aE0guZuni/BzumRspjqdeYE00hrD6LzmiWqZcxJHwBWJFfFNc3BOtjM4MDTtCms=
=VBs2
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--