Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If the real puzzle solver didn't see this coming, he kinda does deserve it. Bitcoin blocks takes 10-20 minutes to confirm. This leaves enough time for a bot/human to take over. I am pretty sure he could have contacted a miner/pool and arranged a deal with them.


How could a bot/human steal the funds without knowing the private key?

Edit: typo


Ok there is one good explanation for this case that I found in another comment here [0]: the person who found the private key made a transaction moving only part of the full reward, but in doing so exposed the full public key. A was monitoring the puzzle address for activity, picked up the public key, used it to crack the private key quickly and moved the rest of the funds.

Fascinating that the original cracker wouldn't know these details about Bitcoin transactions.

[0] https://news.ycombinator.com/user?id=mrb


You can't derive an secp256k1 privkey from the associated pubkey. That's the whole point.


You are right in the general case. But the public key is included in a transaction when it gets signed, and in this particular case the attackers already had part of the private key, that's what allowed a different attacker to combine both pieces and break the private key quickly.


I am not sure about this one but for the other puzzles, the solution is usually hashed and the submitter has to provide the solution in the Bitcoin script to solve for the hash. This disclose the solution (and thus the private key). This is not the case for signed Bitcoin transactions but these have special script functions. So if you don't use those, you lose these protections.


Can you explain that? So the real puzzle solver could have theoretically triggered the transaction, but lurking bots are stealing the transaction from them?


> https://news.ycombinator.com/item?id=41555482

I'll try to give a brief here about how Bitcoin script works but you'd better read up on the Bitcoin wiki.

Essentially, to make a transaction valid, your script needs to pass.

1. <PubKey> + <Signature> -> This is how most transactions are handled. You provide the transaction with a signature. This doesn't expose your private key and lock the receiver. (as the receiver is signed)

2. <Hash> + <Hashed Content> -> To solve for Hash, you need to provide the Hash Content essentially solving the puzzle. Problem is, if you provide the Hashed Content publicly in the Script, anyone can also submit a competing transaction and set himself as the receiver.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: