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 ) 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 ; 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 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Wendell 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> <82E79EB0-49D6-492A-AE4A-6A786C7B0AAA@grabhive.com> To: Eric Lombrozo 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 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: 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 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