From: Drak <drak@zikula•org>
To: Jim <jim618@fastmail•co.uk>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Fees UI warning
Date: Mon, 16 Dec 2013 11:08:56 +0000 [thread overview]
Message-ID: <CANAnSg1oWrjod8N-iQg5fTzyhXWxMfSSdcnvhtjWEWcWW7_LOg@mail.gmail.com> (raw)
In-Reply-To: <1387190808.12225.60115997.547B23B6@webmail.messagingengine.com>
[-- 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 --]
next prev parent reply other threads:[~2013-12-16 11:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 10:13 Drak
2013-12-16 10:46 ` Jim
2013-12-16 11:08 ` Drak [this message]
2013-12-16 11:31 ` Pieter Wuille
2013-12-16 18:26 ` Mike Hearn
2013-12-16 11:37 ` Wladimir
2013-12-16 17:55 ` Taylor Gerring
2013-12-16 18:45 ` Gregory Maxwell
2013-12-16 11:27 ` Wladimir
2013-12-16 18:28 ` Mike Hearn
2013-12-16 22:32 ` Andreas Schildbach
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=CANAnSg1oWrjod8N-iQg5fTzyhXWxMfSSdcnvhtjWEWcWW7_LOg@mail.gmail.com \
--to=drak@zikula$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jim618@fastmail$(echo .)co.uk \
/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