Topic: The Coinbase Transaction Question (Read 4015 times)

I believe that's a moderator action, and I doubt this will get pinned. There have been plenty of discussions on the technical aspects of bitcoin in the "Technical Support" sub-forum.  How many of them do you see pinned?

I'm not sure. Do I have control over pinning it as the creator or is that a moderator decision? I'll pin it if I can.

This thread seems to cover most of the basics nicely and clearly explained in one page thread, could it be 'pinned' ?

Great. Thanks DannyHamilton and thanks DeathAndTaxes. I learned a lot, you guys helped a lot. I might have more questions a little while in the future but I'll call this one a wrap. You guys know your stuff.

Yes. Exactly.

Oh, so a person can send in one transaction to many different places thus creating many different outputs(or in the case of change). When the person receives that payment and then spends it they need to reference the transaction that sent the payment to them. Since there can be many outputs in that transaction they need to specify the exact output in that transaction which is represented by the index.

Each transaction is hashed using SHA-256 resulting in a unique ID for the transaction.  A single transaction can have multiple outputs, each with their own "Value:" and "scriptPubKey:".  The "Previous Tx:" is the hash value indicating which previous transaction contains the output that is being spent, but you still need to identify which of the potentially many outputs in that transaction is the one being spent.  The "Index:" indicates which of the outputs from the previous transaction are being used as the input of the current transaction. It references the entire output, not just the value.

Alright, I see. Does the index reference the value (BTC) of the referenced output? I think I really get the coinbase now and the private-key, public-key and address. When I first started looking into this I thought that I private-key and public-key was always retained as the SOLE keys that a person has but I see now they're generated with each new address and keys are just stored.

So close, but it still sounds like you're a bit confused on the specifics.

In a coinbase transaction, there is no "script" that replaces scriptPubKey. The coinbase transaction has no scriptSig in the inputs, but it still has a normal scriptPubKey for each and every output setting up the requirements for someone to spend that output in the future.

Nothing "handles sending the earner the BTC", BTC are never "sent" anywhere.  Transactions are simply added to the blockchain.

Close but not exactly.  Bitcoin uses ECDSA specifically curve SECP256K1.
https://en.bitcoin.it/wiki/Secp256k1

The private key is a random 256 bit number.  The private key is combined with the SECP256K1 curve to produce the public key.  There is no hashing involved in the generation of the public key.  The public key is a 512 bit value (unless compressed but lets save that for another day) which represents a point (256 bit x value, 256 bit y value) on the SECP256K1 curve.  The math behind Elliptical Curve Cryptography is complex but the strength comes from the fact that if you have the private key and the curve (public knowledge) you can generate the public key easily but if you only have the public key you can't determine the private key because it would be computationally infeasible.

As an extra level of security (and to prevent things like typos) the public key is then double hashed and a checksum generated.  The 8 bits representing the version number (reason most Bitcoin address begin with 1 = version number), the 160 bit hash and 32 bit checksum are concatenated to form public address.  The public address (simply a 200 bit number) is formatted using Base58 to make it more compact.

https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Private Key - Random 256bit number
Public Key - Produced from Private key using ECC
Public Address - RIPEMD160(SHA256(public key)) combined with version number and checksum



Knowledge of the public address won't give you the public key but even if you have the public key you won't be able to determine the private key due to the one way nature of ECDA keypairs.

Public Key -> Public Address = trivially easy
Public Address -> Public Key = protected by the one way nature of RIPEMD160 & SHA256 hashing functions

Private Key -> Public Key = trivially easy
Public Key -> Private Key = protected by the one way nature of ECC


A transaction consists of multiple inputs and multiple outputs.  Unspent outputs of prior tx become the inputs for new txs.  The tx hash identifies the tx but it doesn't identify which unspent output from that tx is being used.  The index identifies the specific output (first one, second first, 23rd one, etc).

I see. When you create a new address in a wallet application, say, it really creates a new private-key that's a 256 bit unit. Then from that the public-key is formed from a series of hashes and from the public-key another series of hashes creates the address. That means it's always possible to deduce from the private-key what the public-key and address are because you can run the private-key through the series of hashes to get the result. That means that anyone with possession of the private-key has access to the address but knowledge of the address wont yield any knowledge of the private key because of the mathematical impossibility of inducing back up through the hashes.

