summaryrefslogtreecommitdiff
path: root/a9/f96f87b0c7366b6ba67ad1e0739d0eb8e94d30
blob: 065d1582bdc5d0f41ea1b4794d36ce88646a57e7 (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
86
87
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1Te7wi-0007wR-Ry
	for bitcoin-development@lists.sourceforge.net;
	Thu, 29 Nov 2012 17:30:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f47.google.com; 
Received: from mail-la0-f47.google.com ([209.85.215.47])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Te7we-0001Zw-IR
	for bitcoin-development@lists.sourceforge.net;
	Thu, 29 Nov 2012 17:30:44 +0000
Received: by mail-la0-f47.google.com with SMTP id u2so11832239lag.34
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 29 Nov 2012 09:30:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.123.103 with SMTP id lz7mr22215679lab.21.1354210233860;
	Thu, 29 Nov 2012 09:30:33 -0800 (PST)
Received: by 10.112.40.73 with HTTP; Thu, 29 Nov 2012 09:30:33 -0800 (PST)
In-Reply-To: <20121129170713.GD6368@giles.gnomon.org.uk>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<20121128233619.GA6368@giles.gnomon.org.uk>
	<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
	<20121129170713.GD6368@giles.gnomon.org.uk>
Date: Thu, 29 Nov 2012 12:30:33 -0500
Message-ID: <CABsx9T1-UvsVAS2ravR10XSqyNkQDf3R1a6Woj-4Jc_9Wpv3_g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Roy Badami <roy@gnomon.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Te7we-0001Zw-IR
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
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: Thu, 29 Nov 2012 17:30:45 -0000

On Thu, Nov 29, 2012 at 12:07 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> I'd still like to understand the rationale for having the merchant
> broadcast the transaction - it seems to add complexity and create edge
> cases.

Mike Hearn has experimented with in-person payments using
bluetooth/NFC on a phone, where the merchant has full Internet
connectivity but the phone might only be able to connect to the
merchant via a Bluetooth/NFC paymentURI.

I think I agree with you, though: if the device DOES have
bitcoin-p2p-network-connectivity, then expecting the client to
broadcast the transaction might be cleaner.

However, if a connection to the paymentURI is made and the transaction
data has been sent, clients have to deal with the case where the
merchant also broadcasts the transaction, no matter what the spec says
and even if the merchant sends an "accepted : false" response.


-- 
--
Gavin Andresen