Basically an SHA256 value for any given input is unpredictable so trying to find a result like this one (note the zeros at the start) 00000000916dd8861312f2cd94ac01310e15541e58df57d988f058eb3adcbf15
is not something that you can guess how to find quickly (it all depends upon the input string and how SHA256 mangles that data into a hash). In Bitcoin's case the # of leading zeros is what is termed the "difficulty" and each miner creates a block header and then hashes this with a random number in order to find a hash with enough leading zeros (according to the current difficulty level). Because there is no way to cheat to determine which random number will work you have to keep trying different numbers until you find one that does (thus the "proof of work"). HTH |
|
|
|
Not sure how you missed this but: [main.h]
...
static const int64 COIN = 100000000;
...
static const int64 MAX_MONEY = 21000000 * COIN;
to find such symbols (assuming they are in .h files) simply: |
|
|
|
Oops - must have an old link - thanks - works fine now (did enjoy the error screen though).  |
|
|
|
Hmm... for some reason I am only seeing the following:   |
|
|
|
I have two backups one encrypted (after encryption) and one without encryption (after creation)
Okay - if you had issued tx's *after* you encrypted the wallet then the chances are very slim that the backup of the unencrypted wallet will be of any use (this has happened to others). So assuming that you using the backup of the encrypted wallet and that no errors are occurring you might need to run bitcoin with the -rescan option. |
|
|
|
|
My advice would be to at least consider using a second OS (preferably non-windows) for generating your private keys that is never connected to the internet.
You could then consider dividing your 100/200 btc into 10/20 separate addresses (generated by say "vanitygen") on the non-internet computer and use a USB flash drive (that is brand new) to move private keys to your connected PC as required,
|
|
|
|
Of course, MD5 is a sequential algorithm. So if MD5(t1)=MD5(t2), then also MD5(t1+x)=MD5(t2+x) for any random data x. Whereas MD5(x+t1)≠MD5(x+t2).
I think the same holds for Sha1 and Sha2 (including Sha256), however no Sha1 or Sha2 collisions are known.
I guessed so (but lack the mathematical skills to know for sure) - the idea was to change the "double hashing" approach so that even if collisions can be found it won't help (unless you can work out collisions that satisfy the "appended double hash" approach which I assume must be much more difficult). |
|
|
|
|
Certainly I am not meaning to suggest that your software has been designed to be nefarious but I am really hoping that you might consider moving from closed source software to an open source model and consider that there are other ways to make money from software development.
My upcoming open source project may in fact be of help to you for this project (and others like it) so PM me if you are interested to know more.
Cheers,
Ian.
|
|
|
|
|
If it is not open source then I suggest that no-one playing with it should put anything such as a password or an API user key into it unless they want to risk losing their BTC (sorry but that is just basic safety precaution).
|
|
|
|
|
What errors (if any) are you seeing (and was your wallet encrypted)?
|
|
|
|
oh, holy shit... I'm sorry!
No worries - initially I thought they looked the same as well (and ran a diff against them to be sure they were not). |
|
|
|
These ones (found them doing a search for the shortest MD5 collision): [t1 - in hex]
d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f89
55ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5b
d8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70
[t2 - in hex]
d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f89
55ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5b
d8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70 so t1 = t2. doesn't suprise that anyfunc(t1) = anyfunc(t2), right? that's not a collision. for a collision t1 != t2 and func(t1) = func(t2) must be true. If you look even more closely you'll see there are other differences also. |
|
|
|
For what values of t1 and t2?
These ones (found them doing a search for the shortest MD5 collision): [t1 - in hex]
d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f89
55ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5b
d8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70
[t2 - in hex]
d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f89
55ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5b
d8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70
|
|
|
|
as long as you can put in a certain 128 byte block at the end that is aligned on a 64-byte boundary (as far as I understand).
I think you mean at the beginning because when I tried MD5(t1+MD5(t1)) it produced the same hash as MD5(t2+MD5(t2)). |
|
|
|
@CIYAM Pty. Ltd. if its so easy, why arnt u creating a little wrapper (best in C so u can directly patch bitcoind with it  ) for it? Altough i have to say i didnt check this function out yet, maybe its really that easy. Unfortunately I have very little time to spend on anything but my own project (working 7 days a week with very little time off in the last couple of years). The "coin control" patch (as it is) in fact is not actually functional enough for what I need (as I need to control the "change" address which it doesn't do). This is why I had a look into the raw tx API stuff. It is quite complex but if you play with brainwallet.org's web page then it looks as though you can put together a raw tx fairly easily (which by default sends the change back to the first input address which happens to be the exact behaviour that I am after). |
|
|
|
You would basically have to write an advanced script or a frontend for bitcoind which would use this feature.
Anyway, it's complicated, not everybody has time for this and you don't have certanity that you did it properly. I would probably write my own script if that was easy enough.
Actually if you use brainwallet.org to do this it seems pretty straight forward - I will update when I've tested some tx's with it (will be doing this in the next few days). |
|
|
|
Even if that is possible, it will be far more convenient (and less time consuming) if it would be integrated in the mainline client.
Well I am pretty sure I will be playing around with the raw tx stuff soon (probably using brainwallet.org to make it easier). So hopefully I'll have something positive to report about using it down the track. |
|
|
|
* WKWTAD people = People Who Know What They Are Doing
And those people can't use the raw tx API (even with the help of brainwallet.org)? |
|
|
|
For the more technically savvy the raw tx API (perhaps with help from brainwallet.org) reduces the priority of this feature a lot (as you have been able to do everything you want as far as controlling your coins since 0.7 was released). For the less technically competent I guess the question is really whether the UI can be made easy enough to make the feature worthwhile implementing (if it's not easily understood then there is probably little point in doing more work on this). Note that I haven't actually tested the patch so have no idea how intuitive the UI is. Certainly I doubt it will ever be a feature that Gavin's grandmother will be asking for. |
|
|
|
|
Show Posts
