path: root/e0/c056d358b80e4d415d6c18cbd821c87ac0046c

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <wendel@314t.com>) id 1VLrcq-0000Bk-UC
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Sep 2013 09:31:16 +0000
X-ACL-Warn: 
Received: from mail-we0-f177.google.com ([74.125.82.177])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VLrcm-0002ux-CB
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Sep 2013 09:31:16 +0000
Received: by mail-we0-f177.google.com with SMTP id t60so4626052wes.8
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 17 Sep 2013 02:31:05 -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=oBacK1z2P6dLa88KRaWCLdOcrj6YkMwlIat/CNtM7Lk=;
	b=YvtydBNQdOSDGtnVY9jN5cw6H01pSl1itRvRBMUnS8jgwDFcg6p7RTo1QxbZdIhf08
	3X0ayIx/zgE1ulc69Y3sCSwJRy7mYNte4A6Ok5gbkelEgVT3ZdteJX1j5WO3xyrUcDQF
	JgE9pAVDQV9vQpu1fuwHonsvJJ7ZUx6miNLPZQAAdITGdSBAlC9/aQPj32cLoIbzGmIO
	eUGPWXOep8PDtu/7F2WHGdgQvx0njXAXTv78GOA6WYXwyO6890yIUaA5lQPBIPqqdbfG
	5xpPXm8g7SddZs0zSBQTcFfhsEMOrwr0WDoVlR4e3MiH82ppLBNZROfr36I+XhnnCKBE
	Brqg==
X-Gm-Message-State: ALoCoQk0BQpOiHV27B0zjSeEKkiI3Vc/DS0gGBju3yKkN2MEQ4w/O8ymqz/jSsq9RrRjfDvPw6z1
X-Received: by 10.180.39.212 with SMTP id r20mr1628705wik.13.1379410265778;
	Tue, 17 Sep 2013 02:31:05 -0700 (PDT)
Received: from [127.0.0.1] ([46.19.143.203])
	by mx.google.com with ESMTPSA id hq13sm3030464wib.7.1969.12.31.16.00.00
	(version=TLSv1 cipher=RC4-SHA bits=128/128);
	Tue, 17 Sep 2013 02:31:04 -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: <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>
X-Mailer: Apple Mail (2.1283)
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
	[46.19.143.203 listed in dnsbl.sorbs.net]
X-Headers-End: 1VLrcm-0002ux-CB
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: Tue, 17 Sep 2013 09:31:17 -0000

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