<unnamed>

Public Key

npub1euxrd57ta7u8mknwsv9w8efhx9p8p3p25vgjfvyr33npnecjpz8qe0fmtt

Profile Code

nprofile1qqsv7rpk6097lwramfhgxzhru5mnzsnscs42xyfykzpcceseuufq3rspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsa2r23v

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:10:48 CEST

- reply

📅 Original date posted:2013-12-16
📝 Original message: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 at gmail.com> wrote:
> On Mon, Dec 16, 2013 at 11:46 AM, Jim <jim618 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131216/112aa966/attachment.html>

2023-06-07 17:10:27 CEST

- reply

📅 Original date posted:2013-12-08
📝 Original message:Maybe bitcointalk.org would like to donate a few BTC from the 6,000 BTC "new forum" fund to sponsor hosting?
On Dec 8, 2013, at 5:51 PM, theymos <theymos at mm.st> wrote:
> I'm sure that you can find a sponsor for a dedicated server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/24223e3b/attachment.html>

2023-06-07 17:10:10 CEST

- reply

📅 Original date posted:2013-12-03
📝 Original message:On Dec 3, 2013, at 12:29 PM, Mike Hearn <mike at plan99.net> wrote:
> It may be acceptable that receivers don't always receive exactly what they requested, at least for person-to-business transactions. For person-to-person transactions of course any fee at all is confusing because you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the other end. I wonder if we'll end up in a world where buying things from shops involves paying fees, and (more occasional?) person-to-person transactions tend to be free and people just understand that the money isn't going to be spendable for a while.
> person-to-business transactions. For person-to-person transactions
Why should there be two classes of transactions? Where does paying a local business at a farmer’s stand lie in that realm? Transactions should work the same regardless of who is on the receiving end.
> any fee at all is confusing because you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the other end
The paradigm of sending money has an explicit cost is not new... I think people are used to Western Union/PayPal and associated fees, no? It’s okay to have a fee if it’s reasonable, so let’s inform the user what the estimated cost is to send a transaction in a reasonable amount of time.
> wonder if we'll end up in a world where buying things from shops involves paying fees
I stayed in a hotel for the first night here here in Milan, and there was an (anticipated) surcharge for the use of credit over cash. Again, nothing new here.
Fees are only confusing because existing clients do a terrible job of presenting the information to the user. In Hive Wallet, I’m of the opinion that we should inform the user in an intuitive way to let them make an informed decision.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/7758e30c/attachment.html>

2023-06-07 17:09:20 CEST

- reply

📅 Original date posted:2013-11-09
📝 Original message:Hi everyone,
I made a post on the BitcoinTalk forums <https://bitcointalk.org/index.php?topic=329229.0> outlining how the Payment Protocol could be extended with optional vCard support to increase the usability of Payment Protocol for user-to-user transactions and improve the user experience in wallets supporting PP.
I’ve outlined the concept in as much detail as my feeble brain can handle, drawing on BIP 0070 itself and Mike Hearn’s Payment Protocol FAQ. I know there is interest in “contact exchange” functionality from the Hive team, so I’m hoping this will begin a discussion on how we can make wallets more friendly in a standard way.
Please read, digest, and let me know if you have any feedback.
Thanks,
Taylor Gerring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131109/0af3c2d6/attachment.sig>