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: <82E79EB0-49D6-492A-AE4A-6A786C7B0AAA@grabhive.com>
Date: Tue, 17 Sep 2013 11:30:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B80F433-9039-459B-BC96-A56786DEF6C3@grabhive.com>
References: <9179D240-EE7E-41A4-AA59-7C96246D8CFB@grabhive.com>
	<AFD93558-684C-497C-ADAF-D031095EC2CE@gmail.com>
	<82E79EB0-49D6-492A-AE4A-6A786C7B0AAA@grabhive.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

Couple of things I just thought about:

1- Presume server should only sweep with two (or more, see below) =
revocation certificates being present
2- Need to insert something in the flow so that Alice can verify that =
the uploaded key is actually Bob's (and perhaps vise-versa, given an =
extremely dedicated attacker with a fast connection?).

Is there a way to do #2 without creating yet another transaction? =
Admittedly I am still really puzzled about the accessibility of public =
keys in Bitcoin!

Please remember that the idea is to have two wallets securely exchange a =
packet of metadata about a transaction beyond the scope of Bitcoin =
itself (a name, perhaps a small photo, etc) in order to increase =
usability. This will be my last post here on the topic except to reply =
in case anyone else contributes.

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Sep 16, 2013, at 4:05 PM, Wendell wrote:

> Luke pointed out that we should not be inserting extraneous data into =
the blockchain, so this sounds like the best option, Eric.=20
>=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?
>=20
> 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:
>=20
> - 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)
>=20
> I presume going the extra mile to generate new keys for each =
transaction is helpful for privacy?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> -wendell
>=20
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>=20
> On Sep 7, 2013, at 12:47 AM, Eric Lombrozo wrote:
>=20
>> 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