Early bitcoin mining and unique addresses

[walletrecoveryservices]

Hi.
I am interested in the process followed during the early days of bitcoin mining - back in 2009, 2010.
I understand that mining was performed on home computers, and the difficulty level was obviously much easier than now
(and the block reward was 50 btc)
What I do not understand is why each block that was mined back then seems to go into a new, unique, bitcoin address?
For instance, look at block 1001
http://blockexplorer.com/b/1001
The block reward went to address 1FJNKtXWjbNA1TBzCyTEnoMEbC8XsFPmFF
This address is never re-used. (afaik)
Look at block 1002, 1003, 1004, etc. They all are associated with new addresses.
I have (just manually), clicked through dozens of those early block rewards, and none of the addresses seem to be ever re-used.
Surely if there were only a handful of miners back then, each miner would have only one address that the block reward would have been being sent to? Why do none of those early bitcoin addresses have more than one block reward added into them?
Can anyone explain?
If I had done some bitcoin mining back then, would I have a unique bitcoin address that contained the sum of my mining efforts?
Thanks
Dave

[1714774278]

1714774278

[1714774278]

1714774278

[1714774278]

1714774278

[Coiner.de]

You get this if you solo mine with bitcoin, I think. Same thing as with change addresses.
Pools introduced reusing of the same address.

[gmaxwell]

Bitcoin was designed generally assuming addresses would never be reused. A number of the assumptions in the design are broken by reuse— but users are ignorant and lazy and now adays reuse addresses frequently. The reference software does it right generally, so you don't see so much reuse earlier in Bitcoin's history.

[walletrecoveryservices]

