this works on a ltc wallet as well? Also thanks for the help  Yes, it'll work with Litecoin-Qt wallets too, thanks to the fact that they use the same wallet container (BerkeleyDB) and mkey formats. I updated the docs. |
|
|
|
I need the script to generate a password that must contain 6 and 7 within the parameters already set, if someone could help me modify the script that would be great  i.e: it would generate PASSWORD63427 PASSWORD364734 If nobody has offered up a modified ruby script yet, I can offer a python script instead... Instructions: download the scripts from here: btcrecover download. These are Python scripts, so you also need to install Python, instructions are here: Installation requirements for Bitcoin-qt wallets. You just need Python, the other two libraries are optional for Bitcoin-qt. Just to make sure that I understand, you need something that: - Always starts with PASSWORD
- Ends with between 3 and 6 digits
- Of those digits, must contain at least one 6 and one 7 (and possibly more)
If that's correct, then create a file with Notepad named exactly "btcrecover-tokens-auto.txt" that contains this: #--pause --wallet wallet.dat --autosave progress.sav
# Starts with PASSWORD (required)
+ ^PASSWORD
# Has at least one 6, one 7, and one other digit (required)
+ 6
+ 7
+ %d
# Has up to three other digits (not required)
%d
%d
%d
After unzipping the btcrecover scripts, place the btcrecover-tokens-auto.txt file and a copy of your wallet.dat into the same folder as btcrecover.py and double-click btcrecover.py. Of course, it's in your best interest to be paranoid: you may want to do all this inside a VM that has no Internet connection, or you may want to unplug your Internet connection while the script is running. If you're really paranoid, you can also take a look at this: extract-mkey README. Good luck! |
|
|
|
It happened to my mom too which makes it worse  I didn't want to take responsibility for them. She made a super long complicated password, wrote it down, and a year later we come back to look at it and it has 2 symbols that are either a "t" or an "r" a symbol that is either a "6" or a "b" a third symbol which is either a "1" a "I" or a "l" and an "!" which might be ".'" Ugh You're welcome to try my new script (but you'd probably be the first to do so... Revalin is well trusted, and it's easy to see that his scripts aren't doing anything unexpected. Although my script is also viewable as just a text file, unless you're a Python programmer you'd be trusting me at least a little, some dude on the net you've never met...) Anyways, if you'd like to try it, download the scripts from here: btcrecover download. These are Python scripts, so you also need to install Python, instructions are here: Installation requirements for Bitcoin-qt wallets. You just need Python, the other two libraries are optional for Bitcoin-qt. Once the scripts file is unzipped, you'll need three files in the same folder as the btcrecover.py script: the wallet.dat file, a file (created with Notepad) named "token.txt" that just contains the password as best as you can tell, and another (Notepad) file that lists out which letters to try swapping for which others called "typos.txt" which should look something like this: This just means that wherever there's an 'r' in the original password, try it with both the original 'r' but also with a 't' instead, and so on (there's a space between those two letters in that file). Actually it might be better to do this: That way every 't' and every 'r' in the original is tried both as-is and swapped, and every '1', 'I', and 'l' is tried as-is and swapped with the other possibilities on the right, etc. Then you need open a command prompt and try something like this: cd c:\Downloads\btcrecover-directory
c:\Python27\python btcrecover.py --wallet wallet.dat --tokenlist token.txt --typos-map typos.txt --typos-capslock --typos-swap --typos-delete --typos 3
I added on three other types of checks (--typos-capslock --typos-swap --typos-delete); you can keep them, get rid of them if you don't think they'd help, or add other ones (complete list of different typos is here: different types of typos). Finally, that last option (--typos 3) is how many typos, at most, to try in any single guess. The higher it is, and the more of those different types of typos you add, the longer it will take... Good luck. |
|
|
|
So, I'm another guy who's lost his password... Luckily, I'm using Armory and I printed out my paper backups. Unluckily, I also lost my paper backups...  Luckily, I happen to have a background in software, so I went about making my own Revalin-style script. Unluckily, they didn't end up doing me any good. Luckily (maybe for someone else, anyways) I have a touch of OCD, so I kept playing around with my script, adding more and more stuff to it. It ended up being a good learning experience. Anyways, I'm at the point where it could be useful to someone else, so I've put it up on GitHub: https://github.com/gurnec/btcrecover. It's open source, written in Python so anyone can check it out and make sure it's not doing anything funky with your wallet file. There's a tutorial (link at the bottom of this post) to get you started. I really do hope it ends up being useful to someone, it would at least make me feel a little bit better
btcrecoverbtcrecover is an open source Bitcoin wallet password recovery tool. It is designed for the case where you already know most of your password, but need assistance in trying different possible combinations. Features- Bitcoin wallet support for:
- Armory
- Bitcoin Core
- MultiBit Classic
- Electrum
- Supported on Windows, Linux, and OS X
- Options to help minimize the search space - the more you remember about your password, the less time it will take to find
- Multithreaded searches, with user-selectable thread count
- Wildcard expansion
- Typo simulation
- Progress bar and ETA display (at the command line)
- Interrupt and Continue searches without losing progress
- Optional autosave - continue searches even after inadvertent interruptions or crashes
Please see TUTORIAL.md for more information, including installation instructions and requirements. |
|
|
|
|
Just a quick heads up for anyone out there who uses LastPass--
The new MtGox login page doesn't seem to work for me (at least on Chrome) if you have the LastPass extension installed and enabled (even if you're not logged in to LastPass). The only way I can log in is by disabling the extension completely.
Hope this helps someone...
-Chris
|
|
|
|
... on only one of the two cores of my 5970 ... should I downclock it a bit ? So you're the reason I can't mine any coin...  *jealously sulks off* |
|
|
|
...
to run the "reject other blocks" attack, as i understand it, i'll generate a block but keep it to myself, while continuing to work on generating a block that builds on top of my hidden block.
so, let's say that I generated a block. now, i have two choices. choice one - i release it to the network, and claim my 50btc, and start working on my second block, which i then later also release and claim my next 50 btc.
choice two - i keep it hidden, and work on generating another block building on top of my secret block, all the while the rest of the network is still toiling away on the first block. in order for me to make the network 'waste power', in other words, in order to be able to trash the rest-of-network's block, i need to be able to generate another block after the rest-of-network generates one block, but before the rest of the network generates two blocks.
...
In order to make the network 'waste power', you only need two things: - Keep at least one solved block to yourself for any amount of time, and
- somehow do you best to later get that block into the chain, even though you're not releasing it right away.
If you can accomplish both of these goals (the second goal being the difficult one), you slow down the rest of the network without slowing down your own processing power, and so you end up with relatively more processing power compared to the rest of the network. The attacks being discussed, as I understand them, ask the questions: - What if you release your hidden block as soon as the rest of the network releases its next block? There will be a race which you might be able to win, but how often and is it worth it?
- Same question, but is it possible to find a way (e.g. lots of connections to lots of other clients) to increase the chances that your just released block will get into the chain, and the competing block will not?
- If you happen by chance to get additional blocks ahead of the network (which is likely to happen on occasion), can you use this to further your advantage?
I'm not sure if question #2 has been answered, but if it is possible for a cartel to give itself a networking advantage, it appears to gain a mining advantage even if it's a not-so-big cartel. Even if #2 is not possible, ByteCoin has a simulation where #3 is regardless a problem (although you have to be a pretty big cartel to pull it off). |
|
|
|
If multiple solved blocks arrive within say 15 seconds of each other (for the same block number in the chain), instead of ignoring all but the first: - Use the block with the most accurate timestamp, and
- flood them all out to the network (so other clients can make their own decisions based on their own internal clocks).
This is more interesting to think of a way to stop this kind of attack through accurate time stampping. So far, the assumption is that coming up with an accurate authority for chronological accuracy (aka a "trusted" time authority) is an intractable problem for a peer to peer network. Bitcoin bypasses that entirely and at the moment mostly ignores the time stamp other than as a general "guide", and there have been some blocks already in the block chain created with timestamps that are before the previous block that it is supposedly following and hashed from. If there could be an accurate chronometer (within a 10 second or so accuracy) to verify a block and thus reject blocks "made" in the future or to reject sub-chains that include blocks with negative time differences, it would certainly help to stop or significantly restrict a cartel attack. The trick is to establish such a time stamping authority that could be recognized by a peer to peer network. Actually I was thinking that just using the local time on each client would be good enough, I wasn't assuming the existence of an accurate chronometer (although having such a source might be better). If all clients flood all competing blocks, than all clients will be able to make their own decision on which block is best (and they would build the chain off the best block, even as they continue to flood the competing blocks). Eventually, the network will converge on a decision that should include the block with the most "accurate" timestamp in the network's opinion. So as long as enough of the nodes have somewhat accurate clocks, the network as a whole can often make the correct choice. I have no idea how to actually test this theory though.... It might be interesting to monitor the network for new blocks, and compare the block-received time to the block timestamp, maybe this would result in some idea of how accurate or inaccurate the network machines are? |
|
|
|
I did a simulation of two cartel strategies along the lines of my previous post. I have assumed that the cartel does not have any superior ability to propagate its blocks across the network. If the cartel and the non-cartel miners publish a block at the same time I have assumed that they have an equal chance of being accepted by non-cartel miners. This therefore is a lower bound on the cartel attack effectiveness.
When the network generates a block, if the cartel has just one unpublished block then the best strategy seems to be to immediately publish the stored block and let the two race across the network.
If the cartel doesn't have any superior network connectivity, I'd think it would on average lose any race where it has just one unpublished block. By the time it knows it should try to publish it's one unpublished block, it along with some of the rest of the network will have already seen the Network's competing next block. I'm thinking having superior network connectivity is important for this type of attack to be lucrative... |
|
|
|
Did you simulate network connectivity at all? Bitcoin is a semi-randomly connected network, where most of the Not really, the sim was very simple. During a race between a cartel-generated block and a Network-generated block, the second sim I ran assumed that the network as a whole received the cartel block 85% of the time, and it received the network block the other 15%. This loss had a negative affect on the cartel, but not a huge one. I also assumed that the cartel only kept one solved block hidden from the network. As mentioned by ByteCoin and RHorning, the cartel could do better by keeping additional blocks hidden, and only releasing them when required to maintain control of the network's chain as much as possible, further improving the cartel's performance. |
|
|
|
...
Cartel maintains as many connections to other nodes as it can.
When the cartel finds a block it only tells the other cartel members.
When a non-cartel block is found, the cartel publishes the previously found block.
Since the cartel has many connections chances are > 50% of the network will accept the cartel block over the non-cartel block and thus the cartel block would become part of the main chain.
repeat
The cartel's advantage would be that the rest of the network would essentially be doing nothing during the time the cartel found a block till the time someone else finds a block. So the cartel would get a much larger % of blocks than it should.
...
I think this is really clever, and assuming you could get the required network connectivity to enough of the network, I can't see any reason this wouldn't work. I just spent longer than I'd like to admit trying to figure out how much of an advantage the cartel would receive, given ideal network connectivity. Apparently my math skills are not what they used to be... so I wrote a quick simulator instead. The only rule oddity in the simulator is: when the Network (all those who are not the cartel) solves a hash, it is not credited a mined block if the preceding block was mined by the cartel. (In this case, the cartel would use its superior network connectivity to "override" the network's newly mined block with the cartel's previously mined block). So in other words, I have something like: if (rand() < $p) { # if the cartel solves the next hash
$cartel++; # cartel gets credit for mining this block
$last = 'c';
} else {
$network++ unless $last eq 'c'; # network gets credit unless the cartel has "overridden" it
$last = 'n';
}
After running through 10M iterations of the above using different values of $p (the cartel's share of CPU power), I ended up with (assuming network conditions ideal to the cartel): Cartel's CPU control: Cartel's take of mined blocks 5%: 5.3% 10%: 11.0% 15%: 17.2% 20%: 23.8% 25%: 30.8% 30%: 38.0% 35%: 45.3% 40%: 52.6% 45%: 59.8% Of course, this was assuming that the cartel never fails in its attempt to "override" a block. What if the cartel fails to "override" say 15% of the blocks it potentially could have overridden (losing those blocks to the Network)? If I run this through a modified simulator the numbers look like: -- 15% "override" failure rate -- Cartel's CPU control: Cartel's take of mined blocks 5%: 4.5% 10%: 9.5% 15%: 15.0% 20%: 21.0% 25%: 27.3% 30%: 34.0% 35%: 40.9% 40%: 47.9% 45%: 54.9% After trying other failure rates, it turns out it's beneficial for the cartel to attempt this cheat as long as it controls a larger percent of the total CPU power than its predicted "override" failure rate (so at least 15% control in the example above). The numbers don't look too alarming to me personally, but I think there may be a simple fix (well, maybe not simple to code, I don't know...). We could use a heuristic in the client along the lines of: If multiple solved blocks arrive within say 15 seconds of each other (for the same block number in the chain), instead of ignoring all but the first: - Use the block with the most accurate timestamp, and
- flood them all out to the network (so other clients can make their own decisions based on their own internal clocks).
The cartel can't predict how long it would need to delay releasing its block, and so it can't predict what timestamp to add. It also can't change the timestamp after solving the block (I'm pretty sure the timestamp is part of the hash, is that true?). So... (wow this post turned out longer than I thought...) any thoughts? -Chris |
|
|
|
... $140,000 dollars required to control the network... still not prohibitory expensive.
Lets try and not get attacked until attacking the network costs at least 50% of the economy. ~ $500,000 or ~ 350GHash/sec
Although this sounds disturbing, keep in mind that "controlling" the network doesn't mean you can steal BTC from people. It does mean you can probably prevent others from generating blocks, probably block any particular transaction from going through, and probably double-spend BTC (if given enough time). So for example if you could sell 140k USD worth of your BTC, you could go back and double-spend it, and end up with a profit after the 140k expenditure required to control the network. Of course doing this in practice without anyone noticing seems just about impossible, so there's not much incentive to try... I believe it remains more profitable to just use all that hardware to mine. Edited to add-- this ignores other practical problems, such as: (1) nobody currently has control of 140k USD worth of BTC; (2) moving any significant amount of BTC would also move the markets, such that trying to sell 500k BTC would result in considerably less USD (or whatever other currency) than the current market price; I'm sure there's more I can't think of... |
|
|
|
Here's how I'm interpreting your attack, can you let me know if I got it right? The mining cartel could follow this rule: If the most recently generated block was generated by the cartel, mine normally. Otherwise, fork the chain, ignoring the most recent block, and begin mining from the previous block instead. So if the most recent block, say #100, wasn't generated by the cartel, we have: | "Main" chain | "Cartel" chain | | Block #1 | Block #1 | | ... | ... | | Block #99 | Block #99 | | Block #100 | Current work block | | Current work block | |
In order to make Block #100 "disappear" from the Main chain, the Cartel must - Generate 2 blocks before Main network can generate 1, or
- Generate 3 blocks before Main network can generate 2, or
- Generate 4 blocks before Main network can generate 3, or
- ...
This is the only way the Cartel could create a chain longer than the Main chain and therefore "override" the Main chain, and would seem to require > 50% of the total network's CPU power to consistently succeed. However, you're suggesting: what if the goal weren't to consistently succeed, but rather only to occasionally succeed? Occasionally a Cartel with a sufficiently high percentage of CPU power (but still less than 50%) would succeed in this by chance. So the questions in my mind are: - Given some percentage control of CPU power, what percent of blocks could a Cartel make disappear? Or alternatively, at what percentage control of CPU power would this attack become feasible?
- What incentive would such a Cartel have (you've already gone into this)?
- What negative affects could this have on legitimate users (again, you've talked about this already)?
By using such a method, the Cartel would not be able to generate more coin for itself (from an absolute point of view). However you point out that since it is disappearing other miners' coin, it would end up with a higher percentage of the total coin generated by the network. However, some of the time (most of the time I think?) that the Cartel forks the chain, it will not be able to catch up to the Main chain. After a certain amount of time spent trying to catch up to the Main chain, the Main chain would be so far ahead that the Cartel must choose to give up, and return to step one (start a new fork). When it does this, all the CPU it's spent trying to catch up, and all of the BTC mined in the process, would be lost. So the last question I have is: - Do the gains of (potentially) creating a greater % of the total BTC outweigh the losses incurred when the Cartel has to give up and start over?
Having not done (and probably being incapable of doing) any real math analysis here, I'm going to go out on a limb and say I don't think the gains are worth the losses.... Or I very well could be missing something here? -Chris |
|
|
|
I've run into this using the latest (20101126) miner executable under windows. I've also seen it once before using an earlier version, I believe 20101102. The miner seems to run fine for a while, and then this error comes up, and the miner exits. Any thoughts? Anything about my setup I can provide to help? sys:1: DeprecationWarning: struct integer overflow masking is deprecated
Traceback (most recent call last):
File "poclbm.py", line 140, in <module>
File "pyopencl\__init__.pyc", line 205, in kernel_call
OverflowError: long int too large to convert P.S. m0mchil, I can't find a donation address for you... if you had one in your sig, it would be much easier to bribe you for support |
|
|
|
As a thought experiment, imagine the "scratch off" lottery tickets. You can't see the receiving key until you scratch it, which makes it visibly void. A drawer full of these ought to alert the shift manager than an employee isn't following SOP. Now that's an idea, but it would still become void for the purpose of futher trade should anyone, honestly or not, scratch off the hidden zone to get to the private key. But so long as each person continued to trust that the bitcoins behind the visable address, something checkable, there might not be any reason to scratch off the hidden portion of the note in order to claim the bitcoins themselves. Eventually, however, someone will do so in order to buy something online, so the "lifespan" of such a note is still limited. But it would certainly be as anonymous as cash, and never require that any person along the chain of trade walk into any kind of bank to redeem them. Something to consider. I wonder how much it costs to print something like that. I really like this idea. It turns out you can buy clear stickers with scratch-off material applied to the top fairly cheaply. A quick search turned up these, which are 1.5 x 2 inches, and cost between 5 and 8 cents each, depending on qty: http://www.easyscratchoffs.com/rectangle-scratch-off-stickers.htmlI wonder how big an area would be needed to print a private key in a 2d barcode of some sort? |
|
|
|
|
Show Posts
