summaryrefslogtreecommitdiff
path: root/9f/33880b9d24bfbc273e3d67962c83e40d42c9de
blob: 0839b64fd74d4eac47d7e35d1d98ece5eae703ba (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <roy@gnomon.org.uk>) id 1YJelP-0006pr-A5
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Feb 2015 08:59:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gnomon.org.uk
	designates 93.93.131.22 as permitted sender)
	client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
	helo=darla.gnomon.org.uk; 
Received: from darla.gnomon.org.uk ([93.93.131.22])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YJelN-0001xn-D8
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Feb 2015 08:59:47 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
	by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t168xQqN023247
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Feb 2015 08:59:31 GMT (envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
	by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t168xNPB023246;
	Fri, 6 Feb 2015 08:59:23 GMT (envelope-from roy)
Date: Fri, 6 Feb 2015 08:59:23 +0000
From: Roy Badami <roy@gnomon.org.uk>
To: Eric Voskuil <eric@voskuil.org>
Message-ID: <20150206085922.GQ39876@giles.gnomon.org.uk>
References: <54D3D636.1030308@voskuil.org>
	<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>
	<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>
	<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>
	<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>
	<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>
	<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
	<CABjHNoTmj=wfjRwApZCJJTDhhwePh=VtXkJN0e3t1uQqmeMu6Q@mail.gmail.com>
	<20150205233421.GP39876@giles.gnomon.org.uk>
	<54D403E5.5090606@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54D403E5.5090606@voskuil.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1YJelN-0001xn-D8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Paul Puey <paul@airbitz.co>
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: <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: Fri, 06 Feb 2015 08:59:47 -0000

> 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 can
> certainly communicate in private as peers where you trust that you share
> a public key. The core issue here is really bootstrapping of that trust
> in an ad hoc manner.

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."

roy