summaryrefslogtreecommitdiff
path: root/60/65dac416c1f861a72de88bd3fd9f4bdf124d9f
blob: 55fc2ccbf5a77f13b8b8b6e1aeeaebd356c8f2ba (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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1VnB18-0003lI-Pc for bitcoin-development@lists.sourceforge.net;
	Sun, 01 Dec 2013 17:41:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
Received: from plane.gmane.org ([80.91.229.3])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1VnB17-0007TY-BC
	for bitcoin-development@lists.sourceforge.net;
	Sun, 01 Dec 2013 17:41:14 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1VnB10-0000dC-Cl for bitcoin-development@lists.sourceforge.net;
	Sun, 01 Dec 2013 18:41:06 +0100
Received: from e179039132.adsl.alicedsl.de ([85.179.39.132])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
	Sun, 01 Dec 2013 18:41:06 +0100
Received: from andreas by e179039132.adsl.alicedsl.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 01 Dec 2013 18:41:06 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Sun, 01 Dec 2013 18:40:55 +0100
Message-ID: <l7fsat$hf3$1@ger.gmane.org>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>	<l7f97u$jdg$1@ger.gmane.org>	<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>	<l7fpbn$hf6$1@ger.gmane.org>
	<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: e179039132.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.1.1
In-Reply-To: <39921E12-B411-4430-9D56-04F53906B109@plan99.net>
X-Spam-Score: -0.4 (/)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [80.91.229.3 listed in list.dnswl.org]
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	1.1 DKIM_ADSP_ALL          No valid author signature,
	domain signs all mail
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1VnB17-0007TY-BC
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
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: Sun, 01 Dec 2013 17:41:14 -0000

On 12/01/2013 06:19 PM, Mike Hearn wrote:
>> Both can be combined into adapting the current generic messages ("This
>> payment should become spendable shortly" for incoming and "This payment
>> has not been transmitted yet" for outgoing transactions).
>
> What would the new messages say?

Well, for starters I'd suggest something like

"This payment did not become spendable since xxx minutes. Check with the
sender if s/he paid the Bitcoin network fee. Check if your internet
connection is working properly." (incoming)

"This payment still has not been transmitted. Check if your internet
connection is working properly." (outgoing)

> We need to get away from the notion of senders attaching fees anyway.
This is the wrong way around because it’s the recipient who cares about
double spending risk, not the sender. That’s why merchants keep running
into issues with people attaching zero fees. Of course they attach zero
fees. They know they aren’t going to double spend. It’s the merchant who
cares about getting the security against that.

Guess you're right. But as you said, we're not there yet.

> The UI for sending money should end up dead simple - no mention of
fees anywhere, IMO.

Agreed, if the sender does not need to pay a fee any more. On the
receiving side it of course needs to be mentioned. (Or the other way
round, as of today.)

> Unfortunately we lack the protocol pieces to get the right UI here :(
Someone needs to sit down and figure out what the UI *should* look like,
in the ideal world, and then work backwards to figure out what needs to
be done to get us there.

(The ideal world doesn't need a UI for money.)

>> For outgoing transactions, if it is very clear that they're never going
>> to be confirmed, I'd like to see a "Revoke" button.
>
> Disagree. There should never be any cases in which a transaction
doesn’t confirm. Period. I know there have been bugs with bitcoinj that
could cause this in the past, but they were bugs and they got fixed/will
get fixed.
>
> Settlement failure is just unacceptable and building a UI around the
possibility will just encourage people to think of it as normal, when it
should not be so.

I fully understand your point of view. However, its not the reality
currently. (Hopefully it is, after the fixes to bitcoinj.)