Award of coins, same block twice ?

[bassride]

Hi all,

can anyone answer me this.  So I understand roughly how new bitcoins are mined, a node (or mining pool) takes in transactions into a block, then attempts to crack the block head to be automatically rewarded (in the form of a special transaction) their -currently- 25 BTC .. 

WHAT IF  : 2 competing branches emerge in the chain, 

2 nodes pretty much crack block 1021 (example) at the same time.  Are coins ONLY awarded when they are are stacked on top of the main block chain ?  and is it not possible that node 'C' will be 'aware' that block 1020 is the highest block (and therefore working on block 1021) in the stack whereas node 'M' will know about block 1024 being the highest (and therefore working at cracking block 1025 ??)  . 

thanks,

bassride.

[1714994629]

1714994629

[1714994629]

1714994629

[BitshireHashaway]

Huh... I'm pretty sure they use units of time small enough that no two people will ever break apart a block at the exact same time, there will always be a time difference that will make it so it doesn't work like that.

[crary]

This happens occasionally, it's called a soft fork.  (http://blockchain.info/orphaned-blocks) The history is defined by the longest chain, so whichever block the miners happen to build on is the winner.  Timestamps are not used.

[bassride]

not time based definitely, due to the global nature of the network (which OFFICIAL clock to use would be the problem, as its completely deregulated) and timestamps can easily be 'faked', whereas the 'proof of work' on the cryptograhic puzzle cannot, one of the geniuses of the system !

so in a soft fork, its possible that 2(or nodes) could successfully crack the same block number at roughly the same time.  (e.g number 1022), but that the fork, in practice, is resolved quickly so that only one will end up in the main chain (the longest), BUT do they BOTH get issued with Bitcoins ?    ummm!

and if they do this would be in advance of blocks being cracked every 10 minutes ?

maybe in practice this is indeed rare, and in general blocks get cracked in sequence !!

[DannyHamilton]

maybe in practice this is indeed rare, and in general blocks get cracked in sequence !!

This is not rare.  Orphan blocks happen all the time.

so in a soft fork, its possible that 2(or nodes) could successfully crack the same block number at roughly the same time.  (e.g number 1022), but that the fork, in practice, is resolved quickly so that only one will end up in the main chain (the longest),

Correct.

BUT do they BOTH get issued with Bitcoins ?    ummm!

Sort of, but no, not really.

An example:

Miner_A and Miner_B each solve and broadcast a block as nearly the same moment.

As the block is relayed throughout the network, some nodes hear about the block from Miner_A first.  Other nodes hear about the block from Miner_B first.
Until another block is solved, there is a fork in the blockchain.  Those who first hear about the block from Miner_A first believe that Miner_A received the block reward, and any miners who hear about the block from Miner_A first begin working on a new block that builds on top of Miner_A's block. Those who first hear about the block from Miner_B first believe that Miner_B received the block reward, and any miners who hear about the block from Miner_B first begin working on a new block that builds on top of Miner_B's block.  During this time, both Miner_A and Miner_B believe they've received the block reward.

Eventually someone solves another block.  Whichever fork they were in becomes the "longest chain", and everyone in the other fork discards (orphans) the block they were using and accepts the new longest chain as the official chain.  Assuming for the sake of argument that the new block was built on top of the block that Miner_B had previously solved, then suddenly everyone who had previously accepted the block from Miner_A suddenly discards the block from Miner_A and accepts the new pair of blocks (the block from Miner_B and the block that builds on top of it).  All the miners now work on a new block that builds on top of this new longest chain.  At this time, Miner_A suddenly sees his block reward from the earlier block that he had thought he solved disappear with the block.  Suddenly nobody in the network sees that Miner_A has received any block reward at all.

Because of this risk, there is a financial incentive for miners (or mining pools) to be as well connected as possible.  The faster you can get your block relayed throughout the network, the better chance that more miners will be working on top of your block next any the more likely that your block will become the "official" block if a competing block is released.


During the brief period of time that the block that will eventually be orphaned exists in a forked chain, the miner (or pool) that solved that block (and anyone who accepted that block when relayed to them) will see that they have received the block reward.  Meanwhile, anyone who received and accepted the block from the fork that will eventually be the longest, will see that m

and if they do this would be in advance of blocks being cracked every 10 minutes ?

In advance of?  I'm not sure what you are asking here.

[CreationLayer]

Danny,

How do they ensure they are better connected than other pools to the network?

[DannyHamilton]

Danny,

How do they ensure they are better connected than other pools to the network?

I don't do any mining, and I don't really know what specific processes miners (or pools) use to maximize their connectivity.

In general, I'd think that the motivation would be to investigate which broadband internet providers are available to you and to maximize your bandwidth, and to maximize the number of peer connections you have open.

Perhaps there is also an incentive for miners/pools to maintain a list of each other's IP addresses, and make sure that your software is configured to force connections specifically to those IP addresses?

Do pools provide a public list of which IP addresses they use?  If so, I'd think anyone attempting solo mining should configure their client to connect to as many of the large mining pools as possible.

[CreationLayer]

Danny,

How do they ensure they are better connected than other pools to the network?

I don't do any mining, and I don't really know what specific processes miners (or pools) use to maximize their connectivity.

In general, I'd think that the motivation would be to investigate which broadband internet providers are available to you and to maximize your bandwidth, and to maximize the number of peer connections you have open.

Perhaps there is also an incentive for miners/pools to maintain a list of each other's IP addresses, and make sure that your software is configured to force connections specifically to those IP addresses?

Do pools provide a public list of which IP addresses they use?  If so, I'd think anyone attempting solo mining should configure their client to connect to as many of the large mining pools as possible.

