Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
I’m inclined to agree, as this was discussed on multiple occasions and seems to fix a lot of the address re-use problems. With hot topics like “coin validation”, I think it’s important to highlight the privacy that generating fresh addresses from public extended keys grants us. Also thinking about implications regarding non-merchant use of Payment Protocol, encouraging the exchange of extended public keys instead of a single address could be a boon for Payment Protocol to actually be useful for users. Initially, the idea was that the merchant would generate a new address from an extended key and include that in the Payment Request. How do we handle pushing the extended public key down to the wallet itself? Do we just shoehorn the exchange of keys into the Payment Protocol itself via a special tag or would this require more substantive change? Services could develop to facilitate the exchange (acting as a sort of “PP gateway”) or wallet software might be able to directly communicate, perhaps by exchanging PGP-encrypted files in Payment Protocol format via Bluetooth, AirDrop, email, BitMessage, or whatever future communications channel comes into being. Thanks again to Peter for putting together a consolidated list of topics! Taylor On Dec 19, 2013, at 2:40 PM, caedes wrote: > I feel it's missing mention of using (or not) *extended public keys* > from bip 32 to share multiple addresses in one go, so regular payments > can be done without asking for further addresses. Also since whoever has > the extended key can generate public keys this might help P2SH where the > public key is also needed. -- 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
Re: [Bitcoin-development] Fees UI warning
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 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. > > 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 -- 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
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
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 wrote: > I'm sure that you can find a sponsor for a dedicated server. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
On Dec 3, 2013, at 2:20 PM, Mike Hearn wrote: > On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring > wrote: > 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. > > Lots and lots of people are psychologically trained to expect that they pay > the sticker price for things. Yes in recent times some places have started to > show additional fees for using credit cards, but only as a way to try and > push people onto cheaper forms of payment, not because customers love > surcharges. It's for that reason that many merchants don't do this, even when > they could - I pay for things with Maestro Debit all the time and I don't > think I've ever seen a surcharge. That system obviously has costs, but > they're included. > > This is just a basic cultural thing - when I buy something from a shop, the > social expectation is that the seller should be grateful for receiving my > money. "The customer is always right". When I send money to a friend, the > social expectation is different. If my friend said, hey Mike, could you send > me that 10 bucks you owe me from last weekend and what he receives is less > than 10 bucks, he would probably feel annoyed - if I owe him 10 bucks then I > owe him 10 bucks and it's my job the cover the fees. That's why PayPal makes > sender pay fees in that case. > > Maybe we need new terminology for this. Interior fees for included in the > price/receiver pays and exterior fees for excluded from the price/sender pays? > > 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. > > Have you thought through the UI for that in detail? How exactly are you going > to explain the fee structure? Let the user pick the number of blocks they > need to wait for? What's a block? Why should I care? Why shouldn't I just set > the slider all the way to the other end and pay no fees at all? Is the > merchant going to refuse to take my payment? Gavin just said that's not > possible with Bitcoin-Qt. I'm thinking for bitcoinj I might go in a slightly > different direction and not broadcast payments submitted via the payment > protocol (and definitely not have one wire tx pay multiple payment requests > simultaneously, at least not for consumer wallets). > > Most of what you mentioned is entirely culture-dependant. In the majority of North America, sales tax is calculated at the point of sale on top of the advertised price. When my local government increases sales taxes, we feel it BECAUSE we see it. Expose information in a digestible way. Just because you don’t instinctively know how to implement a UI for varying sender fees doesn’t mean that other wallets don’t. Leave the fee structure alone. Instead, let’s concentrate on how to calculate an accurate assessment of what a reasonable fee is for reliable service and let the software shake out the rest. Taylor -- 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=84349351&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
On Dec 3, 2013, at 12:29 PM, Mike Hearn 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.-- 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=84349351&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Extending the Payment Protocol with vCards
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 signature.asc Description: Message signed with OpenPGP using GPGMail -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