Also, with the coinbase tx, the scriptPubKey is kind of replaced by another script that handles sending the earner the BTC and this is ultimatly verified through miners working for BTC + transaction fees. What does an index deal with in the index portion of a transaction? I know above for the coinbase transaction it doesn't matter much but what about the others? Also, if anyone wants to put in any input on scriptPubKey and scriptKey meaning I'd be grateful. I keep asking more questions even after you guys do a good job answering other ones but it's like the moment I realize the meaning of one thing it yields five other questions about the deeper nature of the concept.

I cheated.  I answered most of it (with typos, grammatical errors, and formatting errors), then posted, then went back and cleaned up the post and added additional details.

Be careful about this explanation.  I read it they way you just stated it many times when I was first learning about bitcoin, and it had me really confused for the first 5 months.  I couldn't figure out: if I include a signed previous output as an input in a transaction, what would keep someone from modifying the outputs of my transaction before relaying it (since the previous output is already signed).  As I eventually learned, the entire transaction is signed (or rather a hash of the entire transaction, I think) with the private key of the previous output.

Almost.  There is no such thing as signing it to claim the reward.  The unspent output of the coinbase tx is available to the private key holder of coinbase tx once the block is validated* just like any other transaction.  You don't need to claim transactions Bitcoin is a push technology.  If you are the recipient of a tx you have the coins (even if you don't want them).  Remember the blockchain is simply a ledger of the current status and history of the minted coins.  As soon as that history is updated (new block created and validated) all nodes instantly "know" you have the coins.

Take this coinbase tx for example.
http://blockchain.info/tx/1779421745deee5ba44b40a36405e151adcbe64913c0cd617067db28858e653c

25 BTC was generated out of thin air and 0.24561883 BTD in tx fees collected.  The output of the tx (25.24561883 BTC) matches those combined values.  Other nodes will verify that the output of the coinbase matches what is expected (current subsidy + fees).  The 25.24561883 was transfered to the list of addresses you see.  There is nothing to "claim", nothing the receivers need to do.  The owners of those private keys have the coins simply by the existence of this coinbase tx.

Now take the address 13CnZaL3AwZrFwKdyi4TokHbz1VTajpoDa (the first output) for example.  This address received an unspent output worth 0.70738238 BTC.  If the holder of the private key wanted to transfer it (and spending is simply a transfer of ownership) he would create a tx which has this unspent outputs as the input of the new tx, the output would be the intended recipient's addresse(s) and the tx would be signed by the private key for address 13CnZaL3AwZrFwKdyi4TokHbz1VTajpoDa.  

Each address has a corresponding public & private ECDSA keypair .   The address is the checksummed hash of the public key.  It includes the version identifier, the RIPEMD-160 & SHA-256 double hash of the public key and a 32 bit checksum.   To transfer ownership of coins (and spending is merely transfering coins), you sign the unspent output of an address you control with the corresponding private key. Your wallet.dat among other things is a collection of private keys for your addresses which is why it needs to be kept secure.  He who controls the private key controls the coins. 

* Technically newly minted coins can't be spent for 120 blocks.

On edit: Damn Danny is fast, beat me again.

You are getting close, but you aren't quite there yet.

The coinbase is just an list of outputs with no signatures.  The person (or mining pool) that solves the block hash can list as many outputs as they want with what ever values they want assigned to each output in the list, as long as the total of the outputs is not greater than the sum of the allowed block subsidy value and the transaction fees of all the transactions in the block. Each of the outputs in the list is a bitcoin address and a value.  By the nature of being in the list of the outputs with an associated value, the output in the unsigned coinbase transaction is recognized as having that additional value and the right to spend that output to any other address in the future by simply including a reference to the output and a signature from the private key associated with the address that is stored in the output.  There is no need to "officially claim the reward", unless you mean that in spending the reward someone claims that it is theirs to spend by signing it.

Each bitcoin address is associated with a separate private key (there are some technical details that make this not exactly true, but it is generally true in real world use).

To create a new address, you start by generating a completely random 256-bit number.  This random number is the private key.

Next you use the secp256k1 curve and calculate the 512-bit ECDSA public key from this private key.  For all intents and purposes, this is generally considered to be a one-to-one relationship.  I'm not sure if it has ever been proven that 2 different private keys can't generate the same public key, but if they can the odds of it happening are so small that it can be realistically considered impossible.

From there you follow the directions I specified earlier SHA-256, RIPEMD-160, Version, Checksum, Base58Check.

Note that while there are 2^256 possible private keys (just a bit less than 1.58 x 10⁷⁷)
There are only 2^160 (due to the RIPEMD-160 Hash) possible bitcoin addresses (just a bit more than 1.46 x 10⁴⁸)

