I'm sure that feature is available, but I'm afraid I know next to nothing about OS X and so I probably can't help you very much...

Just like on other OS's, you do need Bitcoin Core installed and synced. Have you done that yet?

The Armory file format is the same across platforms, so you should be able to use the 'Wallets -> Import or Restore Wallet' menu option to import an Armory .wallet file.

This will tell you where to find your wallet file on your old hard drive for most operating systems: https://bitcoinarmory.com/faq/#q3

Do you mean that when you created your wallet, you chose a password that was the same as your seed?

Although there shouldn't be any problem with that, I have to ask... how do you remember it? The point of having a separate password is so that you don't need to remember the seed....

In any case, if you have the full seed (it should be twelve words long), you can just do a File -> New/Restore, create a new wallet file, choose to Restore from its seed, and then paste it in.

Assuming that the address you want to remove was created prior to version 4.0 (roughly the beginning of October), and that you're running a recent version today (3.47 or later), it is theoretically possible but would be a giant pain, not to mention fraught with peril. (If you're currently running a version older than 3.47, it's actually much easier. If the address you want to remove was created after version 4.0, it may not even be possible).

So, how important is it to keep your old addresses? Is it worth a few hours of your time? More importantly, is it worth paying somebody else for a few hours of their time to figure out and document how to do this (would involve decrypting a backup (easyish), modifying a protobuf-format wallet file (not so easy...), and re-encrypting it (easyish) so that it can be restored in the app)?

If you're an IT person and would like to try figuring it out yourself, I could give you some starting points, but like I said it won't be easy....

Although bitcoinj has a full node option, I don't think MultiBit can be configured to use it (I could be wrong though).

You can run bitcoind or btcd on the same machine (or on another) and then force MultiBit to connect to it and only it. This gives you the benefit of using full height-based transaction validation. To do so, locate your multibit.properties file (in the %AppData%\MultiBit folder on Windows) and add this (it's just a text file):


(or some other IP or DNS name)

I hope you'll understand that I will not... that's up to silverfuture to decide.

Although if you have a set of password criteria in mind, I might be able to estimate such a thing for your circumstances, but you'd need to be fairly specific (about the password, about your wallet software, and possibly about your PC as well).

I have a favor to ask of someone who already has MultiBit HD built and installed.

I'd like to get a copy of a newly created & empty wallet file. I could d/l the JDK and build it myself.... I'm just being lazy and hopeful that someone might take a few minutes to help me out.

If anyone's willing, specifically I'd like a:

• Newly created wallet,
• this password used to protect it: btcr-test-password
• nothing else added to it or changed.

FYI this is so that I can test bitcoinj support I recently added to btcrecover.

If anyone's willing, please email the wallet file to cenrug-mbhd@yahoo.com. I'll lock this thread if I get any takers.

Thanks!

n/m

A lot of people on this forum choose to help out just for the heck of it, or just because they believe that Bitcoin has a future. For me, it's also (in part) because I hope to learn something new. So, for whatever it's worth, you're helping me (and by the way, I'm actually older than 32 by a little...)


Sorry, I really know almost nothing about OS X. I suspect that OpenSSL comes pre-installed on it, so that should actually make your life easier, it's just a matter of navigating the command line interface.

There are many pitfalls here, e.g. the caps lock key (as VanityMemory already mentioned), the input method editor, using different keyboard layout languages, and just plain-old-typos. However, if there's something wrong with the wallet file itself, there are two ways you can attempt a recovery. (These are Windows-specific instructions; Linux will differ.)

---

Method 1 - restore from digital backup

