Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

blockchain.com

Post reply on HN
Print view View original

401–410 of 428 posts

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#401

Post by Dylan16807 »

keepamovin wrote: post #378
orf wrote: post #362

Earlier quoted context omitted.

Assuming no duplicates, the only case that would make sense would be if all but a single byte was different (sequentially across all records). Even then you’d end up with more than the number of bytes we’re talking about, even excluding the size of the index (which would be non-trivial).

Why don’t you just read what the guy said by following the links in the forum? Surely, you can find more explanation there that will answer some of your questions? Hahaha! :)

His thing has collisions, so it answers none of the questions.

Also they already did follow the link. That's why they said "they don’t actually store the keys, so the quote is misleading", which you responded to with a laugh and nothing else. And that happened many hours before you made this new comment.

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#402

Post by Dylan16807 »

y42 wrote: post #399
Dylan16807 wrote: post #397

Earlier quoted context omitted.

What do you mean by previous bits? Where are you seeing how "everyone is crawling"? With each puzzle, you know that the top bit is 1, and nothing else. Every bit below that is unknown, and you need to go through the whole range of n-1 bits. Puzzle #10 has 9 bits to guess, because it's between 10_0000_0000 and 11_1111_1111. Puzzle #66 has 65 bits to guess. If someone says 66 unknown bits they've misspoken.

yeah, thats what i meant, just to make clear "how" I am thinking it: It's just iterating through integers from n to k and calculating secp256k1, sha-256 and ripemd. So: >> Puzzle #10 has 9 bits to guess, because it's between 10_0000_0000 and 11_1111_1111 means that I don't have to start at 0000 0000 0000 ... everytime, I can actually start at 2^5 and look up to 2^6 - 1, for example for the 6th address.

But show me someone that's starting at zero? You said it "seems like everyone" is doing that. Where?

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#403

Post by commodoreboxer »

kelnos wrote: post #113
commodoreboxer wrote: post #53

Earlier quoted context omitted.

We can and do, all the time. And all puzzles are a "waste of resources", really. I'm not into crypto and I do think Bitcoin is stupid and wasteful, but I don't find it "sick" or all what upsetting that this kind of puzzle exists, though I think some smart contract-based Ethereum puzzles could be much more interesting, demanding solutions to more interesting problems that don't directly relate to the blockchain itself…

This isn't really a puzzle, though. A puzzle requires intellectual curiosity and creativity to solve. This was just a race to see who could burn the most CPU/GPU cycles the fastest. Even when a real puzzle has a monetary reward for solving it, a big component of the reward is the solving itself. For this, the reward is just money.

I agree with you. I think it's a bit wasteful and dumb, I just don't find it either sick or confusing.

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#405

Post by orf »

Dylan16807 wrote: post #400
orf wrote: post #337

Earlier quoted context omitted.

How could this work with less than 1 bit of data per key? Assuming there are no duplicates, which is a sensible assumption, you’d need a minimum of 100,000,000 bits to store 100,000,000 unique entries larger than 1 bit with even a perfect hash function.

In general, when you're storing a list of numbers, there are many situations where you can go below 1 bit per number. The easiest one to think about is storing the deltas between each number. Let's say 80% of your deltas are 5. If you use arithmetic encoding, then storing a 5 only takes about 1/3 of a bit. It's not hard to come up with probability distributions where the average amount of bits per entry is less than…

Thank you for taking the time to explain this - it makes sense, and it’s interesting to invert the problem by storing missing numbers.

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#406

Post by keepamovin »

Dylan16807 wrote: post #401
keepamovin wrote: post #378

Earlier quoted context omitted.

Why don’t you just read what the guy said by following the links in the forum? Surely, you can find more explanation there that will answer some of your questions? Hahaha! :)

His thing has collisions, so it answers none of the questions. Also they already did follow the link. That's why they said "they don’t actually store the keys, so the quote is misleading", which you responded to with a laugh and nothing else. And that happened many hours before you made this new comment.

Heh, yeah. "Store" can have multiple meanings.

I'm not sure that guy really understood what was going on. If he'd followed the links he would've found the code. Or at least a technical description. So why need to play dumb and ask here, while trying to control the discussion?

I don't like that kind of thing. If you're okay with it, alright. But that's not me.

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#408

Post by rtkwe »

the_clarence wrote: post #372
rtkwe wrote: post #354

Earlier quoted context omitted.

The exact details are beyond me but knowing the public key cuts the required private keys you need to test in half. Public keys are included in the transaction but normal keys have enough bits they're effectively protected even with their raw entropy cut in half. 128 bits are still more than you can effectively brute force but the 33 bits left for this challenge is far easier which let the attacker snipe the reward b…

Half of 2^66 is 2^65

I meant the entropy in bits is cut by half.

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#409

Post by AlexCoventry »

AnotherGoodName wrote: post #330
GTP wrote: post #256

Earlier quoted context omitted.

Technically, while the two problems share the same name, the one on elliptic curves is matematically different from the one over finite fields modulo a prime number.

I politely don’t understand this. It’s taught in cryptography 101 that breaking ecc is just solving the discrete logarithm problem and there’s a ton of online articles about how to break ecc if you’ve solved the discrete logarithm problem (not that anyone has).

There's a family of discrete logarithm problems, one for each representation of a group. (Where I mean "representation" in the usual sense, not the precise mathematical one. It's an important distinction because the secp256k1 group, for instance, is isomorphic to all cyclic groups of the same order, but the discrete logarithm problem on secp256k1 is harder than the additive group on Z/Z, because the isomorphism is computationally intractable.) So there isn't simply one monolithic discrete logarithm problem.

Re: Bitcoin puzzle #66 was solved: 6.6 BTC (~$400k) withdrawn

#410

Post by [deleted] »

fernandopj wrote: post #148
mrb wrote: post #136

Earlier quoted context omitted.

No private key was posted too early. What happened is the person who spent all the computing power to brute force the 66 bits broadcasted, naively, a transaction to send the 6.6 BTC reward to his wallet. However, when doing so, the public key is by design revealed on the blockchain. Someone's bot whose sole purpose is to steal this puzzles rewards was monitoring the blockchain and spotted the transaction before it go…

But how could he have avoided this attack? I'm only familiar with Bitcoin's blockchain on a begginner level. But I assume the only way would be to avoid revealing the answer key (public) when sending the transaction to get the reward?

[deleted]
Post reply on HN