I think floor is superior to round as you always want to know 'Do I have enough money ?"
If you show amount = floor(total) then you have at least that amount to spend, whereas with round you aren't sure if you can afford the amount shown.
Ok, for the wallet balance this seems reasonable. Does the same logic apply to payments sent and payments received (transactions list)? |
|
|
|
I think there are a few apps and website that use the 'satoshi digits' to indicate the roll of the dice etc so you will always need the option to show all 8 digits.
I think most of the time people read the first 3 or 4 digits and then the other digits hardly even register in their visual cortex. Maybe we could have the first few digits in regular sized font and then the rest in a smaller font, like this:
0.12345678
big = 10pt, small = 7pt.
The cutoff for big/small would have to be an option.
That way there would not actually be any rounding, but you'd only notice the significant digits.
I think this is what the blockchain.info phone app does. I liked the idea when I saw it, but it looked kind of weird to me. In a similar vein to changing font size, changing the colour saturation might also work, e.g. 0.12345678or both combined (now my favourite after clicking preview)? 0.12345678Thanks for the suggestions. Bitcoin Wallet already has a highlight exactly like this: 0.12345678, the blockchain.info app just forked from Bitcoin Wallet... The interesting info is that people seem to prefer floor to round, I would have never expected this. Any opinions towards round? |
|
|
|
Maybe it's just me but I don't like rounding. What I also don't like is unformatted floats.
IMHO:
1.00000000 -> 1.00
1.00001000 -> 1.00001
What's an "unformatted float"? So you like the right side and dislike the left side? And - more to this topic - you dislike 1.00001 -> 1.0000 (because of 4 digits of precision)? Edit: If it's an optional feature then I'm all for it.
Sure, it will stay optional (8 digits of precision means no rounding at all). |
|
|
|
I'd recommend displaying mBTC or even µBTC by default. Additionally group thousands/millions like this: 1.00000000 BTC = 1 000 000.00 µBTC
Ah, I forgot to mention. The "moving of the comma" topic is not the main topic of this poll. Are groups of 1000 (as in 1 000 000) also used after the comma? I thought only before. |
|
|
|
|
The purpose of my post is getting opinions about rounding of Bitcoin amounts.
Most clients already cut of insignificant zeros at the end. So for example, 1.22000000 gets 1.22. Still, especially if you use currency conversion frequently, you'll have a lot of crude amounts (like 0.31745883 for a burger) in your wallet. In my opinion, this makes it hard to read, especially for non-technical people.
Bitcoin Wallet currently implements a labs feature that allows you to round to either 4, 6 or 8 digits after the comma (see Preferences -> Labs -> Precision of Bitcoin values). Note that when entering amounts yourself (such as when sending a payment) you still can use any precision you like. Also, the setting of course doesn't affect any internal calculations, so there is no "adding up of rounding errors" and stuff like that.
My questions go to all of you, not only Bitcoin Wallet users:
Would you use such a feature in your client?
Do you think it makes sense, also for non-technical people?
Do you find 0.1255 easier to read than 0.125501?
Should we kind of standardize the options (4, 6 and 8 digits) for all clients?
I deliberately left the option of 2 digits out, because we're way past the "0.01 is equivalent to a penny/cent" era. Do you miss it still?
Which option should be default?
|
|
|
|
My app crashes when trying to import a private key. Is this the same issue?
Depends on the crash. Have you sent a crash report? Which email address did you use (so that I can identify your report)? |
|
|
|
Will you ever add a sync-on-wifi-only option?
The plan is to make the network so efficient that you don't care. As soon as bloom filtering is supported by virtually all nodes, it should be possible to stay within 2 MB per month with moderate use. Currently only one quarter of peers support bloom filtering, so make sure to update your bitcoin-qt or bitcoind to 0.8.0. |
|
|
|
I keep my savings in several privkeys, none of which is implemented in software anywhere.
I wonder how you manage to transfer your private keys between devices without accidently leaking them. If you send them by mail or instant message unencrypted, they are obviously leaked. If you copy them to the clipboard (cut & paste), any application can steal them. I am sure there is already malware that monitors the clipboard. If you copy them to external storage on Android unencrypted, again any app can steal them. If you view and scan them using QR-codes, observers can snapshot them as well. This is why I am extremely cautious regarding import and export of private keys and always require encryption. Note that MultiBit uses the same scheme, so you should be able to exchange keys without the openssl step inbetween. We have deliberately chosen this openssl standard, because it should be easy to implement by other applications as well. Some months ago I have - in a private branch - implemented the ability to display private keys as QR and import them by scanning. I will not merge this as is, but if you want you can compile it yourself (and enhance perhaps, to make it more secure). I'm thinking about the possibility to import private keys by sweeping. This would allow for redeeming vouchers / paper wallets, but its probably not what you want. However, its all just a workaround. The most convenient and secure way to transfer money is signing a Bitcoin transaction. |
|
|
|
When I first ran v. 2.41, it gave me a warning about older versions of Android not being supported in the future and said that I should transfer my bitcoins out of the wallet. However, when I try to send now, it crashes. Is there any way to roll back to the previous version or import the private keys into another client? Thanks.
I'm sorry about this, it will be fixed in version 2.42 which will be most likely released tomorrow. It was caused by some Java6 code creeping in, and your phone can only do Java5 unfortunately. Don't worry, your phone will be supported long enough to move your coins out. And actually if you're happy with the current feature set, you will likely be able to use the app much longer. |
|
|
|
I'm proud to announce version 2.41 of Bitcoin Wallet. The changes are mostly under the hood, but some of them are massive: - Seriously reduced bandwidth and CPU usage due to usage of bloom filters on peer connections
- Faster connection setup to peers
- Ability to spend your own change instantly, without waiting for confirmation
- No need to manually disconnect any more for any of the preferences
- Preference for showing the connectivity indicator
- Shortcut to request coins by long tapping on QR code
- Enhanced Peer monitor to show more info about peers, e.g. hostname
- Fallback for fetching exchange rates (bitcoincharts first, then blockchain)
- Lots of small improvements and bugfixes
- Based on bitcoinj 0.7
The bloom filter feature depends on seeing at least one bitcoin-qt/bitcoind 0.8.0 (protocol version 70000+) to download blocks from. As of today, the chance for this is roughly 50% and will increase as the new version spreads. If you want to help, update your bitcoin-qt now. Download/update from Google Play: https://play.google.com/store/apps/details?id=de.schildbach.walletDirect download: https://code.google.com/p/bitcoin-wallet/downloads/listSource: https://code.google.com/p/bitcoin-wallet/source/checkoutThanks to everyone who contributed to Bitcoin Wallet and bitcoinj. Mike Hearn and Matt Corallo earn extra hugs for making bloom filters a reality! |
|
|
|
Why are there no android wallets that let me type in a USD amount to send to someone? Most of my transactions are denominated in dollars. I should not have to get out a calculator every time I want to send bitcoin. Multibit does this.
Try Bitcoin Wallet (see my signature). You can enter amounts in any currency that gets traded for Bitcoin. I implemented this 1 1/2 years ago I guess. |
|
|
|
I will store my private keys in my data tier of course, but I was referring to storing the blockchain/SPV data, that needs constant updating and can't just work instantly when the server is up.
I think bitcoinj is currently the best approach at trustless operation. However, you'd still need to download at least the blockchain headers plus relevant transactions on each start. You can cut this down dramatically by using checkpoints. However, for this to work you need to update your client with the latest checkpoint data from time to time. Which is of course technically local storage again. Or trust, if you are bootstrapping your client from a remote server each time. |
|
|
|
trustless bitcoin API that doesn't require local storage
I don't think its possible. You need to store your private keys somewhere. Either locally, so you need local storage. Or remote, so you need trust. At the very minimum, you need to trust that the remote storage does not go away. |
|
|
|
I just uploaded to http://code.google.com/p/bitcoin-wallet/downloads/lista 'spendpolicies' version that has the ability to spend your own change. For this to work, you your previous transaction needs to have been seen and echoed back by the network. This has been symbolized by the grey got growing larger for some versions now. So if you start a new wallet and send one chunk of Bitcoins to it, you are no longer limited to one outgoing transaction per 10 minutes. Just make sure you're connected when sending. Anyway, the branch could use some testing. It also contains all the stuff from the bitcoinj0.7 version. Just in case you snatched these version when I had it uploaded some days ago, please update to the current version. The old one can corrupt your wallet (easy fix: reset blockchain). |
|
|
|
This is only the first Bloom filter code so I imagine there will be refinements in the future.
For mobile phones the reduction in total bandwidth used will be very handy for people on monthly data caps also.
Bloom filters will never be faster than just using getheaders. But yes, network efficiency is more important anyway. And who knows, maybe its good that SPV clients are not fully optimized right away. After all, bloom filters puts some burden on the full node. We can optimize when bloom filters have been rolled out to 40.000+ Bitcoin users and understand the implications. |
|
|
|
My Nexus Galaxy appears to be I/O-limited, maxing out at about 40 blocks/second even with just getheaders (no bloom filtering involved) and on speedy & stable WLAN. My g-slate can do up to 80 blocks/second. Write ahead caching might be a solution. This can write blocks in larger chunks and skip most of the seeking to the start and writing the hash of the chain head all the time. However, this would introduce the risk of the chain getting out of sync with the wallet(s). Thus, after getting advice from Mike I postponed these optimization until bitcoinj can recover from drift without replaying the whole blockchain. Hi Andreas,
I was wondering what sync speeds you were seeing with bloom filters ?
If I download 1 months / 3 months of blocks I am getting about 80 blocks/ second on 3G and 130 blocks/ second on WiFi (1MB down, 100kB up). This is from riker.plan99.net
Android Wallet and MultiBit should be getting about the same I think but it would be nice to have the numbers to confirm it.
|
|
|
|
riker.plan99.net is only serving prodnet, not testnet. Sorry, I forgot to mention this. However, on testnet its quite easy to connect to a 0.8 node. Just have a look at the peer monitor and see which peer its downloading from (printed in bold). Of course, its always good to connect to your own peer, for debugging purposes. |
|
|
|
|
Show Posts