1. Open Armory and take note of the ID of the wallet you're having trouble with.
2. Close Armory.
3. Go to the Start Menu, click Run (or hold down the Windows key and press R -- on Windows 8 this is the right alternative).
4. Type this in the text box: "%appdata%\Armory", and then click OK to open the wallet storage directory.
5. Right click on the wallet file that has the ID you noted in step 1 (and doesn't contain "backup"), and click "Cut".
6. Minimize your windows, right click anywhere on the Desktop, and click "Paste" to move your wallet file to the Desktop for safe keeping.
7. Open Armory.
8. Click the "Import or Restore Wallet" button (you'll have to wait until Armory reaches an "Online" state).
9. Choose the "Import Digital Backup" option.
10. Type this in the Filename text box: "%appdata%\Armory", and click the "Open" button.
11. Select the wallet file that has the ID you noted in step 1 (and does contain "backup"), and click the "Open" button.
12. Click "Yes" when prompted.

---

If this doesn't work, you'll need to restore from your paper backup (you did print one out, right? )

Method 2 - restore from paper backup
(This method may not restore all of comments you've added to your wallet, but it should recover all of your bitcoin funds.)

1. Follow steps 1 through 8 above, if you haven't already.
2. Click the "Import or Restore Wallet" button.
3. Choose the "Single Sheet Backup" option, and then just follow the instructions.

If neither of these options work for you, there might be a typo in your password. There are tools that can try to search for typos in your password (e.g. btcrecover), but they they do require some effort to use....

Let us know how this turns out (hopefully well!)

That sounds like a good idea


I agree... I'm grasping at straws here.


Thanks for the link, I added a note to that issue a short while ago. It appears that clubshaft was using the correct password, but more than one of his .wallet and .key files were corrupted, and he eventually was able to recover an older .key file he retrieved using a file restoration utility. I'm not sure I agree with his conclusion that the file corruption was the result of a bug in MultiBit, but I've no way to tell. It would be interesting to examine both his corrupted and uncorrupted files to look for differences... that might give some insight as to the source of the corruption (or it might not).

Have you tried following gary-rowe's advice regarding openssl yet? I'll repost it below (slightly modified for a default Windows install):

Now that you have a .key file do the following (I've made the instructions step by step for Windows):

1. Ensure you have OpenSSL installed. Specifically, you should choose "Win32 OpenSSL v1.0.0o Light".
2. Copy your multibit key file into the C:\OpenSSL-Win32\bin folder, and rename it to "multibit.key".
3. Open the command prompt and navigate to C:\OpenSSL-Win32\bin (on Windows type "cd \OpenSSL-Win32\bin" at the command prompt).
4. Enter the following at the command prompt on a single line:
Change "yourpassword" to your password (but leave the "pass:" prefix in there).

OpenSSL will attempt to decrypt the file and will tell you if it is successful. The decrypted keys will be placed in decrypted.txt and should now be considered compromised. You'll need to sweep funds out of them as soon as possible into a safe area. If you have those keys you have your bitcoins.

If you open the decrypted.txt file in a text editor like Notepad, you should see one or more lines like this, one for each key:

You can see the key file format here: https://multibit.org/en/help/v0.5/help_exportingPrivateKeys.html

Agreed.

Spam-- as in the junk that people like awesome31312^* add to their sig in the hopes of netting a few pennies. (yeah I know I should just enable the "Don't show users' signatures" option and stop complaining)

* nothing personal, I just hate sig spam

Correct.

At first glance, that seems... silly. But if you consider how it works, and how it might work if there wasn't a reshuffle before each hand, it makes more sense.

Right now, at the beginning of each hand you're given access to a hash of the shoe. At the end of a hand, you're given access to the entire contents of the shoe. This supposedly^* makes the game fair because the server can't change the shoe after the game has begun.

Obviously, once the shoe is revealed, it can't be used for the next hand, so a reshuffle is in order. An alternative would be to only show the entire contents of the shoe right before a reshuffle, e.g. once 66% or 75% (or some other %) of the shoe was used up and a reshuffle would be "normally" required.

But what happens if the player wants to leave before the next reshuffle? In other words, if the player wants proof that the game isn't rigged, should they be forced to continue playing until the next reshuffle?

One option might be to allow the player to view the contents of the shoe at the end of any hand of their choosing (which of course would be followed by a reshuffle), but this isn't any better. A card counter could use this to their advantage and force a reshuffle whenever the count gets too low. (This sort of strategy is possible IRL but more difficult because it involves moving between tables under the watchful eye of security.)

So there probably isn't a better option; had I been the coder I probably would have made the same decision.

* I haven't actually looked at CoinJack's provably fair algorithm, so I don't claim it actually is provably fair, I'm just taking their word for it. If all they provide is a hash of the shoe and nothing more, there would definitely be some problems....

I get the same impressions (not that I'm any sort of BJ expert though... I haven't played in years). There's a lot of good information available on the topic, though.


Regardless of shoe size, a reshuffle occurs before every hand. (Implementing it any other way would be problematic due to the the provably-fair requirement.)

The two are incompatible with one another, but there would remain no way that an outside observer (who doesn't have the privkey used for a signature) to determine if k was generated deterministically or it was "mined", so your method remains possible (and it's pretty cool that you went and implemented it ).

Yes, and it's quite salient that you brought up TrueCrypt -- it has some leaky side channels which (before the ongoing audit began) were pointed out as avenues for exactly this kind of evil-implementation attack (and yes the source code was examinable at the time, but there wasn't a reproducible build process for Windows).

Here are the rules of a version that I tested a little while back (I don't know what's changed since then).

• number of decks: configurable according to OP
• dealer wins ties (very uncommon, typically it's a push)
• double after hit allowed and on any card values (fairly uncommon)
• can't split more than once (split 3 times for up to 4 hands is more common)
• double after split allowed
• hitting (and/or doubling) after splitting aces allowed
• BJ pays 3 to 2 or 6 to 5: configurable according to OP
• dealer peeks (if dealer starts with 21, the hand immediately ends)
• can't double for less (uncommon)
• dealer hits on soft 17: configurable according to OP
• no insurance

Sorry, I wasn't very clear.

The "attack" I was trying to refer to involves an evil (and closed source) ECDSA implementation that intentionally leaks X successive bytes of a privkey in each signature it creates. Only someone aware of the leak, e.g the authors of the implementation, would able to take advantage of it. Given multiple signatures, the evil authors could reconstruct privkeys of those using their implementation.

An advantage (perhaps not the main advantage though) of a deterministically generated k is that one can validate the output of a closed-source implementation without needing the source code (assuming the method of generating k is published). If for example ProprietarySoft Corp. published an ECDSA library, researchers could verify that it wasn't using this channel to leak privkeys.

I was just bringing up that point -- none of this really applies to open source implementations.

I thought that the ability to create subliminal messages in a security protocol was generally considered a flaw of that protocol.

For example, an evil ECDSA implementation could leak a user's private key to the implementation's authors. Isn't that (one) reason that newer ECDSA implementations deterministically generate k?

(I'm just repeating what I've read elsewhere on the forums and on the web, e.g. DJB's blog.)

I hate to say it, but that makes it seem like a mistake in the password you're using (I'm still not 100% sure though). You've already tried a bunch of combinations, but did you follow bitbaby's advice regarding the use of an Input Method Editor (if you've ever used one)? Do you ever switch keyboard layouts (e.g. between English/ASCII and Cyrillic)?

If it is a typo in the password, you'll have to look into a password recovery tool (or a paid service). This one can try different combinations of typos in a starting password, it's free but it's tricky to get working if you're not familiar with using the command line: btcrecover. The Quick Start is here.