summaryrefslogtreecommitdiff
path: root/d1/69d353093027f1d522b779fb35bce4c81d5e2f
blob: 874ea5f7001948fb797696d14b966d40dc81d8c4 (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
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 <chuck+bitcoindev@borboggle.com>) id 1W8qLw-0006mc-03
	for bitcoin-development@lists.sourceforge.net;
	Thu, 30 Jan 2014 12:04:16 +0000
X-ACL-Warn: 
Received: from borboggle.com ([69.164.197.78] helo=mail.borboggle.com)
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1W8qLu-0000ct-5X for bitcoin-development@lists.sourceforge.net;
	Thu, 30 Jan 2014 12:04:15 +0000
Received: from [192.168.1.72] (unknown [180.183.159.154])
	by mail.borboggle.com (Postfix) with ESMTPSA id BDDA1FAA8;
	Thu, 30 Jan 2014 07:15:15 -0500 (EST)
Message-ID: <52EA3FAD.5080802@borboggle.com>
Date: Thu, 30 Jan 2014 19:03:57 +0700
From: Chuck <chuck+bitcoindev@borboggle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Pieter Wuille <pieter.wuille@gmail.com>, Mike Hearn <mike@plan99.net>
References: <52E9E787.8080304@borboggle.com>	<CANEZrP0soR0xRqW=vsKaL__HRuWstA5vW=6_JkGZm=8wkm8Q3g@mail.gmail.com>	<52EA343E.4010208@borboggle.com>	<CAPg+sBg8AGrbny=2tXp3gsok4TX7XV5307Cx1+ArBwxM6xL4jQ@mail.gmail.com>	<CANEZrP2MHqw+c+AVSLzmc6A1xyMvVK=DfR_R-tH1ypGQLRqo_A@mail.gmail.com>
	<CAPg+sBhzLVxdU+Kg2N7eW=34X1-6qbg1+rPzyMqfsy01zqnfGA@mail.gmail.com>
In-Reply-To: <CAPg+sBhzLVxdU+Kg2N7eW=34X1-6qbg1+rPzyMqfsy01zqnfGA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1W8qLu-0000ct-5X
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 message delivery reliability
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, 30 Jan 2014 12:04:16 -0000

On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn <mike@plan99.net> wrote:
>> With the way it works in bitcoinj, the tx is only committed to the wallet if
>> the server accepts the Payment message and ACKs it. So the tx would not be
>> retried if there's a failure submitting or some kind of internal server
>> error, and the UI would show that the payment failed. That seems
>> straightforward and how I'd expect things to work as a user.
> That's one right way to do it imho, but not what is suggested or
> required by the specification, and not what bitcoin core master
> currently implements.
>
If you sent the Payment message and the server goes silent after 
receiving it, you retry to delivery.  However, the merchant can 
broadcast the transactions and force them into your wallet anyway. You 
could, quite likely, pay and never get an ACK.