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>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Simple contacts exchange (was: Social
	network integration (brainstorm))
Precedence: list

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