Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VlgzJ-0002qf-3m for bitcoin-development@lists.sourceforge.net; Wed, 27 Nov 2013 15:25:13 +0000 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; Received: from outmail149056.authsmtp.com ([62.13.149.56]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VlgzH-0003hS-AR for bitcoin-development@lists.sourceforge.net; Wed, 27 Nov 2013 15:25:13 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt10.authsmtp.com (8.14.2/8.14.2) with ESMTP id rARFP5Pd011988 for ; Wed, 27 Nov 2013 15:25:05 GMT Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rARFOxVr072786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 27 Nov 2013 15:25:01 GMT Date: Wed, 27 Nov 2013 10:24:58 -0500 From: Peter Todd To: Bitcoin Development 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) X-Server-Quench: 156ba09d-5778-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQJ1 LhcPXVBSFQZ4ABkL BBsUUhg8dgJCZn9y bFhgVm5ZWE1lcE56 XU8aVxxkExgoDiIf V0JffwUadgFKelFE b1YtBXMENXgCYX1o WlZqMmt0N2UHcmEN GltQfAobGBsHF2Eq fwoFGjtqGkNAXDk0 NRUpJxYADEEMLl5a X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VlgzH-0003hS-AR Subject: [Bitcoin-development] Proof-of-storage txouts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 15:25:13 -0000 --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 { 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--