Responded to you in the pywallet thread over here.

Earlier versions of pywallet prior to September 8th had a bug which would, under some circumstances, cause it to create a recovered wallet with a password that didn't work in Bitcoin Core. It might be possible that you were affected by this bug.

I'd try this:
  1. Close Bitcoin Core, and then make a backup of all of your current wallet files (preferably onto a different drive or USB stick).
  2. Download the current version of pywallet from here (the download zip button is on the right): https://github.com/jackjack-jj/pywallet
  3. Choose a wallet.dat file that was showing the correct balance in Bitcoin Core, but whose password wasn't working, and run a pywallet recovery on it.
  4. Check if you can send a transaction, or simply sign a message, in Bitcoin Core with the recovered wallet.

Let us know if this works with one of your wallet files, or if it fails with all of them. Good luck.

Edited to add: I agree with those responding to you in the Armory thread that you probably never created an Armory wallet, and that Armory is probably unrelated to any of your Bitcoin funds (because you're able to see your balance in Bitcoin Core).

I just wanted to share this quick anecdote.

I've been using GreenAddress as my preferred mobile wallet for a little while now, and I've been quite happy with it.

I ran into a small issue on Friday that was preventing me from creating a transaction. It was easy to find a workaround though, so it wasn't tying me up. I did a little bit of troubleshooting, but eventually gave up.

I sent an email to their general support box on a Friday at 6pm (my local time) along with the steps to reproduce the issue, and I explicitly mentioned that it wasn't really affecting me, so it didn't matter how long it might take for a response.

To my surprise, I received a pretty detailed response back by 8am Saturday morning listing out a few different bugs (all relatively minor) that they had found and fixed, as well as an expected release timeframe for the updated version (about a week).

I just wanted to post here to commend them -- I was really impressed that they took the time to read my email and reproduce the issue, and that they got back so quickly (even though it wasn't a big deal to me). All this , and it's a free service.

So anyways, thanks for a great piece of software and a great service!

All the best,
Chris

And I just noticed now that we're both responding to a post made in November 2013 (a spammer necroposted, but the spammer's post was since deleted by the mods).

This shouldn't happen... the server for some reason is not sending your browser enough information to permit the login process to complete.

If it continues, you'll either need to submit a support request, or restore the wallet from a backup. To submit a support request, visit: https://blockchain.info/support-desk

Yes, but the hash target doesn't necessarily move from 135 bits to 136 bits, it moves from 135.1 to 135.4.


The total difficulty of a chain (for the purposes of determining which chain is longest) is the sum of the difficulty targets, and has nothing to do with the "luck" of the miners / block hashes.

That depends on how much you remember about the password... if it's long enough and you don't remember much or anything about it, there's pretty much no chance.

If you do remember a lot about the password, you can try to use a tool that will go through various combinations to recover it. One such option is btcrecover (I'm the dev of that tool, so naturally I'm biased), it's a free & open source password recovery tool you could try. You will need to do a bit of reading to get it set up and running though. The Tutorial and the Quick Start are here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

If you have any questions about it, feel free to ask.

There are also people in the Services forum who offer assistance with password recovery, so you could check there too.

Good luck...

It seems to be missing the coat of arms of Mexico... we're not going to have another big argument here, are we?

Please don't paraphrase what I said... what I said was "we already have a way to slow down hash generation: increase the difficulty. Keep in mind that difficulty is not a bit count [emphasis added], it's more finely granular than that."

In other words, I completely agree with deepceleron.

I have to disagree with you, but this part is a matter of opinion.

I think Bitcoin should strive to be as decentralized as possible. It's not perfectly decentralized now, but I see no reason to add additional potential points of failure or points of control. Rather I'd prefer the opposite -- remove what few remaining centralized points are left.


I suspect that the majority of nodes on the network are not miners, and therefore have no concept of best-block-so-far-in-my-pool, and remain susceptible to a DoS.


I think you just described a PoW system... hard to generate and easy to verify. How this add-on PoW is any improvement of the PoW already in use?

Cryptography is a complex subject, and cannot always be discussed in 5-word sentences (I even bolded the parts that actually needed addressing). I will try, but you may not like the results.

1. You claim nearly all CSPRNG is flawed. Then, as a workaround, you recommend vanitygen, which uses a.... CSPRNG (a fairly common one, OpenSSL). Can you explain the difference?

2. Your dartboard scheme for creating entropy is slow and biased, the sort of thing no cryptographer would ever come up with. Why did you?

3. You claim that "paperwallets" are superior because they use entropy from a mouse. You cite a bunch of wallet clients you claim to have found "through heavy testing" to be faulty, and yet every one that you cited also uses real-world entropy, just like "paperwallets". Armory, in particular, uses mouse input plus several other sources of real-world entropy. How could a cryptography expert miss this fact?

4. You've made extraordinary claims. If you are unwilling or unable to provide extraordinary proof (which is understandable for a work-in-progress), you will likely be ridiculed unless you can at least provide extraordinary professional credentials for your "few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education." Why have you done neither?

Is that better?

A node does not send a recently received block (or rather, it does not notify connected nodes that it has a new block to send) until after it has fully verified the block, including the hash target, so the only way to flood the network with blocks is if you can generate them (with the current difficulty).

As I understand it in your proposal, every X minutes, all nodes will need to see all potential blocks before a consensus can be achieved, which seems to be open to DoS.


Adding a new restriction to the target hash would slow down hash generation, but we already have a way to slow down hash generation: increase the difficulty. Keep in mind that difficulty is not a bit count, it's more finely granular than that.


I'm afraid I don't understand what you're saying here.

Nice production values, and easy to understand, but I can't say much positive about the content of the latter half of the video.

For one thing, it's very one-sided, claiming that proof-of-stake is strictly superior to proof-of-work. The link to the forums below isn't very useful, either. I might suggest a more recent thread which includes more enlightened views on proof-of-work and proof-of-state (and proof-of-idle too): https://bitcointalk.org/index.php?topic=776541.0

There's also a strong implication that Bitcoin is on its way towards switching to a proof-of-stake system, which seems extremely unlikely to happen given the problems it has (see that link for details).

Why can't you tell if they're the same? Couldn't you look up some of the addresses in a block explorer to check if they have any transactions (that match up with what you remember)? If they don't have any transactions, it seems likely that you typed in the wrong seed.

Also, be sure to read the rest of this thread if you haven't already...

A hash is just a big integer (in this context), there's no need to do something this complicated if all you're after is changing the hash-target scheme to an exactly-one-block-per-unit-time scheme. Just compare the hash's integral values, and the value closest to zero wins.

However do you think it's a good idea for the Bitcoin network to flood itself with one or two hundred fully solved blocks every 10 minutes? How would you implement an anti-DOS scheme to prevent an attacker from flooding the network with thousands or millions of solved-with-low-difficulty blocks?

It's rather telling that he claims a "paperwallet" (I assume he means bitaddress.org) has a safer RNG for key generation than Armory (which, among others, has undergone "heavy testing" by his team) because "paperwallet" uses mouse input....

Hash Hyena, I have a couple of questions / points which I hope you can address. The first is related to your interim key generation recommendations.


Given that vanitygen is just another CSPRNG, and therefore flawed by your reasoning, why would you recommend it over any of the others you mention above (all of which use, exclusively or at least in part, the same OS-provided source of entropy)? In fact, vanitygen intentionally decreases entropy when it throws out generated keys which do not match the predetermined pattern, which would (slightly) decrease the security of the generated keys.


First of all... how did you generate the random pattern of digits on your dartboard to begin with?

Regardless, any single set of random data is of course itself randomly biased, including your dartboard, and re-using it naively like this (I assume you don't create a new dartboard for each throw) combined with human bias will introduce that bias into its output. For example, it's very likely that there exists a hex digit on your dartboard which occurs less frequently on the periphery than it does towards the middle. Since I presume you'd avoid aiming your darts such that they might miss the dartboard, this hex digit is more likely to occur in your generated output.

In fact, a much better approach which would lead to less biased random numbers (assuming that the individual target boxes are small enough) would be to use a regular repeating pattern for the dartboard, where each 4x4 section contains exactly all 16 hex digits. How is it that nobody on your team caught this?

(This is to say nothing of the fact that throwing 64 darts at a dart board is silly-inefficient compared to just shuffling (well) a deck of cards...)


Next, moving back to your assessment of alternative clients:


First it should be noted that all of the clients you mention above (including BitAddress.org, which is I assume the paper wallet to which you refer) begin with the same source of OS-provided entropy (/dev/random on Linux/BSD or CryptGenRandom on Windows). Even though these two sources of entropy are in part provided by deterministic processes, they also use external human-influenced sources to maintain their internal state, e.g. the starting of programs, the initiating of or receiving of network traffic, the timings of writing to or reading from disks, etc. It is inaccurate to claim that the wallet clients you mentioned do not use significant amounts of human-source entropy.

Next, let's move on more specifically to your assertion that "through heavy testing that Armory ... has the same problems." Given that Armory gathers entropy from some of the same sources [github.com] as "paperwallet" (in fact it gathers entropy from many more human-influenced sources than "paperwallet"), can you explain why Armory has a flawed CSPRNG, whereas "paperwallet" does not?


Given that you've said
I find it extremely discouraging that you can make such basic errors as those outlined above. The net effect is to make me exceedingly skeptical of not only your overly-broad claims (which cannot be proven nor refuted due to their vague nature), but also of your abilities as mathematicians and cryptographers and even your intentions. Posting your team's professional qualifications (names, degrees, and peer-reviewed publications) would go a long way toward alleviating some of these concerns, even if you choose not to be more specific regarding these alleged vulnerabilities still under investigation.

I also hope that you can specifically address the questions above.

You're welcome, and thank you for the kind words.

I'll definitely be starting a new thread (in the Tech Support section). I'm waiting until I have a bit of time to finish up some documentation on Unicode support, and then I'll start one. Thanks for the advice!

They attempt to block Tor, but that doesn't mean they're successful. See obfsproxy.

If you have both of the "xor" files, file.x and file.y, than the additional "key" is simply an XOR cipher with a static repeating key on top of that. To quote Wikipedia:


Scary, but unfortunately not surprising...


That would probably be best. Remaining open to constructive criticism is always a good thing.