Looks like there was bitcoin left in the address he published the private key for until about 30 minutes ago. I hope that was a deliberate giveaway.
https://blockchain.info/tx/2685ff794de17cebdf94eb0f111e8b8c0...
A peek under Bitcoin’s hood: Writing a client that can create a transaction
21–30 of 67 posts
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#22>> 0xFACEBEEF and sent it 0.0005 BTC.. 1 month later and someone had stolen my 0.0005 BTC! I guess people must occasionally trawl through addresses with simple/common private keys. This made it worth reading the article. Such cyberpunk!
For fun[1], you can occasionally trawl through addresses with any private key!
[1] For various definitions of "fun."
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#23Earlier quoted context omitted.
Bitcoin addresses are basically a public key, so you can generate them offline the same way you can generate pgp keys, openssl keys, SSH keys you use to access GitHub etc. The chances of a collision are so astronomically low that our sun will probably run out of fuel and explode before two identical keys are generated.
With the comfort of a public blockchain at hand why not eliminate this case at address-creation time?
Not worth the effort. You could absolutely make a wallet that does this, but you'd have to either do a lookup with a trusted third party, or keep around a bloom filter of used addresses to query against (probably about a gigabyte). We're talking about "winning a lottery jackpot several times in a row" odds.
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#24Hi Sam, If you're reading the comments, can you do this treatment but for Ethereum and the smart contracts built on top of it? I find that your article gives a good explanation especially for beginner to understand from the code perspective.
FWIW, I was looking at eth code in the weekend and it's pretty accessible (I was looking at go -- I've read that eth python should be even more readable). The address part is very similar, even simpler, than bitcoin. It's the same elliptic curve, same way to build private/public keys. For the address, it uses a different hash function, Keccak256, and then it's just serialized in hex. Code here [1]. Pointers to key ge…
Keccak256? Isn't that just SHA3 with a digest of 256 bits?
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#25I am actually really surprised it took a month for someone to swipe the BTC he sent to an address with a private key of 0xfacebeef. That could be found via an incremental search in under an hour of CPU search time on one computer. I note that compressed public keys are not being used in these examples - it's highly recommended to use them, since they reduce transaction size and cost. Regarding weak keys - there have…
Just a warning for people, I was playing around with BTC the other day and not generating random entropy from urandom, just putting in a short string.
I found my BTC was stolen immediately when I did this. It wasn't a lot of coins, since I was just testing, but it certainly cost me some debugging time as I wondered how the extra transaction had occurred.
Basically, someone out there has already generated the keys corresponding to short strings and is keeping an eye on any transactions on them. Maybe more than one group, who knows?
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#26Can someone explain why bitcoin adresses can be created (offline) without blockchain-validation for duplicates? Even if the chances are very small I mean...like....gone is gone...no bank to call for a false transaction.
Consider that if you do find a collision, you would be able to take any bitcoin outstanding to said address on the blockchain.
Framed this way, you can see that in fact if your defensiveness is necessary, addresses would be extremely unsafe against targeted attack.
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#27Article says > This is also why address reuse in Bitcoin is encouraged as to sign a transaction you need to reveal your public key. If you don't reuse an address after sending a transaction from the address, you don't need worry about the private key of that address being exposed. Shouldn't that say "address reuse in Bitcoin is discouraged "? Otherwise I don't think I understand what he's trying to say.
Address reuse only becomes a problem in the theoretical case that someone can determine the private key from a signature. This would only happen if there was some sort of breakthrough in cryptoanalysis of elliptic curve cryptography, which while theoretically possible, is unlikely.
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#28Article says > This is also why address reuse in Bitcoin is encouraged as to sign a transaction you need to reveal your public key. If you don't reuse an address after sending a transaction from the address, you don't need worry about the private key of that address being exposed. Shouldn't that say "address reuse in Bitcoin is discouraged "? Otherwise I don't think I understand what he's trying to say.
It should say This is also why address reuse in Bitcoin is "discouraged" as to sign a transaction you need to reveal your public key. If you don't reuse an address after sending a transaction from the address, you don't need worry about the "public key" of that address being exposed
The reason being without revealing public key, with only the bitcoin address the attacker first need to guess the public key from the address, then guess the private key from there. So just breaking one of the hash algorithm or ecdsa algorithm is not enough to steal funds. at least that's in theory, in reality if either algorithm is broken we have a much bigger problem.
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#29I am actually really surprised it took a month for someone to swipe the BTC he sent to an address with a private key of 0xfacebeef. That could be found via an incremental search in under an hour of CPU search time on one computer. I note that compressed public keys are not being used in these examples - it's highly recommended to use them, since they reduce transaction size and cost. Regarding weak keys - there have…
Just a warning for people, I was playing around with BTC the other day and not generating random entropy from urandom, just putting in a short string. I found my BTC was stolen immediately when I did this. It wasn't a lot of coins, since I was just testing, but it certainly cost me some debugging time as I wondered how the extra transaction had occurred. Basically, someone out there has already generated the keys cor…
There are many of us with bots sweeping weak keys. Some of us give the coins back to a safe address, some people just keep it. It's like finding money on the sidewalk.
Re: A peek under Bitcoin’s hood: Writing a client that can create a transaction
#30Earlier quoted context omitted.
FWIW, I was looking at eth code in the weekend and it's pretty accessible (I was looking at go -- I've read that eth python should be even more readable). The address part is very similar, even simpler, than bitcoin. It's the same elliptic curve, same way to build private/public keys. For the address, it uses a different hash function, Keccak256, and then it's just serialized in hex. Code here [1]. Pointers to key ge…
Keccak256? Isn't that just SHA3 with a digest of 256 bits?
I'm unsure. I think this came before sha3 was defined so some parameters may have changed. But the core is essentially that.