Well there is a public list of nodes available.

http://blockchain.info/connected-nodes

Is this what you refer to being important to connect to?

[DannyHamilton]

Well there is a public list of nodes available.

http://blockchain.info/connected-nodes

Is this what you refer to being important to connect to?

That is not a list of nodes available.  That is just a list of the particular nodes that the blockchain.info clients happen to be connected to at the moment.  There are very likely very many more nodes that blockchain.info knows nothing about.

If you are a miner (or a pool), then more nodes you can connect to and broadcast your blocks to the better off you'll be at avoiding having your blocks orphaned.  However, the most important nodes for a miner to connect to are the other mining pools and miners.  You need them to all work on your block next regardless of what block the non-mining nodes happen to have heard about.

If, as a miner or pool, you can establish a connection directly to the following pools:

Slush's Pool (BitcoinCZ)
DeepBit
50BTC
BitMinter
BTC Guild

Then you'll have a better than 75% chance that your block will be the winner in any blockchain fork situation.

[bassride]

Danny, thanks for the great answer on the award of the coins  !!  all clearer after that ; and I can see how being well connected in the P2P network would be beneficial.

can't help but wonder now !    if Miner_a in your example has effectively received the new coins as a special transaction in their newly solved block (in a fork that will surely become orphaned) could they not attempt to spend those coins immediately before they effectively become invalidated !!  OR

I guess that they COULD but then that transaction would effectively be invalidated once that block becomes orphaned (as the same coins are rewarded to the new miner who becomes the TRUE owner)  If the recipient waits for a handful of confirmations before handing goods/services/currecny etc over .. he'll see the confirmation count drop to zero.  If he doesn't he'll lose out .  does that make sense?


re: my question on blocks every 10 minutes.  I understand that the protocol is designed to release coins gradually over time and thought that the 10 minutes had something to do with controlling the rate of coin issue - periodically the difficulty level is changed to keep this approximate rate  (although I did read also that it has to do with allowing time for transactions to propagate through the network)  -- if indeed new coins could be issued to 2 different parties (which I now realise, after your answer, is not possible) coins would possibly be issued at a much faster rate than was planned !!

[DannyHamilton]

if Miner_a in your example has effectively received the new coins as a special transaction in their newly solved block (in a fork that will surely become orphaned) could they not attempt to spend those coins immediately before they effectively become invalidated !!  OR

I guess that they COULD but then that transaction would effectively be invalidated once that block becomes orphaned (as the same coins are rewarded to the new miner who becomes the TRUE owner)  If the recipient waits for a handful of confirmations before handing goods/services/currecny etc over .. he'll see the confirmation count drop to zero.  If he doesn't he'll lose out .  does that make sense?

Yes, this is one of the reasons that it's recommended not to consider a transaction irreversible until after a few confirmations.  It's also one of the reasons that some wallets won't even display the transaction as "confirmed" until it has at least 6 confirmations.  I think most mining pools required about 50 confirmations before they'll even let you withdraw the funds from the pool.

In the example above, if Miner_A were to somehow spend his block reward before his block was orphaned, there would be a few interesting effects:

First of all, much of the network would never even see his transaction.  The recipient would only see the transaction if they received the block from Miner_A before they received the block from Miner_B.  Otherwise, they (like everyone else who received the block from Miner_B first) would be on a different fork, and their wallet would refuse to accept the transaction since it couldn't be validated.

Secondly, when someone who was building on top of Miner_B's block finally solves and broadcasts their block, the transaction from Miner_A wouldn't just drop to zero confirmations, it would vanish disappear completely.  It would no longer be in the longest chain, so it would vanish from there.  Usually transactions from an orpahaned block are moved back into the unconfirmed memory pool, but this transaction would be invalid, since the transaction funding it no longer exists, therefore all the wallets/clients would discard it.

[bassride]

fascinating stuff !  disappearing transactions would definitely be a little mysterious for a receiver/sender who does not have a deeper level of understanding of the transaction process !!, but like you say this is the reason to only consider the transaction 'solid' after those handful of confirmations, chances of your transaction disappearing drastically reduce as the blocks pile higher on yours !

thanks again,

bassride.

[DeathAndTaxes]

Danny, thanks for the great answer on the award of the coins  !!  all clearer after that ; and I can see how being well connected in the P2P network would be beneficial.

can't help but wonder now !    if Miner_a in your example has effectively received the new coins as a special transaction in their newly solved block (in a fork that will surely become orphaned) could they not attempt to spend those coins immediately before they effectively become invalidated !!

No the network prevents this by making newly coined mined non-transferable for 100/120 blocks* (~1 day).  If a miner's chain eventually becomes orphaned only the miner loses.

* 100 is enforced at the protocol.  A new tx with inputs from the coinbase tx of block X is considered invalid for relay or inclusion in a block until block X +100.  The reference client prevents the creation of said transactions until the block is 120 blocks deep in the chain.

[DannyHamilton]

No the network prevents this by making newly coined mined non-transferable for 100/120 blocks* (~1 day).  If a miner's chain eventually becomes orphaned only the miner loses.

* 100 is enforced at the protocol.  A new tx with inputs from the coinbase tx of block X is considered invalid for relay or inclusion in a block until block X +100.  The reference client prevents the creation of said transactions until the block is 120 blocks deep in the chain.

Ah, thanks!  Good to know.

I knew that the reference client prevented creation of the transaction, but did not know that relay of the transaction was prevented at the protocol level.  I has assumed that a raw transaction could be created that could spend the coinbase.

So, you'd have to orphan a fork over 100 blocks long to have a transaction that spends a coinbase output vanish.