public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Proof-of-storage txouts
Date: Wed, 27 Nov 2013 10:24:58 -0500	[thread overview]
Message-ID: <20131127152458.GA10884@petertodd.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

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=HMAC(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=348868.new#new

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

                 reply	other threads:[~2013-11-27 15:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131127152458.GA10884@petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox