[Bitcoin-development] Fees UI warning

[Bitcoin-development] Fees UI warning

[Drak]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Not sure if this is the right place, but since a few wallet authors
congregate here I though it might be the best place.

It seems every once in a while you see stories of people accidentally
paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
0.05 BTC transaction[1], oops. There was another recently where someone
paid a fee of about 200BTC which fortunately the pool operator refunded.

It just occurs to me this kind of sad story could be averted if wallets
implemented a confirmation box if the fee amount seems crazy - for example,
if it's >10x what the default fee should be, or if it's greater than x% of
the sending amount. "the fee seems unusually high, are you really sure you
want to pay X in fees?"

I realise the exact details of this might need to be fleshed out given we
want flexible fees, but it should be pretty simple to agree with what looks
like an unusually large fee according to the going rate.

Drak

[1]
http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/

[-- Attachment #2: Type: text/html, Size: 1328 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Jim]

Yes I saw that on reddit too.

I think it applies mainly to custom transactions rather
than where fees are calculated automatically.

Another variant of not understanding change that loses
people's bitcoins I have encountered is:
1) Import a private key of a brainwallet/ paper wallet.
2) Send a small amount of bitcoin from that key.
3) The user then secure deletes all copies of the wallet
'for security'. If they are not careful they can delete
a change address with funds on it.

In MultiBit I have tried to reduce this possibility by:
1) Hiding the ability to delete wallet (in the next version
I am removing it entirely)
2) There is always a single key in a new wallet. When
a user imports a key then that makes two. I always send
the change to the second address, if it is available.
(This is bad for privacy but at least lessens the chances
that the funds become lost). 

If users are determined to use a brain wallet and 
secure delete every copy of the wallet after they use
them you cannot stop them (it is their machine after all)
But these two options help lessen the chance of bitcoin
loss if they do.

For the HD version of MultiBit we are removing the import
of individual private keys entirely and only supporting HD
addresses, primarily for safety reasons.

Jim

On Mon, Dec 16, 2013, at 10:13 AM, Drak wrote:
> Not sure if this is the right place, but since a few wallet authors
> congregate here I though it might be the best place.
> 
> It seems every once in a while you see stories of people accidentally
> paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
> 0.05 BTC transaction[1], oops. There was another recently where someone
> paid a fee of about 200BTC which fortunately the pool operator refunded.
> 
> It just occurs to me this kind of sad story could be averted if wallets
> implemented a confirmation box if the fee amount seems crazy - for example,
> if it's >10x what the default fee should be, or if it's greater than x% of
> the sending amount. "the fee seems unusually high, are you really sure you
> want to pay X in fees?"
> 
> I realise the exact details of this might need to be fleshed out given we
> want flexible fees, but it should be pretty simple to agree with what looks
> like an unusually large fee according to the going rate.
> 
> Drak
> 
> [1]
> http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
http://bitcoin-solutions.co.uk

Re: [Bitcoin-development] Fees UI warning

[Drak]

[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]

Jim,

It's great to see the many ways wallet authors try to protect users from
easy to make mistakes, especially against losing funds.

But this issues isn't confined to custom transaction - some wallet
implementations have a fee field and almost all wallets allow the fee rate
to be configured in preferences. Sanity checking is sensible where a user
can override the calculated fee. Some wallets don't allow the fee to be
adjusted at all, but quite a few do.

Drak


On 16 December 2013 10:46, Jim <jim618@fastmail.co.uk> wrote:

> Yes I saw that on reddit too.
>
> I think it applies mainly to custom transactions rather
> than where fees are calculated automatically.
>
> Another variant of not understanding change that loses
> people's bitcoins I have encountered is:
> 1) Import a private key of a brainwallet/ paper wallet.
> 2) Send a small amount of bitcoin from that key.
> 3) The user then secure deletes all copies of the wallet
> 'for security'. If they are not careful they can delete
> a change address with funds on it.
>
> In MultiBit I have tried to reduce this possibility by:
> 1) Hiding the ability to delete wallet (in the next version
> I am removing it entirely)
> 2) There is always a single key in a new wallet. When
> a user imports a key then that makes two. I always send
> the change to the second address, if it is available.
> (This is bad for privacy but at least lessens the chances
> that the funds become lost).
>
> If users are determined to use a brain wallet and
> secure delete every copy of the wallet after they use
> them you cannot stop them (it is their machine after all)
> But these two options help lessen the chance of bitcoin
> loss if they do.
>
> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.
>
> Jim
>
> On Mon, Dec 16, 2013, at 10:13 AM, Drak wrote:
> > Not sure if this is the right place, but since a few wallet authors
> > congregate here I though it might be the best place.
> >
> > It seems every once in a while you see stories of people accidentally
> > paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
> > 0.05 BTC transaction[1], oops. There was another recently where someone
> > paid a fee of about 200BTC which fortunately the pool operator refunded.
> >
> > It just occurs to me this kind of sad story could be averted if wallets
> > implemented a confirmation box if the fee amount seems crazy - for
> example,
> > if it's >10x what the default fee should be, or if it's greater than x%
> of
> > the sending amount. "the fee seems unusually high, are you really sure
> you
> > want to pay X in fees?"
> >
> > I realise the exact details of this might need to be fleshed out given we
> > want flexible fees, but it should be pretty simple to agree with what
> looks
> > like an unusually large fee according to the going rate.
> >
> > Drak
> >
> > [1]
> >
> http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> http://bitcoin-solutions.co.uk
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 6071 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Mon, Dec 16, 2013 at 11:13 AM, Drak <drak@zikula.org> wrote:

> It just occurs to me this kind of sad story could be averted if wallets
> implemented a confirmation box if the fee amount seems crazy - for example,
> if it's >10x what the default fee should be, or if it's greater than x% of
> the sending amount. "the fee seems unusually high, are you really sure you
> want to pay X in fees?"
>

Bitcoin-qt (in master) always shows the fee and total amount that is going
to be paid in the confirmation dialog, so it is very hard to accidentally a
very high fee.

Wladimir

[-- Attachment #2: Type: text/html, Size: 969 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Pieter Wuille]

On Mon, Dec 16, 2013 at 11:46 AM, Jim <jim618@fastmail.co.uk> wrote:
> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.

Will that also mean no longer reusing (change) addresses?

-- 
Pieter

Re: [Bitcoin-development] Fees UI warning

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Mon, Dec 16, 2013 at 11:46 AM, Jim <jim618@fastmail.co.uk> wrote:

> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.
>

I'd love to have the same in Bitcoin-Qt as well. Too many sob stories about
people with outdated backups that lost part or all of their coins. These
are much more common than fee messups.

What we should really do is:

- Use deterministic wallets. Making regular backups becomes optional (to
retain label and transaction data and such) instead of mandatory.

- Don't support importing private keys. Replace the importing of private
keys by a "sweep" function.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Taylor Gerring]

[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]

Providing people with a great user experience is something that Hive Wallet is enthusiastic about, so this is stuff we’re thinking about constantly. For example, how do you alert the user to abnormal activity (i.e. sending “too much” on accident[1])? The removal of extraneous UI and functionality that can be automated is a priority, which is why we (to date) still don’t have a Preferences dialog. Smart defaults should be an important aspect of design decisions.

Thinking about stripping UI away as much as possible, consider what was done with dat.wallet[2]: no wallet file whatsoever and it doesn't even reveal the address except when explicitly necessary. For privacy’s sake, the intent should be to detect the use of an address and automatically rotate it away from the user. This minimal interaction results in maximum benefit.

Or take a look at the new Bitstamp app I’m writing for Hive[3]. How do you cram an entire trading API into a mobile-like window? Smart use of space and making intelligent event-driven decisions is often overlooked. In the linked screenshot, imagine the user actually clicks the deposit button. A “send bitcoins" dialog is pre-populated with the deposit address and the requested amount. Copying and pasting addresses is error-prone and not user-friendly in the least.

I would urge all software developers to think about UX when developing applications. What can be automated? What can we make a best guess about? In the case of fees, we will hopefully have more control over them in the coming months, but in the meantime, consider what your application tries to accomplish and how it can do that without getting in the way too much. Software should enable the user, not encumber them.

Lastly, I’ll leave everyone with an approach we’re considering once floating fees are feasible[4], something Mike Hearn asked about in a previous thread.

[1] https://github.com/hivewallet/hive-osx/issues/107
[2] https://github.com/darkwallet/dat.wallet
[3] https://github.com/tgerring/hiveapp-bitstamptrader
[4] https://github.com/hivewallet/hive-osx/issues/148


Taylor


On Dec 16, 2013, at 5:37 AM, Wladimir <laanwj@gmail.com> wrote:

> On Mon, Dec 16, 2013 at 11:46 AM, Jim <jim618@fastmail.co.uk> wrote:
> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.
> 
> I'd love to have the same in Bitcoin-Qt as well. Too many sob stories about people with outdated backups that lost part or all of their coins. These are much more common than fee messups.
> 
> What we should really do is:
> 
> - Use deterministic wallets. Making regular backups becomes optional (to retain label and transaction data and such) instead of mandatory.
> 
> - Don't support importing private keys. Replace the importing of private keys by a "sweep" function.
> 
> Wladimir
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 4961 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Mon, Dec 16, 2013 at 12:31 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:

> Will that also mean no longer reusing (change) addresses?
>

Jim seems to be planning some parallel development to what I'm doing, but
HD wallets and stopping address re-use is the current feature I'm working
on for bitcoinj. Only code review and merging takes higher priority at the
moment. So I think we might be able to stop re-using addresses at least on
devices with sufficient memory some time in Q1

[-- Attachment #2: Type: text/html, Size: 878 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Mon, Dec 16, 2013 at 11:13 AM, Drak <drak@zikula.org> wrote:

> It just occurs to me this kind of sad story could be averted if wallets
> implemented a confirmation box if the fee amount seems crazy - for example,
> if it's >10x what the default fee should be, or if it's greater than x% of
> the sending amount.
>

Most good wallets have UI's designed to be safe. Unfortunately this guy was
using brainwallet.org which is by no means a "good" wallet in that sense
(it's not really even a wallet app at all)

I think most of us have expressed displeasure at the existence of this site
before, and I once even asked the guy to stop running it, but he refused.
It's an extremely sharp tool which makes it easy to cut yourself, except it
doesn't look dangerous, it looks like ordinary software designed for
ordinary people.

I don't know how to solve this. Badly designed software that looks
appealing will always be a danger.

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

Re: [Bitcoin-development] Fees UI warning

[Gregory Maxwell]

On Mon, Dec 16, 2013 at 3:37 AM, Wladimir <laanwj@gmail.com> wrote:
> What we should really do is:
> - Use deterministic wallets. Making regular backups becomes optional (to
> retain label and transaction data and such) instead of mandatory.
> - Don't support importing private keys. Replace the importing of private
> keys by a "sweep" function.

I'd add a third: make structured key-management possible, e.g.

At a minimum:  Users should be able to hit a "retire keys / keys
possibly compromised" button, which creates a new seed, forces the
user to make a backup (and allows more than one), then switches to the
new seed and moves all their coins.

On Mon, Dec 16, 2013 at 10:28 AM, Mike Hearn <mike@plan99.net> wrote:
> I don't know how to solve this. Badly designed software that looks appealing
> will always be a danger.

"We didn't say it couldn't be done—  We said don't do it!"

Part of the challenge here is that the service does a number of things
people _really_ shouldn't be doing— things so dangerous that I
certainly won't do them— and as a result to not use the site turn into
big education efforts rather than just "use this other thing (that
also does the wrong headed thing you want to do)".

Re: [Bitcoin-development] Fees UI warning

[Andreas Schildbach]

On 12/16/2013 07:28 PM, Mike Hearn wrote:

> I don't know how to solve this. Badly designed software that looks
> appealing will always be a danger.

One way would be to explicitly warn against some services. For example,
on the "Choose you wallet" page of bitcoin.org.