From: Mike Hearn <mike@plan99•net>
To: Andreas Schildbach <andreas@schildbach•de>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Sun, 1 Dec 2013 18:19:14 +0100 [thread overview]
Message-ID: <39921E12-B411-4430-9D56-04F53906B109@plan99.net> (raw)
In-Reply-To: <l7fpbn$hf6$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]
> 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?
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.
The UI for sending money should end up dead simple - no mention of fees anywhere, IMO.
The UI for receiving money could be a bit more complicated but even then - I think if ordinary people using smartphone wallets are having to think about how quickly they want their transaction to confirm and adjust fees, etc on the receiving side then we’re getting dangerously close to the usability failure zone.
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.
> 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.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4127 bytes --]
next prev parent reply other threads:[~2013-12-01 17:19 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 11:51 Mike Hearn
2013-12-01 12:15 ` Andreas Schildbach
2013-12-01 13:41 ` Mike Hearn
2013-12-01 16:50 ` Andreas Schildbach
2013-12-01 17:19 ` Mike Hearn [this message]
2013-12-01 17:40 ` Andreas Schildbach
2013-12-01 17:52 ` Mike Hearn
2013-12-01 18:12 ` Peter Todd
2013-12-01 18:18 ` Mike Hearn
2013-12-01 18:37 ` Peter Todd
2013-12-02 13:54 ` Patrick Mead
2013-12-02 14:33 ` Mike Hearn
2013-12-02 14:37 ` Jeff Garzik
2013-12-02 14:44 ` Mike Hearn
2013-12-02 14:47 ` Jeff Garzik
2013-12-03 1:40 ` Gavin Andresen
2013-12-03 10:06 ` Mike Hearn
2013-12-03 10:36 ` Drak
2013-12-03 10:45 ` Mike Hearn
2013-12-03 11:04 ` Drak
2013-12-03 11:07 ` Gavin Andresen
2013-12-03 11:29 ` Mike Hearn
2013-12-03 11:37 ` Peter Todd
2013-12-03 11:41 ` Gavin Andresen
2013-12-03 11:46 ` Mike Hearn
2013-12-03 11:54 ` Gavin Andresen
2013-12-03 12:05 ` Drak
2013-12-03 11:57 ` Taylor Gerring
2013-12-03 12:07 ` Peter Todd
2013-12-03 13:20 ` Jamie McNaught
2013-12-03 13:20 ` Mike Hearn
2013-12-03 13:48 ` Taylor Gerring
2013-12-03 13:54 ` Mike Hearn
2013-12-03 14:42 ` Quinn Harris
2013-12-04 1:45 ` Jeremy Spilman
2013-12-04 10:40 ` Mike Hearn
2013-12-04 10:57 ` Peter Todd
2013-12-04 11:09 ` Mike Hearn
2013-12-04 13:06 ` Peter Todd
2013-12-04 13:48 ` Mike Hearn
2013-12-04 21:51 ` Peter Todd
2013-12-03 11:03 ` Peter Todd
2013-12-03 11:09 ` Drak
2013-12-03 11:33 ` Peter Todd
2013-12-04 5:50 ` kjj
2013-12-03 11:31 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39921E12-B411-4430-9D56-04F53906B109@plan99.net \
--to=mike@plan99$(echo .)net \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox