Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 260. (Read 192467 times)

Since I had a bit of time on my hands (and I wanted to try my hand at writing a program to generate bitcoin addresses from private keys), I put together a C program that attempts to brute force as many of these addresses as it can.

The program starts with a private key of 2⁰-1 and then increments private keys until it finds the first address.
Then it skips to 2¹-1 and increments private keys until it finds the second address.
Then it skips to 2²-1 and increments private keys until it finds the third address.
Then it skips to 2³-1 and increments private keys until it finds the fourth address.
And so on until it gets to the 51st address.

It's been running for a maybe a half hour now and I've gotten all the private keys through the 24th address (1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7)

I expect each additional address to take twice as long as the previous address, so I doubt I'll get to 50 (or even 35) addresses the way the program is currently written.  I'll need to optimize it more if I can find the time.

Possible speed improvements (placing these here as a reminder to myself):
Instead of computing the full address, I should convert each target address to its binary RIPEMD160 hash value. Then when checking private keys, I don't need to add the version byte, compute the checksum, and convert to base58.  Since I'm currently doing that for every private key that I attempt, I suspect that I'd get a significant performance improvement.

Instead of attempting the private keys in order, I wonder if it would be better to first try every binary combination where half the digits are zeros, then every binary combination where half+1 of the digits are zeros, then every binary combination where half-1 of the digits are zeros, then every binary combination where half+2 of the digits are zeros, then every binary combination where half-2 of the digits are zeros, and so on.  This shouldn't make things any slower, but depending on how the private keys were chosen in the first place, it may result in a performance improvement.

Clean up the code, and strip out all the unnecessary functions.  The program was first written as a generic utility that accepted a single private key as a command line argument and wrote the resulting bitcoin address to stdout.  Then I butchered the program into something that could attempt to brute force these addresses. The idea was first just to see how fast or slow it would be without any improvements.  Now that I've got a feel for it, there's a lot of old code that either isn't being used or is not handling the process efficiently.

Any day now I should be able to open what I downloaded. Hope there's eggnog inside for my efforts.

Please stay focused. I'm refreshing the Marshal Long thread every few minutes

That is why everyone calls you Gleb "Gullible" Gamow

Why the fuck am I now downloading http://www.sagemath.org/ ?

But still, so often more than one address is claimed at the same time. So either there is some system behind, or somebody is lazy and claiming them in bundles after he get more adresses.

Maybe just bruteforcing considering if you use modifed oclvanitygen and get probably 5 million tries per second with one or two GPUs it takes depth 50 with 562,949,953,421,312 possibilites to check all (as worst case) in 3 and half years.

Seems lazy bruteforcer claiming few adresses at once to me - but risky move considering anybody other could bruteforce and empty the address although the lazy one had the priv key stored! Obviously he does not give these Bitcoins much value and he is bruteforcing just for the challenge.

I just checked this more closely, looks like we are back to step 0.

That pastebin entry are inputs/outputs of an application called sage, I actually downloaded it and was playing around with it.

For those interested: http://www.sagemath.org/

Problem is, that this just proves that there is no mathematical formula behind the sequence.

You can see in the first part, he placed already the sequence in the inputs:

R=PolynomialRing(QQ,'x')                                
sage: f = R.lagrange_polynomial([(0,1),(1,3),(2,7),(3,8),(4,21),(5,49),(6,76),(7,224),(8,467),(9,514),(10,1155),(11,2683),(12,5216),(13,10544),(14,26867),(15,51510)]);

Those values were placed in the variable f.

Then he asked for the output of f, and sage returned the formula based on those actual fixed values:


When this formula is applied for the rest of the sequence that is not part of the inputs, it spits out nothing of value.

Apparently it just proves that there is no formula behind this sequence, at least using the Polynomial Ring model.

This was probably a test done by someone in the past that already realized this transaction in the blockchain, but the test failed.

So basically we are back to the one and only brute force impossible option.  

How are you calculating that formula?

I just did a simple app to calculate that and I get completely different results:


Results:


 

Am I getting something wrong?

The answers where you start getting the negative variables, why not just invert its polarity??

Funny thing, I've searched for the sequence and found this too.

That "interview" excuse is so lame. Personally, I would've said, "I was fucking this crack whore when outta the blue she asked me if..."

This thread started 2 days ago (on December 28), so looks like that guy posted there after reading this thread.

I find funny his excuse... "an interview" 

http://webcache.googleusercontent.com/search?q=cache:eyTz1uovmGkJ:pastebin.com/erN0F1ce+&cd=3&hl=en&ct=clnk&gl=us


How close am I? I'm pretty sure parsley = -1514935  

EDIT: I see somebody already found it: https://bitcointalksearch.org/topic/m.13401879 I guess it's not potato clock then. 

http://webcache.googleusercontent.com/search?q=cache:jpD-kGY5IRwJ:mathematica.stackexchange.com/questions/102967/forumla-producing-the-sequence-of-1-3-7-8-21-49-76-224+&cd=7&hl=en&ct=clnk&gl=us


Amazingly, some dude probably not a Bitcoiner  was seeking the same thing the OP was only a couple days ago. What are the odds?

Just figured out that the formula i have previously posted is missing a +1. if you post x = 0, then 1 comes out. Otherwise the formula would not be correct.

Every now and then I regret not attending college, like when reading this post and skimming over this video: https://www.youtube.com/watch?v=iB3HcPgm_FI

Many a times in our one room home (I have 5 siblings) my mom would make me turn off the light and go to bed at one in the morning while I was teaching myself calculus because it wasn't offered at the school I attended, but even if it was, I would've been reading the text months ahead of the class like I did in them classes that taught about shapes and things, and in the class that dealt with letters like a, b, c, x, y, etc., and sometimes foreign symbols which I think were Greek letters. Come to think of it, I think them Greek letter thingies were mostly taught in that shapes and things class. Or was it that other class that had to with stars and things. Or was it the class that taught me about moles. Or was it that class about copper wires making light bulbs light. Whatever it was, I aced them all... for funsies. That was the extent of my nerddom back in the mid-70's. Good times! Thanks to the advent of Bitcoin et al. I'm now able to revisit them years thanks to accidentally stumbling upon this space in mid-2011... or was it 2009 like when Marshall Long and Leroy Fodor falsely claimed to start their foray into Bitcoin?

The only thing that makes me think there might be something to this is the "burst" of claims after a long delay.  This indicates that the person was able to claim #47 - #50 in short order, possibly by finding a polynomial fit.

Thanks for the explanation! Good to know that bitcoin uses an encryption curve that was not designed by the NSA. Also feels good that bitcoin is one of the only ones to use this method, as it gives less incentive for hackers to try and crack the cryptography (would be worth more if you hack a bank right?).

Back to the puzzle: Nice find tyz, looks like it is less random than we thought a bit before. It's getting interesting now, I'll take another crack at it

Sounds like overfitting to me. Its easy to find a function with x+1 terms to match x points exactly. 2 points define a line (a*x¹+b*x⁰), 3 points define a function of leading coefficient x², etc.

Very nice finding tyz, this gives us some hope that this puzzle will still be solved during our lifetime 

Yes the problem are those divisions like -673909/1307674368000, not sure whats the formula behind this, will have a look on it.