Generated coins can't be spent until the generation transaction has 101 confirmations. Transactions that try to spend generated coins before this will be rejected.
The reason for this is that sometimes the block chain forks, blocks that were valid become invalid, and the mining reward in those blocks is lost. That's just an unavoidable part of how Bitcoin ...
The term "coinbase" is used to mean many different things. But the two you're probably asking about are:
The "coinbase transaction" is the transaction inside a block that pays the miner his block reward.
Inside the coinbase transaction is a field that is called the "coinbase". It's the generation transaction's equivalent of a scriptsig. Since it doesn't ...
The block is accepted, and the coins are lost. Poor miner.
Here is a link to the part of the 0.6.3 source which checks this: https://github.com/bitcoin/bitcoin/blob/v0.6.3/src/main.cpp#L1362
Also, this has effectively happened before; block #124724 claimed one satoshi less it than could have.
A coinbase transaction follows the same format as a normal transaction, except:
It has exactly one txin
This txin's prevout hash is 0000...0000.
This txin's prevout index is 0xFFFFFFFF
The txin's prevout script is an arbitrary byte array (it doesn't have to be a valid script, though this is commonly done anyway) of 2 to 100 bytes. It has to start with a ...
Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK.
Is this space ...
According to BIP 34 the coinbase transaction is required to start with the block height. The format is a single byte giving the count of bytes to follow (currently 3) and then the block height in little-endian. See Why block height is required in coinbase? for more on the rationale.
478529 decimal is 0x074d41 in hex, so this block's coinbase must begin ...
A block is accepted immediately (assuming it is valid) the maturation time applies to the coinbase reward to the miner found in the block (bock subsidy + tx fees).
The purpose is to prevent a form of transaction reversal (most commonly associated with "double spends") if the block is orphaned. If a block is orphaned the coinbase reward "ceases to exist". ...
how is the output of a coinbase transaction (plus block's transaction fees) different than the outputs of any other transaction?
Because it's validity is tied to WHICH block it is included in. You can't take a coinbase transaction and include it as if it were a standard transaction in another block, because it creates more bitcoins than it spends, which is ...
Here is a breakdown of the entire genesis block:
01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - prev block
3BA3EDFD7A7B12B27AC72C3E67768F617FC81BC3888A51323A9FB8AA4B1E5E4A - merkle root
29AB5F49 - timestamp
FFFF001D - bits
1DAC2B7C - nonce
01 - number of transactions
01000000 - version
01 - input
Look at block #280963. Look at coinbase transaction d1c6b8...fd08. You can see CoinBase data:
This is a script. Look at wiki for details. In coinbase transaction this script can contain any ...
First of all, when 1 second has passed, the miner can just increment the timestamp in the header. This already gives us 4 Ghash/s rather than 4 GHash/block.
When this is not enough, and the nonce range is exhausted before a second has passed, the miner builds a new proposed block with a hash to search through. Specifically, the very first transaction in the ...
In a limit order, you specify how much of the asset (in this case BTC) you want to buy or sell, and the price you want. If there are matching orders on the book (e.g. someone who wants to sell at the same price, or lower, as the price at which you want to buy), your order will be filled immediately. If not, your order will stay on the book until matching ...
The block that Alice mined includes the mining rewards going to Alice's address. If Eve alters the block data to output the rewards to her own receiving address, then the nonce (and other variable values, I think "extranonce" and timestamp) that Alice used to solve the block will almost certainly no longer solve the block.
There are 3 places where GetBlockValue is called. One is on incoming blocks, one is on blocks we're mining, and one is an error message. This is the one for incoming blocks:
if (vtx.GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
return state.DoS(100, error("ConnectBlock() : coinbase pays too much (actual=%"PRI64d" vs limit=%"PRI64d")", ...
David has already given a good explanation of the term coinbase, but I'd like to give further details on the coinbase transaction.
The coinbase transaction is a special type of transaction.
Every block must have a coinbase transaction, other transactions are optional.
The coinbase transaction must be the first transaction of the block (it follows that ...
Yes, it must.
Block without coinbase transaction will be rejected by network.
From the Protocol, rule #6:
First transaction must be coinbase (i.e. only 1 input, with hash=0, n=-1), the rest must not be
In the same special "generation transaction" that collects the 25 newly minted bitcoins, the miner also collects the total of all the transaction fees in the block, and together can send them to an address(es) of his choosing.
No signature is required; it's a hardcoded perk to whoever manages to find a block.
This is normal. You can see on https://bitcoinfees.earn.com/ that BTC 0.001 is a pretty average fee right now.
You should not think of it as a percentage, since the fee for a transaction is not related to the amount of coins transacted. Instead, it has to do with the size of the transaction in bytes, which is more a matter of its complexity (e.g. number ...
Every block must include one or more transactions. The first one of these transactions must be a coinbase transaction which should collect and spend the block reward and any transaction fees paid by transactions included in this block.
Bitcoin Foundation Developer Guide— https://bitcoin.org/en/developer-guide#transaction-data
This is a known bug in the early days of bitcoin.
Was fixed by BIP-30 https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
There is a discussion here: https://bitcointalk.org/index.php?topic=216938
And yes, 50+50 bitcoins are missed forever.
In fact, there are much more missed bitcoins. For example, 2500 bitcoins were gone to nowhere
in block ...
A coinbase transaction is characterised by "previous_output" field of the transaction being 32 bytes of zeros and 4 bytes of 0xFF. It should be the first transaction of the block, but I'm not sure whether all the clients enforce this rule. The signature script of the coinbase transaction need not obey the Script protocol, but as far as I remember the first ...
There is no technical constraint causing the genesis block's reward to be unspendable forever.
It is a bug that has now become the accepted standard. In the future the genesis block reward could be spent but clients must be updated to fix this bug or they will reject blocks containing a valid input referring to this transaction (...
There is a maximum limit on the block reward which is 12.5 BTC but nothing prevents a miner from claiming less than 12.5 BTC. In fact, there have been times when miners forgot to claim any bitcoin at all (claimed 0 BTC), a very expensive mistake. This is probably a mistake from the miner, he could have certainly claimed more bitcoin.
As long as the block ...
Nope. Not 1 bit. A balance (in this context) is the sum of all UTXO's for a given address. There is no limit on the number of UTXO's or their total amount (from the perspective of how the blockchain works and the blockchains limitations).
Software interpreting the balance may have limitations on consuming, processing and/or displaying a number beyond a ...
This is not true. Code and code comments in v0.1.5 (the oldest tagged version in git) enforce that there always is a coinbase transaction and that it must always be the first. There cannot be a coinbase transaction elsewhere in the block. Coinbase transactions are defined as transactions with one input whose previous transaction hash is all 0's and whose ...
The nBits don't exactly get swapped. The notation on the wiki is in big-endian notation, which is basically the notation you'd use when displaying it, similar how the number twelve is written 12 and not 21 (different number order) but can be stored as 21 by a computer.
Your modern computer uses little-endian, which means that if you write something like :
I think this is best answered by an example. Let's find the coinbase from a block on the Bitcoin testnet.
First we'll get the hash for a block we want to look at. We'll have a look at the (as I write this) latest block:
> bitcoind getblockcount
> bitcoind getblockhash 81626
Miner has to supply the Bitcoin address for block reward. Then, when the block is mined, the special "credit" transaction is permanently stored in found block, creating given amount (25 BTC, was 50 BTC) to given address.
Some pools (Eligius or P2Pool) use this feature and create a lot of credit transactions, so that when block is found, all participants ...
One of the network rules is that a coinbase's outputs cannot be larger than the current block reward plus the transaction fees of the transactions in the block.
So, a miner claims the transaction fees by increasing the amount of the block reward. This is true even after 2140, when there will be no block reward. (Network rules require that the first ...
In Bitcoin v0.1.5 to v0.3.24, the coinbase scriptSig contained:
txNew.vin.scriptSig << nBits << ++bnExtraNonce;
In Bitcoin v0.4.0 to v0.5.3, it changed to:
pblock->vtx.vin.scriptSig = CScript() << pblock->nTime << CBigNum(nExtraNonce);
Bitcoin v0.6.0 to v0.6.3:
pblock->vtx.vin.scriptSig = (CScript() <&...