wait, which do you recommend? mycelium or spinner 0.8.3. makes no diff to me.
since one shouldn't reuse addresses (for privacy and especially in recent light for higher security), mycelium is a step in the right direction.
Topic: BitcoinSpinner - page 6. (Read 55467 times)
since one shouldn't reuse addresses (for privacy and especially in recent light for higher security), mycelium is a step in the right direction.
wait, which do you recommend? mycelium or spinner 0.8.3. makes no diff to me.
BitcoinSpinner / Mycelium Wallet
An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.
wait, which do you recommend? mycelium or spinner 0.8.3. makes no diff to me.
- Unlike the Android Bitcoin Wallet, Mycelium does not connect directly to several nodes in the Bitcoin network. This means less bandwidth requirement for your mobile plan, less power consumption, and immediate availability, but also means that the server side could establish IP/address relations. (which it doesn't)
Can you reason this claim? Bitcoin Wallet also is "immediate available", has a very low bandwidth requirement and power consumption. The Bitcoin P2P protocol is very efficient (its binary), so how can Mycelium get any better than that?
Does Mycelium depend on a server? I thought it worked like the other Bitcoin Wallet, just connecting to random bitcoin nodes and asking for bitcoin balances from relevant addresses (bloom filter).
...
...
Let me clarify a bit by pointing out differences between Mycelium and other Android wallets.
- Like the Blockchain.info app, Mycelium depends on a redundant set of servers. This is what gives the wallet tremendous speed, and makes it ready immediately after startup.
- Unlike the Blockchain.info app, Mycelium does not upload private keys to the server (not even in encrypted form), or require any registration.
- Like the Android Bitcoin Wallet, the private keys are only stored on your device (You may and should export them for backup purposes)
- Unlike the Android Bitcoin Wallet, Mycelium does not connect directly to several nodes in the Bitcoin network. This means less bandwidth requirement for your mobile plan, less power consumption, and immediate availability, but also means that the server side could establish IP/address relations. (which it doesn't)
Using a powerful server side with an optimized index over the entire blockchain is what makes it possible to determine unspent outputs, transaction history, etc for any address in milliseconds. The alternative would be to download and scan the entire blockchain. Without this it would not be possible to do effective cold storage spending or key imports. Please note that since the server does not know your keys, it cannot control your funds.
Each wallet does it differently, and that is a good thing. We need as much diversity as we can get.
sure, this is the solution. but it means some more work for us both client and server side.
Does Mycelium depend on a server? I thought it worked like the other Bitcoin Wallet, just connecting to random bitcoin nodes and asking for bitcoin balances from relevant addresses (bloom filter).
And sure, I understand that this will be more work. Let me know if I can help motivate it.
BitcoinSpinner v0.8.3b has been pushed to Google Play. It may take an hour or two before you can update it.
Version 0.8.3b:
- Fix for broken SecureRandom on Android
- Showing warning message on startup on how to mitigate weak key vulnerability
Version 0.8.3b:
- Fix for broken SecureRandom on Android
- Showing warning message on startup on how to mitigate weak key vulnerability
sure, this is the solution. but it means some more work for us both client and server side.
During your winning poker streak you do some bitcoin payments. Finally you win big and all your winnings are paid back to you ... at an address you can no longer access in your client. Whoopsie.
Since addresses are generated from a single seed, you technically still have all the private keys for it. I guess you just won,t know what the balance on them is. Maybe it would be good to "lock" some addresses in place to continue using them, instead of moving them into the "Archive" section.
generating new addresses is currently not feasible due to "the backup" problem.
I was suggesting using https://en.bitcoin.it/wiki/BIP_0032
What back up problem will that cause?
generating new addresses is currently not feasible due to "the backup" problem. also we need some more server infrastructure to handle this correctly.
we have a plan how to solve this but its complex to execute. but it will be fun to work on it
we have a plan how to solve this but its complex to execute. but it will be fun to work on it
Perhaps just make older addresses inaccessible? Show only the most recent address that has coins, when you spend it, create a new address for change, sweep from old address, and hide old address to prevent it from being used.
During your winning poker streak you do some bitcoin payments. Finally you win big and all your winnings are paid back to you ... at an address you can no longer access in your client. Whoopsie.The idea is not unworkable but there will be lots of usability corner cases like the above.
0.7 is live and kicking.
apart from minor spelling issues, please report any inconsistencies.
Security swiping worked like a charm. Thanks. apart from minor spelling issues, please report any inconsistencies.
After all this madness is done with, will you guys be able to add a deterministic key feature to allow for a new Bitcoin address for every change transaction?
Using new deterministic addresses for every transaction is quite tricky with the model that we use. Instead of downloading the blockchain we query a server for the unspent outputs of the addresses we are interested in. If the number of addresses grows infinitely something is bound to break down. Andreas has some nifty ideas on how to mitigate that, so this is something we will investigate.
Perhaps just make older addresses inaccessible? Show only the most recent address that has coins, when you spend it, create a new address for change, sweep from old address, and hide old address to prevent it from being used. That way you'll only be interested in the last address, and can ignore the rest. And since it's deterministic, you only need to back up the initial seed. If you stick with the deterministic address standard being developed, if someone wants to clean out their old addresses, you would only either have to create a separate tool to scan/sweep the seed addresses, or even just use someone else's tool, which I'm sure will be developed once deterministic addresses become more popular.
I understand that the affected wallets generate transactions that might leak key information.
So even if you generated your key in a secure way, as soon as you generated two transactionsone transaction with one of the affected clients *bam!* there is a small probablity anyone could steal all your funds.
That would make your advice dangerous and misleading. The only way to be sure is to transfer all your funds to a fixed version (or to bitcoin-qt, or to a paper wallet...).
Corrected for accuracy.So even if you generated your key in a secure way, as soon as you generated two transactions
That would make your advice dangerous and misleading. The only way to be sure is to transfer all your funds to a fixed version (or to bitcoin-qt, or to a paper wallet...).
This specific bug is very rare. It happens when the broken RNG generates exactly the same random number for both signatures. It has been noted that it was happening a few times a month worldwide. There are scripts running that search the blockchain for this specific issue: two signatures in two different transactions from a single private key that have the same random number in the signature.
So, if your coins have not been stolen yet and you update to the new RNG then they probably won't be stolen (by this method).
0.7 is live and kicking.
apart from minor spelling issues, please report any inconsistencies.
apart from minor spelling issues, please report any inconsistencies.
westkybitcoins,
Thanks for the answer.
Thanks for the answer.
Question:
Private keys doesn´t start with 5?
Private keys doesn´t start with 5?
It depends on whether the public key is compressed or not:
Quote
For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5. Private keys associated with compressed public keys are 52 characters and start with a capital L or K. This is the same private key in wallet import format.
Source: https://en.bitcoin.it/wiki/Private_key
Question:
Private keys doesn´t start with 5?
Private keys doesn´t start with 5?
Version 0.7.0 has been pushed. It may take an hour or two before it is available in the Google Play Store.
This version features the key migration wizard. If you already migrated your keys in version 0.6.5 manually you should not notice any difference. Otherwise it will nag you on the startup view until you complete the wizard for every key.
This version features the key migration wizard. If you already migrated your keys in version 0.6.5 manually you should not notice any difference. Otherwise it will nag you on the startup view until you complete the wizard for every key.
I think Mycelium is already functional enough to avoid this issue: Go to https://www.bitaddress.org, generate a key, print a backup, scan it into mycelium, and stash the backup safe somewhere. Of course any fixes will also help a lot. Thanks guys!
I understand that the affected wallets generate transactions that might leak key information.
So even if you generated your key in a secure way, as soon as you generated one transaction with one of the affected clients *bam!* anyone could steal all your funds.
That would make your advice dangerous and misleading. The only way to be sure is to transfer all your funds to a fixed version (or to bitcoin-qt, or to a paper wallet...).
Jump to: