You can use software such as this to run bitcoind as a Windows service. If you decide to do so:

• Use the stopargument/stopexecutable feature to run "bitcoin-cli stop" to shut down bitcoind gracefully.
• For added safety, you may want to consider changing the user account that bitcoind runs under to either your normal user account, or a new user account dedicated to this purpose. You'll need to add the "Log in as a service" user right (with secpol.msc) to the account, and change the Service config (with services.msc) to log in as that account.

Once it's been set up, you can use the standard Windows service recovery options (with services.msc).

Edited: I tried to follow my own advice in this post, and I couldn't get it running (it was crashing for some reason shortly after start up). Just a warning, YMMV....

Sorry for my initial flippant response.

jackbox is correct (except that there are "only" 2 billion change addresses). After a change address receives its first transaction, a new change address is created, and the original change address is not used again. There's currently little reason to increase this gap limit from its default of 3, it won't effect the way Electrum works with change addresses. (Old change addresses are moved to the Used section once they no longer have a balance.)

Note that Electrum will occasionally reuse change addresses. A change address is only considered "used" once it has at least one transaction with two confirmations. If you create two transactions without waiting for two confirmations in between, and if both transactions need to use a change address, then the same change address will be used for both. There's no simple way (without mucking with the console for every transaction) to avoid this in Electrum aside from waiting for two confirmations in between transactions.

I suggest that you use the most recent version of Electrum (2.x).... That would give you about 2 billion change addresses. Hopefully that would be sufficient

Close, I think... there are still some wallets which can't import/store private keys with compressed public keys (Armory is the only popular one I can think of).

And of course there are plenty of wallets that choose not to include an import function, for example mobile ones, strictly HD ones, etc., but I'm sure you know that already.

I'd agree with everything else you said.

Thank you for checking, I appreciate it.

There's already a comment attached to MultiBit HD's BIP-39 cell which mentions Beta 8 being a requirement. (I'm the same Chris who opened that issue on GitHub )

Offline? Absolutely. It has zero network-related code.

You sound like the paranoid type (like me ), so here are some tips.

btcrecover doesn't require any binaries for the most part, but for some wallet types, installing some pre-compiled binaries can greatly speed things up (see the Installation Guide for details). I didn't compile any of the binaries, so even if you don't trust me (and you've got no reason to), you only need trust the source of the binaries.

But all of that doesn't even matter much if you want to run it offline. Just download the btcrecover .zip file, and the various binary installers you need according to the installation guide, throw them on a USB stick and install them on your offline PC.

What does matter, for the truly paranoid like me, is whether or not btcrecover has direct access to your wallet file (ideally, it shouldn't need it). To "fix" this issue, download one of the extract scripts listed here, and follow the directions in that doc to give only that one small script access to your wallet file (also offline). Once you get the extract string, you can give that to btcrecover instead of a full wallet file.

The advantage is that the extract script which has access to your full wallet file is small, simple, and self-contained. Even if you're not a Python programmer, you can probably verify that it's not doing anything "funny", has no network code, etc. (as opposed to the rest of btcrecover which has over 5,000 lines of code....)

If someone has one of your private keys, they can steal some of the funds in your wallet. If they have one of your private keys, and your wallet file (even if it has a good password), they can steal all of the funds in your wallet.


No, not without the wallet file.

MultiBit HD isn't (yet) compatible with Mycelium seeds, but it will be once MultiBit HD Beta 8 is released.

Another option (which works today) is exporting an account's master private key (its "xprv"), which can then be imported into Electrum 2.x (just paste it into the Restore Wallet dialog). The two downsides here are that the seed is not compatible with Electrum (so you'll need to keep your xprv somewhere safe as a backup), and that you'd need to export each Mycelium account individually to a separate Electrum wallet file (if you have more than one account set up, that is).

(More details on wallet interoperability is available here: https://bitcointalk.org/index.php?topic=1000544.0)

That would be better, thanks. Fixed.

I'm relatively unknown in the Bitcoin world, but I do distribute bitcoin-related software via GitHub written mostly in Python (and some OpenCL). One of the nice things about scripting languages is they're easier to check for shenanigans, as opposed to binaries.

None of the bitcoin-related software I distribute via GitHub is in binary form; I wouldn't expect anyone to trust me that much. Instead I ask users to install binary components (such as Python) from sources they do trust.

As another example, for EC math that needs to be fast, I ask users to install Armory which comes with some Crypto++ libraries on the assumption that most users trust Armory.

Having "official" dynamic libraries available could be useful, especially for Windows or OS X users where the compilation process isn't particularly easy. (Of course, only when they're actually ready for distribution.)

If you really want no wallet (e.g. if you're using it with an SPV wallet), you should add the -disablewallet option. Also, I find it less ugly (and easier) to not keep the command prompt window around, so instead you could click Start -> Run (on Win 8, you need to right click on Start, then click Run), and then enter in this whole thing at once and it will start in the background (with no command prompt window):


It's safer to shut it down using bitcoin-cli stop, e.g. in a command prompt:

It does by default, however MultiBit HD calls peerGroup.setUseLocalhostPeerWhenPossible(false) to disable this.

Thanks. I don't quite understand yet, but it doesn't surprise me that I'm wrong....

Physical theft is an issue (as I mentioned above), but if you don't understand the security model used by mobile devices, you really shouldn't be offering advice on the subject....

Generally speaking, Android wallets are a bit more secure than PC-based wallets because they're generally less vulnerable to malware. On the other hand, they're easier to lose (so make sure you have a copy of your Mycelium seed somewhere safe).


Lots of people claim that a rooted phone is something terrible. It's actually not, if you're careful. A rooted Android phone will ask you before giving an app root permissions (and if you use SuperSU it can even be configured to prompt you for a PIN). If you're the type of person (and you don't sound like it ) that always clicks "Yes" whenever they see a prompt, then rooting isn't for you. But aside from that, as long as you're careful with only installing very popular/trusted root-using apps, and you make sure any root security prompts are from a trusted app that you're expecting, you'd be fine.

The real issue isn't is your phone currently rooted, but rather can your phone be rooted? In other words, is there a known Linux kernel vulnerability that makes it possible to root your phone? If the answer is yes, then you have to be very careful about all apps that you install (it sounds like you already are), because any one of them could root your phone without your knowledge, and then it would be free to steal your btc. Practically speaking, this type of attack doesn't seem very prevalent today, but I suspect that will change as Bitcoin becomes more popular....


I do, I use GreenBits / GreenAddress.it (same devs, GreenBits is their newer semi-beta app; GreenAddress is their older one).

Honestly, the fact that you're asking these questions already puts you head and shoulders above many others....

This is a first attempt at creating a compatibility matrix for deterministic wallets. In other words, it tries to answer the questions:

When using two different wallet apps from different devs, will I have the same list of addresses and the same balance if I:

• use the same mnemonic sentence (seed) in both?
• export a master private key from one into the other?
• export a master public key from one into the other (creating a watch-only wallet)?

For now, it's an Excel file available for viewing or downloading here: https://onedrive.live.com/redir?resid=584F122BA17116EE%21313.

It has four tabs. The first, "Details", lists out (hopefully) all relevant details of various wallets that might make them compatible or not with one another.

The next three are calculated from the first; they try to answer the three corresponding questions above. (Sorry, but Excel Online doesn't render vertical text correctly, so they look a bit ugly online. Either download a local file, or hover over the wallet names in the first row to read them; they're in the same order as the wallet names in the first column.)

I'm definitely interested if anyone has any input; in particular I'm not at all confident that the Details tab has everything correct, and it's probably missing some deterministic wallets that I'm unaware of. If there are any wallet devs who could take a quick look at their wallet on the first tab to see if I got anything wrong, that'd be great!

I'm also not sure that the list of requirements (spelled out on the three right-most tabs) is sufficient to guarantee compatibility.

(Also: don't rely on this without doing your own testing first!)

I'm not sure where, if anywhere, this is headed, but it'd be nice to turn this into a set of web-based tables on GitHub, perhaps something jekyll-based like this. Again, input is most welcome.

I think it would be nice if MultiBit HD allowed you to specify a single full node (out of the 8) as a hint. Specifically I'm thinking of circumstances where someone is running a full node on the same host or local LAN, and would like to make use of it.

To a small extent, it could encourage people who are already somewhat interested in running a full node towards doing so (and conversely, not having such an option may encourage people to stop running a full node after upgrading to MultiBit HD from Classic). I think (gentle) encouragement such as this would be a good thing.

Alternatively, an option that calls peerGroup.setUseLocalhostPeerWhenPossible(true) would be almost as good IMO.



I'm off-topic here... but Electrum connects only to somewhat-centralized servers; it doesn't participate in the P2P network (it does do SPV on what it downloads, though).

Can you verify (or refute) that Mycelium checks these 20 lookahead addresses for transactions once every 24 hours? I was trying to read through the code yesterday, and I'm not sure I got it right.

Thanks!

Doesn't much matter.... even if it's lower-case ASCII characters only, that's still 26¹⁶ possible passwords; over 43 trillion billion, putting it far out of reach of any recovery / brute-forcing tool....

Thanks (again) for recommendation, onemorexmr!


So what?


Now that's different.... luckily:


and


Agreed: if OP is a thief, or if OP doesn't have any idea of what the password is, then nothing can help.