A peek under Bitcoin’s hood: Writing a client that can create a transaction (opens in new tab)

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.

Address reuse is most certainly discouraged from a security standpoint! I expect that you are correct as to the article's intended meaning.

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.

Oops, you are correct. Good pick up, I'll get to changing that!

Not using cryptographically safe random key is very stupid, even though it is only an example. It should be very trivial to fix this example.

I think in python the right way is to use the os.urandom() function.

My intention in using "hand crafted"/memorable private keys was just to make the article and what I was doing easier to follow.

I don't think there's any harm in people copying and pasting examples, it only becomes an issue if they start depositing money to either of the addresses that I listed the private keys for. I hope that's an obvious enough mistake not to make! Thanks for the feedback anyway, I'll keep an eye on those addresses and if they start getting mysterious deposits change the article to include more cryptographically secure keys.

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 generation [2, 3].

[1] https://github.com/ethereum/go-ethereum/blob/release/1.6/cry...

[2] https://github.com/ethereum/go-ethereum/blob/release/1.6/acc...

[3] https://github.com/ethereum/go-ethereum/blob/release/1.6/acc...

No promises but I was actually considering having a crack at this as my next project. stay tuned!

I did deliberately leave that there in the hope someone might take it using what they'd learnt from the article. there's a short note about this in the conclusion to the article. From the "non whole" fee amount it looks as though someone might have just used some sort of wallet software to take it though, which is a shame.

As of the time of publishing, roughly ~8.58 USD.

For fun[1], you can occasionally trawl through addresses with any private key!

http://directory.io/

[1] For various definitions of "fun."

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?

Addresses are created offline for scalability reasons, meaning that not having to interact with the blockchain is a feature, not a bug.

There are 2 levels of collision that are theoretically possible. The tldr is that both are really hard, way harder than mining itself, so you'd better spend your time mining that trying to find collisions in the address space.

The first level is that you can generate the same private key, i.e. guessing exactly 256 bit. Prob is 1/2^256.

The second level is that you find a collision in hashing the public key onto the address. Hash is a combination of sha256+rimemd160, but in fact it's a hash onto 160 bits, so the probability of finding a collision is 1/2^80 because of the birthday paradox.

When you generate a new address, you can certainly add an extra step and verifiy if it's used already in the blockchain. If you find a collision, though, please send it to me before discarding it :)

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.

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.

It's essentially for efficiency but not merely; it would be impractical to do with partial spends. Transactions are immutable and spend all of their inputs because it's easier to track and verify no double spend has occurred. If you allowed for partial spends, you'd have to trace the ancestry and descendants of all the transactions to verify whether there was enough bitcoin to spend it. This way if you have a transaction and it hasn't been spent since it originated, you know exactly how much can be spent.

I think it's natural to think of addresses as having a certain amount of bitcoin in them like an account at a bank. But bitcoin doesn't actually have accounts with balances. It just has transactions that have yet to be spent. You can calculate the amount of bitcoin that is spendable by an address so it looks like an account, which is what every wallet does but underneath it's just a collection of transactions that point to some address that you have the private key of.

The high-level meaning of a transaction is to send all the contents of an address. So if you only want to send partial payment, then you need two transactions - one to the foreign destination address and one back to yourself for the remaining funds. The analogy is closer to law and property title, rather than the mathematical/accounting actions of addition or subtraction.

In fact addresses don't really exist, other than as named state in the chain of title. It is the prior, unspent transaction output (utxo) that is unlocked during a transfer, and not some abstract bitcoin address.

Other blockchains, can and do handle these things differently.

Because the miner almost always expects a fee, so why not just infer how high it is and you don't need to spend block bytes on it?