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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VscO2-0007lu-Cq for bitcoin-development@lists.sourceforge.net; Mon, 16 Dec 2013 17:55:22 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.175 as permitted sender) client-ip=209.85.213.175; envelope-from=taylor.gerring@gmail.com; helo=mail-ig0-f175.google.com; Received: from mail-ig0-f175.google.com ([209.85.213.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VscO0-0003Hl-9n for bitcoin-development@lists.sourceforge.net; Mon, 16 Dec 2013 17:55:22 +0000 Received: by mail-ig0-f175.google.com with SMTP id j1so4324503iga.2 for ; Mon, 16 Dec 2013 09:55:15 -0800 (PST) X-Received: by 10.50.108.235 with SMTP id hn11mr15008839igb.0.1387216514911; Mon, 16 Dec 2013 09:55:14 -0800 (PST) Received: from [192.168.1.118] (207-181-233-57.c3-0.mct-ubr1.chi-mct.il.cable.rcn.com. [207.181.233.57]) by mx.google.com with ESMTPSA id f5sm17395284igc.4.2013.12.16.09.55.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 09:55:12 -0800 (PST) From: Taylor Gerring Content-Type: multipart/alternative; boundary="Apple-Mail=_56B18513-1F96-4290-80E8-36BDEF959E3A" Message-Id: <75261AAF-989D-4A9A-A99A-160B13BC6B09@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Mon, 16 Dec 2013 11:55:11 -0600 References: <1387190808.12225.60115997.547B23B6@webmail.messagingengine.com> To: Bitcoin Dev In-Reply-To: X-Mailer: Apple Mail (2.1822) X-Spam-Score: -0.6 (/) 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: doubleclick.net] -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 (taylor.gerring[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1VscO0-0003Hl-9n 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 17:55:22 -0000 --Apple-Mail=_56B18513-1F96-4290-80E8-36BDEF959E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Providing people with a great user experience is something that Hive = Wallet is enthusiastic about, so this is stuff we=92re thinking about = constantly. For example, how do you alert the user to abnormal activity = (i.e. sending =93too much=94 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=92t 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=92s = 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=92m 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 =93send 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=92ll leave everyone with an approach we=92re 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 wrote: > On Mon, Dec 16, 2013 at 11:46 AM, Jim 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. >=20 > 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. >=20 > What we should really do is: >=20 > - Use deterministic wallets. Making regular backups becomes optional = (to retain label and transaction data and such) instead of mandatory. >=20 > - Don't support importing private keys. Replace the importing of = private keys by a "sweep" function. >=20 > Wladimir >=20 > = --------------------------------------------------------------------------= ---- > Rapidly troubleshoot problems before they affect your business. Most = IT=20 > organizations don't have a clear picture of how application = performance=20 > affects their revenue. With AppDynamics, you get 100% visibility into = your=20 > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of = AppDynamics Pro! > = http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg.c= lktrk_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail=_56B18513-1F96-4290-80E8-36BDEF959E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Providing people with a great user experience = is something that Hive Wallet is enthusiastic about, so this is stuff = we=92re thinking about constantly. For example, how do you alert the = user to abnormal activity (i.e. sending =93too much=94 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=92t 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=92s 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=92m 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 =93send 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=92ll leave everyone with an = approach we=92re considering once floating fees are feasible[4], = something Mike Hearn asked about in a previous = thread.



=
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://p= ubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg.clktr= k_______________________________________________
Bitcoin-developmen= t mailing = list
Bitcoin-development@lists.sourceforge.net
https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development

= --Apple-Mail=_56B18513-1F96-4290-80E8-36BDEF959E3A--