> 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.
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.
Bitcoin can soft-fork, allowing address generation with a different algorithm. It's not any sort of existential threat to Bitcoin. But it does require that you move your coins to a new address if you reuse an address, else you are vulnerable.
This burned sony, and burned people that had faulty wallet code that submitted transactions with the duplicate nonces.
If you only published, and signed a transaction once, you would be immune to fail by ECDSA nonce reuse.
Its good to rotate the publickey/address per transaction in bitcoin
One issue I'd like to point is I wish the author used proper random generated private key. Examples on the internet have a nasty habits of being copy pasted and reused verbatim :(
I think in python the right way is to use the os.urandom() function.
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.
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.
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...
https://blockchain.info/tx/2685ff794de17cebdf94eb0f111e8b8c0...
This made it worth reading the article. Such cyberpunk!
[1] For various definitions of "fun."
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 been a lot of weak key generation techniques in bitcoin where hiding the public key won't do you any good.
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?
Even if the chances are very small I mean...like....gone is gone...no bank to call for a false transaction.
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 :)
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.
Framed this way, you can see that in fact if your defensiveness is necessary, addresses would be extremely unsafe against targeted attack.
(accepted answer includes) „...It may be "theoretically" possible...“
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.
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.
ECDSA is vulnerable to a modified version of Shor's quantum integer factorization algorithm. However, nobody on Earth is known to be close to producing such a computer. Adiabatic quantum computers like the ones produced by D-Wave are not known to be capable of running Shor's algorithm. See https://en.wikipedia.org/wiki/Adiabatic_quantum_computation
SHA-256 and hashing algorithms have no known quantum attack against them, but one could theoretically gain a sqrt(n) advantage in brute-force search using Grover's quantum search algorithm. https://en.wikipedia.org/wiki/Grover%27s_algorithm
Let's say the probability of someone cloning a Velociraptor within the next 20 years is 1 in 1 trillion. Let's say that given a Velociraptor has been cloned, it has a probability of 1 in 1 million of escaping. Let's say that given a Velociraptor is on the lam, it has a 1 in 100 billion chance of breaking into your house. Let's say that if there's a Velociraptor in your house, checking for it increases your chance of survival by 1%.
Let's assume there are 1 quadrillion Bitcoin addresses created.
Under the assumption of correct implementation, checking for velociraptors in your closet is literally more rational than checking for duplicate addresses.
Now, there is some value in checking for duplicate keys as a safeguard against implementation bugs, but that's best covered by generating a billion addresses on your own and checking for duplicates within your personal set.
I suspect it was a design decision, yeah. If outputs could be spent multiple times then you'd need to traverse the chain of outputs backwards to see how much an output has left in it. Bitcoin's implementation is less complex and more elegant, imo.