Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VLZmA-0000P6-Ir for bitcoin-development@lists.sourceforge.net; Mon, 16 Sep 2013 14:27:42 +0000 X-ACL-Warn: Received: from mail-pd0-f181.google.com ([209.85.192.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VLZm8-00030t-OP for bitcoin-development@lists.sourceforge.net; Mon, 16 Sep 2013 14:27:42 +0000 Received: by mail-pd0-f181.google.com with SMTP id g10so4198987pdj.12 for ; Mon, 16 Sep 2013 07:27:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BuUjTWPLaIlYhwbROXdNg0ILPD32fxADeURKkev+GII=; b=EVZ/ZrFlXdqHQxNGgicee5RWQsZhJr7xheGGgrUkjXe1XMglasL9TrdJa1HWYM+oeo /TMqtEXXL3zs4oWkBLCJx1BDfGK7HPs02LBt8bb7ARpTTEL4wUzb10idl144wJPJ0Vj6 sX/6G7QtjLArV8C83NSgqL05WJASXV/C58cfe47PmGL2u0dp545hltjkNmEZLU5JEkxs YKBxcgT7Wcu0pjg5sqeyBIgJwMkOvriY+sZACIZV7VXW7lL8Z5VxxuSPePeaK20SX2jP sVym+JJ1U5U1jQKmNcB9bxxyip2g7d/UD3JC2SQzOg1z2H6AKYFqaH+jMMj2q/ShK5Nb CwVw== X-Gm-Message-State: ALoCoQnlviAw6hOPqhwrxQqQGY9xEsdeDSJRJ8OgAjKXnp7fWwu/gcPAUA9pO3ZuMwP5p8vjfBOd X-Received: by 10.68.168.99 with SMTP id zv3mr2967653pbb.144.1379340336123; Mon, 16 Sep 2013 07:05:36 -0700 (PDT) Received: from [127.0.0.1] (manning1.torservers.net. [96.44.189.100]) by mx.google.com with ESMTPSA id ye1sm38895581pab.19.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Sep 2013 07:05:35 -0700 (PDT) Sender: Wendell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Wendell In-Reply-To: Date: Mon, 16 Sep 2013 16:05:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82E79EB0-49D6-492A-AE4A-6A786C7B0AAA@grabhive.com> References: <9179D240-EE7E-41A4-AA59-7C96246D8CFB@grabhive.com> To: Eric Lombrozo X-Mailer: Apple Mail (2.1283) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.181 listed in list.dnswl.org] X-Headers-End: 1VLZm8-00030t-OP Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm)) 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: Mon, 16 Sep 2013 14:27:42 -0000 Luke pointed out that we should not be inserting extraneous data into = the blockchain, so this sounds like the best option, Eric.=20 I'm under the impression that a Bitcoin user Alice cannot see the actual = public key of Bitcoin user Bob, so if we had Hive store metadata on a = server relating to a given transaction ID, I would not be able to use = those public keys key to encrypt. Is this a misunderstanding or is it = correct? Assuming it is correct, the best that I could come up with was storing = the transaction ID with a _fresh_ public key on a server, each time a = transfer is made. Altogether it looks like this: - Alice generates a new keypair & revocation certificate for the = transaction - Alice makes a Bitcoin transaction to Bob - Alice sends the transaction ID plus the new public key to server - Bob receives the Bitcoin transaction - Bob generates a new keypair & revocation certificate - Bob does a transaction ID lookup on the server, receives Alice's = public key, sends his own new one - Bob encrypts his user metadata against Alice's new key - Alice downloads and decrypts Bob's metadata - Alice uploads her revocation certificate - Alice uploads her own metadata - Bob downloads Alice's metadata - Bob uploads his revocation certificate - (Server removes all keys with revocation certificates) I presume going the extra mile to generate new keys for each transaction = is helpful for privacy? The above seems rather inelegant to me. I really don't like that clients = (wallets) are going to be beating down the server all the time checking = for keys, or that there is a possibility of a desynchronization so = severe that the user receives the data much too late for it to be = useful. But, I suppose it can work. Another thing I'm considering is Alice/Bob validating each other. I = suppose we should include some kind of code that we encourage people to = read to each other over the phone or some other medium, to ensure that = "it really is Alice", before (for example) returning money to a very = legit-looking personage. Any other thoughts? I would love to do this without using any servers at = all ("serverless keyserver", anyone?), but I am not quite sure how. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 7, 2013, at 12:47 AM, Eric Lombrozo wrote: > Why not just use the transaction hash itself for the lookup? Also, = presumably you'd want to encrypt the data so that only the recipient of = the transaction can do this lookup. >=20 > -Eric >=20 > On Sep 6, 2013, at 8:07 AM, Wendell wrote: >=20 >> Hi all, >>=20 >> We're thinking about ways of automatically exchanging contact details = between wallets, in order to encourage the proliferation of identifiable = names and photos rather than long and hard-to-verify addresses. >>=20 >> The simplest version goes like this: >>=20 >> 2 BTC Bitcoin is sent to someone, and a data lookup hash is inserted = into the transaction. When it arrives on the other end, it is indeed = looked up, and instead of being presented with a dialogue that says "you = received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You = received 2 BTC from Frank Jones" including a nice photo. >>=20 >> Now. We can simply delete this data in reference to the transaction = ID after it happens (or delete it after a time), but is there any more = decentralized way to do it? I would prefer us to run no dedicated = servers that would ever put us in a position of being coerced into = giving data, or otherwise altering our system to store it. >>=20 >> Any thoughts about this? >>=20 >> -wendell >>=20 >> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 >>=20 >> = --------------------------------------------------------------------------= ---- >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, = more! >> Discover the easy way to master current and previous Microsoft = technologies >> and advance your career. Get an incredible 1,500+ hours of = step-by-step >> tutorial videos with LearnDevNow. Subscribe today and save! >> = http://pubads.g.doubleclick.net/gampad/clk?id=3D58041391&iu=3D/4140/ostg.c= lktrk_______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20