Ok, I see, thanks. (and I've just peeked at the early bitcoin-qt source code, and I can see that new addresses are generated for each new coinbase transaction)

[sumana]

Bitcoin was designed generally assuming addresses would never be reused. A number of the assumptions in the design are broken by reuse— but users are ignorant and lazy and now adays reuse addresses frequently. The reference software does it right generally, so you don't see so much reuse earlier in Bitcoin's history.

why cant they force to use that design in QT ?

[CryptoMiningContracts]

Bitcoin was designed generally assuming addresses would never be reused. A number of the assumptions in the design are broken by reuse— but users are ignorant and lazy and now adays reuse addresses frequently. The reference software does it right generally, so you don't see so much reuse earlier in Bitcoin's history.

What is the benefit of not reusing addresses?

[DeathAndTaxes]

Bitcoin was designed generally assuming addresses would never be reused. A number of the assumptions in the design are broken by reuse— but users are ignorant and lazy and now adays reuse addresses frequently. The reference software does it right generally, so you don't see so much reuse earlier in Bitcoin's history.

why cant they force to use that design in QT ?

An address is just a string of letters there is nothing you can do to prevent someone from using it more than once.  The client does try to discourage that but many people insist and some probably would use command line to dump the keys if that is what it took to ensure they can reuse the address.   

[DeathAndTaxes]

Bitcoin was designed generally assuming addresses would never be reused. A number of the assumptions in the design are broken by reuse— but users are ignorant and lazy and now adays reuse addresses frequently. The reference software does it right generally, so you don't see so much reuse earlier in Bitcoin's history.

What is the benefit of not reusing addresses?

Privacy is one.  Address reuse makes it easier to track transactions on the blockchain.   Also in the unlikely event that ECDSA is compromised or a client has a bug which allows funds to be stolen if the PubKey is unknown not reusing addresses keeps that information hidden until a transaction is made.  An address is an encoded PubKeyHash to spend the coins requires providing the corresponding PubKey.  So even if one could steal coins of all known PubKeys if an address has only been used once the PubKey is still unknown to the attacker.  It is a secondary line of defense and would give the keyholder options for safely transfering funds to a more secure address.

This is more than just academic.  ECDSA signatures require a unique "k" value to be used.  If the k value is repeated for the same PubKey then the private key can be computed and funds stolen.  This happened on android wallets due to a flawed RNG however funds could only be stolen from users who reused the same address.  The flaw existed for all users but those who didn't reuse addresses were safe as the exploit required the PubKey to be known and there to be at least two "spends" from the same address.

[Cryddit]

why cant they force to use that design in QT ?

You could do that, but it would have to run a lot deeper than the QT client. 

You could hardfork Bitcoin with an additional transaction validity rule, that if an address has ever been previously used for a txout, then another transaction after block XXXX which also uses it for a txout is not valid.  It would be good for privacy, obviously. 

But it would increase the demands on computer resources required to validate the blockchain considerably, because they'd have to keep track of all txouts rather than just unspent txouts. 

I've considered this, mostly because it would shut down (existing) pools, and I think pools are bad because they can easily be used for attacks and the miners don't even necessarily know what they're hashing on.  But the reasons why people want to use pools would still be there, and they would just create a new pool protocol that conformed to the rule using BIP16 addresses (which they ought to do anyway). Ultimately, it wouldn't shut down pools, although it would make them more private.

The right way to get rid of pools is to do something that addresses the reasons (such as distributed pool software), rather than just firing the opening shot in something guaranteed to become an arms race.

[gmaxwell]

there is nothing you can do to prevent someone from using it more than once

Well, technically the network could prohibit it. E.g. Bytecoin (and its forks) prohibit a single public key from ever being spent from more than once. Zerocash will also require such a restriction.

You could hardfork Bitcoin with an additional transaction validity rule,

Such a change is merely a soft-forking change, it only restricts the set of valid behaviors.

But it would increase the demands on computer resources required to validate the blockchain considerably, because they'd have to keep track of all txouts rather than just unspent txouts.  

Right, it requires an an unprunable data structure that will grow forever.  However, you could make it lossy with most of the same privacy effect, e.g. you can't use an address used anywhere in the last 2016 blocks. This isn't an option in bytecoin, since it needs the non-reuse invariant to prevent double-spends.

I've considered this, mostly because it would shut down (existing) pools, and I think pools are bad because they can easily be used for attacks and the miners don't even necessarily know what they're hashing on.

hah well if this was your motivation then I guess you couldn't deploy that as a soft fork.

But you're wrong there wrt pools, it would be very easy for pools to switch to paying BIP32 chains or ECDH addresses— and they should, for privacy reasons.  Eligius' prior operator (Luke) wanted to do this, but the new management is less interested in doing things which are of long-term benefit.

For a little while Eligius was generally deprioritizing recent-address-reusing payments in their block selection as a way to discourage reuse generally and to also give more fair access to the blockchain. I'm not sure if they're still doing that.

But the reasons why people want to use pools would still be there, and they would just create a new pool protocol that conformed to the rule using BIP16 addresses (which they ought to do anyway). Ultimately, it wouldn't shut down pools, although it would make them more private.

Or that.

The right way to get rid of pools is to do something that addresses the reasons (such as distributed pool software), rather than just firing the opening shot in something guaranteed to become an arms race.

Welp, P2Pool exists, and could use some more love and attention.

[Brangdon]

why cant they force to use that design in QT ?

Another reason is that there are legitimate reasons to reuse addresses. For example, I have an address in my signature on this forum. That's only practical if I have an address that is stable and reusable. I don't much care about privacy for that address. If anything, I think it might be useful to have an address I am publicly associated with. (I keep it in a separate wallet so it's less likely to get confounded with addresses I do care about). You'll notice I made it begin with the first few letters of my name; that's how lacking in anonymity it is.

Note that the security issue only arises for reusing addresses that have been spent from. You can send coins to the same address any number of times without revealing its public key. Also note that, provided you don't have a bug in your wallet software, the loss of security from reusing an address that has been spent from is academic.

[gmaxwell]

That's only practical if I have an address that is stable and reusable

Thats only a restriction in popular software, it's not a fundamental technical limitation.

[knightcoin]

That's only practical if I have an address that is stable and reusable

Thats only a restriction in popular software, it's not a fundamental technical limitation.

sometimes I like to sign a msg ( or I have too ) can be digital or analogue one like my passport ...