From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Brian McQueen 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.