Bidding 0.015 BTC

Selling a hard drive I had lost back in 2011 which had a few thousand bitcoins (not sure how much, I'd estimate 3000, definitely more than 1000). The wallet is not encrypted but the hard drive itself (My Passport 1 TB) is encrypted with a password which I for the life of me cannot remember. I know it has 10 characters exactly but that's about it, and it's not feasible for me to bruteforce.

Starting price: 0.03 BTC
Increments: 0.005 BTC
Buy now: 1 BTC

Thank you, that's some good advice. Will be keeping that in mind. I've already received quite a few PMs offering help and asking to purchase the drive!! Not selling for $50, haha... I will contact Dave.

It's been a while since I've been a part of the bitcoin project. Got extremely bitter after Gox collapsed since I had 90% of my holdings on there. After a recent attic cleaning, I found my old drive, which is supposed to have the other 10% (I believe it was in the thousands of bitcoins, definitely more than one thousand, not exactly sure). I tried every possible password combination I could remember, but it didn't work. The only thing I know for sure is that the password is 10 characters long.

This isn't feasible for me to bruteforce on my home computer, so I was wondering if anybody has experience with smarter algorithms that would be able to decode my wallet passphrase in a shorter amount of time (I'm hoping within a week or so). I've been in a financial crunch recently, and to be honest, had mostly forgotten about cryptocurrencies, so finding my old drive was a very welcome surprise. Feels good to be back in the game. Also, if anyone has contacts with some good wallet recoverers, please let me know, and I will do my best to arrange for an in-person meeting.

And BTW, in most financial calculations you don't want to perform operations to infinite precision.

What you want is to have predictable results that do not depend on the environment used to compile and/or run the application.

Great!


It's exact for additions and subtractions (of values that were never divided).

If you divide one value by another, and now you add the result multiple times, you will likely obtain different results than if you had used fixed-point arithmetic (unless it was an exact division).

This can lead to results that are unexpected. It may also lead to different results depending on how the compiler optimized your code (e.g. whether it used SSE2 or the FPU), the architecture you're using, etc.


It's not as obvious and simple as you seem to imply, as I just proved to you.

The code is also non-portable because the 'double' type in C++ is not required to have 64 bits, in fact it can have only 32 bits which is obviously not enough to represent all bitcoin values (not even close).
The size of double does not only depend on the architecture and compiler that you are using, but also on the compilation flags.
The double type is only required to not be smaller than float.

Not to mention that the C++ standard allows the 'double' type to have only 4 bytes.... sigh 

If you're representing "things" as integer nanocoins, then why don't you use an integer type?!

An uint64 would work just fine!!

UINT64_MAX = 18446744073709551615
BITCOIN_MAX = 21000000 * 10^ 8 = 2100000000000000

BITCOIN_MAX < INT64_MAX

So you want to do that just because you like to get yourself into trouble?

Do you know what optimizations the compiler is allowed to do in intermediate values of floating point calculations?

Do you know that certain compilation flags affect the precision of the results (downwards or upwards)?

Do you know that when you enable some optimizations in some compilers, they don't follow the standards?
Such as when you use -fast with the Sun Studio compiler or -ffast-math in gcc?

Do you know that many Linux Gentoo users use -ffast-math by default?

Also, I didn't see any place in the code where "integer nanocoins" are represented as floating point values (granted, I only read a fraction of the code). What I saw was integer nanocoins being used as integers, and floating point bitcoins being used in floating point variables...

Please, just use integer (i.e. fixed point) arithmetic for financial data and stop writing shoddy code. It's a no brainer, really...

Yes, v0.3.22.

Can we stop with this nonsense?

+    if (params[0].get_real() != 0.0)
+        nAmount = AmountFromValue(params[0]);        // rejects 0.0 amounts


          if (strMethod == "sendtoaddress"          && n > 1) ConvertTo<double>(params[1]);
+        if (strMethod == "settxfee"               && n > 0) ConvertTo<double>(params[0]);


Please learn to use fixed-point arithmetic, people... this is not a pet project anymore, it's a financial application that at the moment holds $181 million USD worth of people's savings.

I think you might need a lesson on how floating point works.
In short, results of rounding, calculations and comparisons may vary depending on compiler, optimizations, or architecture used.
Furthermore, there are other non-obvious semantics, such as negative zeros, infinities, NaNs, etc.

I know in this case the comparison with 0.0 is probably not problematic, but for instance, you don't want someone to send a transaction of 0.12345678 bitcoins and then due to rounding conversions you actually send 0.12345679 bitcoins instead. Or someone to set a transaction fee of 0.2 and instead it gets set to 0.19999999.

It is NOT acceptable for financial applications to use floating point numbers to represent monetary values.
Governments have strict regulations against this for banks, for obvious reasons.

Please, please avoid using floating point arithmetic and educate yourselves why you should do that.

For example, there's a reason why Satoshi avoided floating point calculations in many places (e.g. difficulty calculations... you really don't want different machines having a different concept of what the difficulty is).

What you really want is to convert strings directly to fixed-point numbers (probably with BigDecimals if uint64 is not enough for 21,000,000*10^8 individual units) and vice-versa.
Always do calculations, comparisons and range checks with fixed-point arithmetic.

http://objectopia.com/2009/07/03/stop-using-floating-poin/
http://programmers.stackexchange.com/questions/62948/what-can-be-done-to-programming-languages-to-avoid-floating-point-pitfalls
http://www.theregister.co.uk/2006/08/12/floating_point_approximation/
http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf

... and so on and on...

Same advice goes for the code of any website that deals with bitcoins (MtGox and mining pools come to mind...).