1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mcqueenorama@gmail.com>) id 1RFRHk-0001V3-Gw
for Bitcoin-development@lists.sourceforge.net;
Sun, 16 Oct 2011 14:01:52 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=mcqueenorama@gmail.com;
helo=mail-iy0-f175.google.com;
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RFRHj-0004pg-LC
for Bitcoin-development@lists.sourceforge.net;
Sun, 16 Oct 2011 14:01:52 +0000
Received: by iafi7 with SMTP id i7so6430611iaf.34
for <Bitcoin-development@lists.sourceforge.net>;
Sun, 16 Oct 2011 07:01:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.141.69 with SMTP id n5mr30672550icu.47.1318773706182; Sun,
16 Oct 2011 07:01:46 -0700 (PDT)
Received: by 10.231.145.71 with HTTP; Sun, 16 Oct 2011 07:01:46 -0700 (PDT)
Date: Sun, 16 Oct 2011 07:01:46 -0700
Message-ID: <CAPfzCrT3J5RPiffzb5ruRy41kLbkQdRWdsr10oDyVxnKAf939g@mail.gmail.com>
From: Brian McQueen <mcqueenorama@gmail.com>
To: Bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mcqueenorama[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RFRHj-0004pg-LC
Subject: [Bitcoin-development] Cool New Bitcoin Proj
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 16 Oct 2011 14:01:52 -0000
Its cool, with both cryptography and bitcoin, its also an internet first.
Here's the idea: file's that go away and then come back later.
Realistically, the first version of this project needs to be files
that get encrypted, but can't be decrypted until a particular future
date - time-released cryptography.
Here's the simple demonstration of the concept, which is known to be
inadequate, but it demonstrates the time-released cryptography
concept. The true proposed solution is a P2P architecture shown
later, but first this simple model demonstrates the idea. Cryptoclock
provides a list of unique public keys on a calendar, one for each day
out into the future. Each day the hosting site releases the
associated private key for the current day, allowing all files
encrypted with the associated public key to be decrypted. In effect,
files would be popping open each day when the key of the day is
released. Maybe wikileaks documents pop open, or stashed bitcoin keys
so the stashed money can be retrieved.
Simple Public Cryptoclock Model:
1) Choose the public key for Jan 12, 2012
2) Encrypt your file with that public key
3) Erase your clear copy of file
At this point the file is locked up and nobody can get at it. If
people ask for the data, you can't get it. Ideally nobody can. Its
not available.
4) Wait until Jan, 12, 2012
5) Get the key of the day from the cryptoclock - maybe it goes out via twitter
6) Unlock your file - now you've got your data back
There are problems with this, that can be discussed separately, but
its known to be inadequate. At a minimum, its not cool that the
private key is delivered to the world, because the file should not pop
open to everybody who has a copy - just for the owner. Also, the
hosting site has a bad problem with securing the private keys, and
actually must be able to deny having them at all, in order to be free
of persecution and to be trusted. The keys must be gone - they must
be unavailable, not just on some USB stick in a box.
P2P Solution:
First stab at a general solution. This solves two problems, the
secret key will return automatically to the file owner, and the secret
key will truly be unavailable.
* Key Sharding
Assume P2P network of special cryptoclock nodes built on bitcoind, and
the transactions have to be of the contract variety, to eliminate the
risk of distributing the key. Shards will NOT be put on the block
chain but will be distributed via http. Shard holders will be
compensated for holding the shards when the key is rebuilt.
1) User1 has a file to hide. User1 puts it into node1 of the cryptoclock.
2) Node1 produces a public/private keypair (pb1, pv1)
3) Node1 encrypts the file with public key 1 (pb1) and wipes out the clear file
4) Node1 shards private key1 (pk1)
5) Node1 encrypts and distributes the shards to the P2P network as follows
5.1) Node1 sends a small bitcoin deposit txn to Node2 with a URL
message in the script and a random number (rn1)
5.2) Node2 issues a GET to the URL with the signed rn1 to node1
5.4) Node1 receives the GET and verifies the signature on rn1 and
returns the shard and a 200 to node2
This mechanism will distribute the private key in pieces to any number
of nodes, known only by their bitcoin addresses. Repeat this for each
shard of the private key. The number of shards and copies is
proportional to the security of the storage - the more you pay, the
more scattered is the key. There should be many shards, and each
shard should have many copies.
The transaction will have have to go from node1 to node2, triggering
the retrieval GET, and it must be done in a deposit style so if the
node is not available the bc will be returned as in the case of the
Deposit example on the Contracts wiki page.
* Rebuilding the key
A future-dated transaction needs to be created to get the keys to
return to the key creator on the target date, and they must be crafted
in such a way that the shard-holders are paid at the time the keyshard
is reclaimed, producing an incentive to stay online and keep the
keyshards in the network.
The general model (bitcoin txn and http request) will also make the
key return and reassemble itself in the owners cryptoclock client on
the future date, if the future transactions are triggered reliably. A
future transaction must be made right at the start, with a locktime
set to the target date. On the target date the shard holder's
client's transaction script is executed, which will trigger node2 to
take action on the initial deposit transaction. Node2 will have to
notify node1 that its ready for a GET, and node1 will issue a GET to
reclaim the keyshard. Another small deposit-style transaction to
node 1 will do this perfectly, in the same style as the first deposit
transaction.
* Cool Features
1) Participants are paid to participate and its a natural fit - its built-in.
2) The key returns automatically the file owner on the desired date
- it reassembles itself.
3) Pay more for more surety - more shards for more money.
* Peer Discovery
I think keys should be distributed to bitcoin addresses, which in
general are not available to the nodes, so peer discovery needs to be
fleshed out.
This needs to be fleshed out considerably. A peer discovery mechanism
must be produced. Bitcoin addresses could be pulled from the block
chain, or there can be an irc channel for address discovery, or users
could establish their own trusted network of associates.
* Block Chain Usage
This model uses bitcoin in a legitimate way, using real bitcoin
transactions and putting the bitcoin engine to work and leveraging its
financial engine to establish a reasonable expense/reward system. The
block chain has only one extra, short message for the initial
transaction. All application data is transacted outside the block
chain and stored outside the block chain.
|
