From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VsVhQ-0008Hr-3x for bitcoin-development@lists.sourceforge.net; Mon, 16 Dec 2013 10:46:56 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of fastmail.co.uk designates 66.111.4.28 as permitted sender) client-ip=66.111.4.28; envelope-from=jim618@fastmail.co.uk; helo=out4-smtp.messagingengine.com; Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VsVhO-0002Lm-9a for bitcoin-development@lists.sourceforge.net; Mon, 16 Dec 2013 10:46:56 +0000 Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 75FE6206CE for ; Mon, 16 Dec 2013 05:46:48 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 16 Dec 2013 05:46:48 -0500 Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 54A9B29FA48; Mon, 16 Dec 2013 05:46:48 -0500 (EST) Message-Id: <1387190808.12225.60115997.547B23B6@webmail.messagingengine.com> X-Sasl-Enc: BCPp6eV9J7yVYK+SFEjVCsSyHu2jA8OPlTALLIJ7Se1L 1387190808 From: Jim To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-7f24e732 In-Reply-To: References: Date: Mon, 16 Dec 2013 10:46:48 +0000 X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: reddit.com] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (jim618[at]fastmail.co.uk) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (jim618[at]fastmail.co.uk) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VsVhO-0002Lm-9a Subject: Re: [Bitcoin-development] Fees UI warning X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 10:46:56 -0000 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