path: root/81/c73ea7112578e9aab73088ac7f34e7b5e8cd46

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 <wendel@314t.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <wendel@314t.com>
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Wendell <w@grabhive.com>
In-Reply-To: <AFD93558-684C-497C-ADAF-D031095EC2CE@gmail.com>
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>
	<AFD93558-684C-497C-ADAF-D031095EC2CE@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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 <w@grabhive.com> 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