From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJeyD-00069B-EO for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 09:13:01 +0000 X-ACL-Warn: Received: from mail-pa0-f47.google.com ([209.85.220.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJeyC-0004SC-AX for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 09:13:01 +0000 Received: by mail-pa0-f47.google.com with SMTP id lj1so16054929pab.6 for ; Fri, 06 Feb 2015 01:12:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Y3Z6Z9tF2wC1sSnWmVx7FTPrcSRsRfLyOEi1YKR9OuY=; b=lUm17Lx90qclD5T/+VCqSkMwSPyOVvdbahak2ADeB7a03PlQAgO9l/t617XVtuBUPc oUsZEyZP9Xlwj9RggXD6t/vvCOhHnBK+bwO2TMZJASMh4QNdJOjokTob2m0PRABMPO4U iWAxOtICch5gSA57bAASeYKNfHwgnKkqfz/ecWx2QjNMjRZmSO4SaN9JiPHtRAIq7tQu qwK9VPP7GJXeDmARjiUvTI8aD++8GdNFTCRoe5V2ImuMSp0Z3PVRacZ/3poHZp9Ih3PW 2ol4AUMukBWcW5qgtZ7RpEf/lmM1bQlOK97HuyIN4Wa4QnMUmpy4iau37X3Rm/hBVotw zvqg== X-Gm-Message-State: ALoCoQl6cWNLO0nFLoqQxQEdQZlA3Fz9s+WwFhI8bnTPBQxwsUFwi636dIR28I3y0WDvO/CS3Rsh X-Received: by 10.68.132.198 with SMTP id ow6mr4235853pbb.61.1423213974630; Fri, 06 Feb 2015 01:12:54 -0800 (PST) Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net. [50.135.46.157]) by mx.google.com with ESMTPSA id ms9sm7405473pdb.41.2015.02.06.01.12.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 01:12:53 -0800 (PST) Message-ID: <54D485A6.4010708@voskuil.org> Date: Fri, 06 Feb 2015 01:13:10 -0800 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Roy Badami References: <54D3D636.1030308@voskuil.org> <279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com> <6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org> <20150205233421.GP39876@giles.gnomon.org.uk> <54D403E5.5090606@voskuil.org> <20150206085922.GQ39876@giles.gnomon.org.uk> In-Reply-To: <20150206085922.GQ39876@giles.gnomon.org.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JvTEgaNTFb4BpbNNSwll8IinDIb9fDoaD" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YJeyC-0004SC-AX Cc: Bitcoin Dev , Paul Puey Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI 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: Fri, 06 Feb 2015 09:13:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JvTEgaNTFb4BpbNNSwll8IinDIb9fDoaD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/06/2015 12:59 AM, Roy Badami wrote: >> In this case there is no need for P2P communication, just pay to an >> address you already have for the other party. If you want to avoid >> address reuse, use stealth addressing. >> >> But yes, if you don't have a stealth address for the other party you c= an >> certainly communicate in private as peers where you trust that you sha= re >> a public key. The core issue here is really bootstrapping of that trus= t >> in an ad hoc manner. >=20 > Something interactive might still be nicer, though, to avoid the risk > of paying to an address that the payee no longer has the private key > for. "Nooo!! Don't pay to that address. I lost my old phone so I > generated a new wallet." Certainly, which brings us back to proximity. Which reminds me - it's important to keep in mind the scenario that arises when there is no person present to represent the receiver. Such as a vending machine purchase. Proximity in these cases is insufficient, as the receiver is not able to prevent application of a fraudulent NFC device or replacement of a static QR code. In these cases BIP-70 becomes essential. e --JvTEgaNTFb4BpbNNSwll8IinDIb9fDoaD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU1IWmAAoJEDzYwH8LXOFOe8AH/RMjJY8f1NTgW3IZklUIAGXP B5VkmCkGqkT9y5L0CTDBw+HctaZT3w5QRcz6Qi8bfCVpcV/KFRHL7UrGGb6kJumV 5Y3UwbJAYDBlV/WOJzNgqzCcbqaMjXat1ar3U4Xk7NmzpIMz+4Q6omwGoYMnYaRi /qPLVFBaF5XBE4OlEf5StbIluk7x1j0nGEKh/G4aPAsjQcFcR6logkd1Gw11q73K IA+pArwNGJkcKBBWom0NkZzZqpfVZOTkEchECy/q4K+JSJewnlBCeWWaFqg/VXcL Fci37muLc9fZ/8O8xpS/EfLl7rfE251RwVAPwSu7CNYL8Mjd9JTjKM2+9zNB2lY= =5ih2 -----END PGP SIGNATURE----- --JvTEgaNTFb4BpbNNSwll8IinDIb9fDoaD--