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; 
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
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>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

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