This would seem to suggest that it might be possible for 2 different private keys to sign transactions spending outputs assigned to the same bitcoin address.

In reality, unless a weakness is ever found in ECDSA and/or the secp256k1 curve  it would be impossible to find these "other private keys". As long as the random private key is being generated from a source with sufficient entropy, the odds of someone accidentally picking a private key that matches a bitcoin address that is being used are so long that it can be considered impossible.

I understand! So the coinbase transaction is just an output with no signatures that is rewarded to the person solves the hash which then gets transferred to the corresponding person's address in which they sign it while sending it which officially claims the reward. Is that about right? The address is also the hash of a public key.

When each new address is created does that create a new public and private key or is a person's private key always retained and reused no matter the change in the public key? Now I understand the coinbase transaction, the money supply creation, and more but the last thing is just what the creation of a new address entails.

Seriously, thanks everyone who helped to understand so far. I just couldn't conceptualize before the notion of creating something from nothing(the question of reality that still and will forever plague man) but I see now the nature of it in relation to BTC.

The coinbase transaction is the first reference point for the first signature.  The coinbase transaction is unsigned and only contains outputs.  Each transaction that spends an output from a coinbase transaction will have a reference to the coinbase transaction output being spent and that is where you'll find the first signature in the chain.

Since there can only be one coinbase transaction per block, I suppose you could sort of think of the block hash as a coinbase "signature" since you can't change the coinbase transaction without modifying the block hash and doing so would require you to perform the proper proof-of-work to replace the block. If you could manage to add your own output to the coinbase of the most recently mined block, and then find an appropriate hash for that block AND then mine the next block before anyone else does (making your chain one block longer than the existing one, you would replace the original block in the blockchain for everyone and your block would become the official one.

Coinbase tx has a special structure.  There is NO prior output.  The coins are minted from nothing.

Input:
Previous tx: - Null
Index: IIRC it is 0 but it isn't checked.  The tx index value of a null output is kinda irrelevant.
scriptSig: - There is no script sig for coinbase tx.  In its place is the coinbase parameter which is used to store the exta-nonce among other things.  It can contain arbitrary data and isn't parsed by the network.

Since no tx except the coinbase can contain a null prior tx (think the first node in a linked list) the coinbase can be identified by the tx which has no prior tx value.  If more or less than one tx in the block has a null prior tx value then the block is invalid.  A block must contain exactly one coinbase.

The coins don't come from anywhere.  They simply never existed prior to the block and they exist (as unspent outputs at the address(es) in the output of coinbase tx) once the block is added to the blockchain.

There is no pool or account with all of the not yet unminted coins which slowly decrements as miners mint them if that is what you are thinking.   You can't trace back further than the coinbase.  The input tx is simply null.

Based on this section of main.h from the reference client



I'd guess the "Previous tx:" will contain something like the following:

Other than that, I don't think the values of any of the other fields will matter much since the only thing the code looks at is the values stored as previous output hash.
 
Perhaps the "Index:" will contain something like:

The "Response Script Length" will probably be a single byte:

And therefore there won't be a ScriptSig (or any response script at all). The very next byte of data after the Response Script Length will probably be the "Sequence Number", and it will probably also be:

After that you'll probably find a variable length integer indicating the number of outputs.

I believe this has already been answered for you here:


If you don't want to click on the http://en.bitcoin.it/wiki/Address link, I can explain that the public key is hashed using SHA-256.  That hash is then hashed again using RIPEMD-160.  A 1-byte version number is prepended to the hash, a 4 byte checksum is appended to the hash, and then that resulting value is encoded with Base58Check encoding.  The result is a bitcoin address.

So, referring to this link I reference : https://en.bitcoin.it/wiki/Transactions

I just want to know how this will look with a coinbase transaction. I understand the basis of the reward system, the miners and the solving of the block's hash through SHA-256 and all continuous transaction following but since there is no input in coinbase transaction is there still something to be represented for the input.

Referring to the link above, will there be nothing following the previous tx, index and scriptsig?

This is given as the input for a tx:

Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Will the coinbase transaction look like this:

Input:
Previous tx:
Index: 0
scriptSig:

Or will something be represented in each section including previous tx, Index and scriptSig?If so, what?
 
It not, what? I just need something very explicit to know what the eventual reference will be. Basically, since BTC are are a series of signatures there must be a first reference point for the signature. Is it just some code originating from the block of the coinbase transaction? If it is, what is that reference? and when we trace a bitcoin back to its creation (or prior to the original possessors signature) what exactly will it look like?

Also, on another note, is an address just a public-key?