associated bc addresses when minting coins

[earney]

when a processor mines a coin, their bitcoin address is associated with the mined coin.  if someone gets lucky enough to mine another coin, does the same bitcoin address get associated with the newly mine coin?   I'm looking at some mined transaction data (creation of 50 BC coins), and I'm seeing that very few bc addresses are mining more than one (50 BC) coin.  I was thinking a good question to ask since some people are talking about using GPU's to mine coins, and how lower powered cpu's maybe at a disadvantage would be, "Are some users mining more coins than others?"

So in summary, my question is,  can more than one bc address be used to mine coins?  If so, does anyone have an idea of how we can figure out if two or more addresses are associated with a single miner?

Thanks!

[1714959857]

1714959857

[1714959857]

1714959857

[1714959857]

1714959857

[1714959857]

1714959857

[1714959857]

1714959857

[ribuck]

Each bundle of 50 generated coins, together with any associated transaction fees, gets its own address. A different address will always be used for each subsequent bundle of generated coins.

If the generated coins have not been spent, there's no way to know whether two bundles were generated by the same miner or by different miners. When the coins get spent, it's possible that a single transaction will include both bundles, at which time the information appears in the block chain and everyone can deduce that the two bundles were generated by the same miner.

There are ways around this (e.g. exporting a key from one wallet and importing it into another, or using a modified client that never combines generated bundles when sending coins) but I don't think there are any standard tools available.

[earney]

whats funny is when I look at the results of the queries I'm running, we have 12 blocks that contain the same recipient address (as another block) for the mined coins.  To verify that I'm pulling data correct, I used blockexplorer, to verify my results.

 An example of this issue can be found by looking at the blocks below:

http://blockexplorer.com/b/70459
http://blockexplorer.com/b/70460

both were mined by the same recipient 15w6iQpfmsKwHswaUoWNWhyjAftrU1b3yB

I have 5 other examples that contain this same issue.

does someone get a new address after they make a transaction, and any new coins mined will have the newly created address?

the data I'm looking at doesn't support your statement of "new address for each mined coin", since I have 12 blocks that have the same recipient address as another block..

Please help me to understand what is going on here.  Is there documentation that would describe this?

Thanks!

[caveden]

He was probably talking about the default client generator.
There are many different implementations of generators out there. If someone creates one that reuses the generation address, there's no reason to refuse the generated blocks.

[theymos]

the data I'm looking at doesn't support your statement of "new address for each mined coin", since I have 12 blocks that have the same recipient address as another block..

Please help me to understand what is going on here.  Is there documentation that would describe this?

Thanks!

Mainline Bitcoin will never create two blocks with the same address. It's dangerous to do so, in fact, as you might create duplicate transactions. It is technically possible, though, if you modified your client to do so.

If you've generated two blocks that were sent to the same address and you're using mainline Bitcoin, then this is a bug.

[Hal]

Maybe we should fix this duplicate-transaction problem. We could embed the block number in the generation transaction so they would all be unique. Right now the txin has hash = all zeroes, n = UINT_MAX. We could change to n = block number and still identify it as coinbase by the zero hash.

[theymos]

Maybe we should fix this duplicate-transaction problem.

It's not a problem unless you force Bitcoin to use addresses more than once. Modified clients can add arbitrary data to the generation's scriptSig in order to get more uniqueness.