Topic: transactions & signatures in depth questions (Read 1323 times)

"coinbase" transaction will be hash with the first transaction in the block?

Wow, I sure feel like a newbie all the sudden.

Sticky up top.

Wow, I've been active here at bitcointalk.org for nearly 2 years (and have been studying the bitcoin concept for more than 2 years), and it never even dawned on me that there might be some sort of mailing list.

How would I get myself added to that list?

Since this is an educational thread, a few pedantic points that you need to keep track of if you move from the "pop-tech" sources (like the forum) to the "hard-tech" sources (like the source and mailing list).

That special transaction is the "generate transaction" and it does have an input, of sorts.  (At the very least, the #TxIn field exists and is 1 instead of zero.)  Normally, an input contains a reference to a previous UTXO and a SigScript.  In a generate transaction, the reference is bogus (hash of 0x00 and sequence of 2³²-1) and the SigScript is just garbage  That garbage is called the coinbase.  The coinbase is required to include the height of the block containing it, in (normalized?) cScript encoding.

https://en.bitcoin.it/wiki/File:TxBinaryMap.png

Just wanted to say that was a really clear way of explaining it which is something I always struggle to do when putting information in my head into simpler terms so thanks for that.

Every solved block is allowed by the protocol to contain exactly one transaction that has no inputs, and still be considered to be a valid transaction when all the peers verify the block before relaying it. The sum of outputs of this special transaction are not allowed to exceed the sum of the transaction fees of all other transactions in the block plus the current block subsidy.

This transaction is often called a "coinbase" transaction, and it is both how new bitcoins come into existence with each block, and how the miners are rewarded for their effort in securing the blockchain.

^^^could you please clarify this?

its more then 101...and u right i do owe him.

DeathAndTaxes is correct with his clarification on "outputs" being spent instead of "transactions".  I had simplified a bit and skipped this detail since you were struggling a bit already with the basic concepts on signing and relaying transactions.  I touched on it a bit when I mentioned, "Then wallet A creates 2 outputs.  One output assigns 1.3 BTC to Wallet_B_Address_A.  Wallet A creates a brand new empty address Wallet_A_Address_D and creates a second output in Transaction6 assigning the remaining 0.4 BTC to this new address."

I think you owe Danny some tuition for the Bitcoin 101 course.

One small thing to add to all that good information is transactions are never "spent".  Outputs are spent.  A transaction can contain one or more outputs.  Each can be spent independently.  An output is spent when it is referenced in the input of a future transaction.   The input of all transactions (with one exception) references a specific unspent output.

Most of these questions were answered in the Whitepaper.  Perhaps you should review it and ask questions about the specific areas of that document that confuse you.

DannyHamilton thank you!
ill need a day or two for that.

Each peer will consider a transaction output spent when that peer first hears of a transaction that uses the previous transaction output as an input.  This means that if a peer hears of any other transaction that tries to spend the same previous transaction output, it will consider the second one that it hears about to be "invalid" and will refuse to relay it or acknowledge it.

I can therefore create 2 transactions (Transaction7 & Transaction8) that both spend the same previous output.  I can send Transaction7 to half of the peers that I am connected to, and Transaction8 to the other half of the peers that I am connected to.  Both sets of peers will verify the transaction (since it is the first one they heard about) and attempt to send it to the peers that they are connected to.  At that point there is a race as the 2 transactions spread out across the network.  Eventually part of the network accepts Transaction7 as "valid" and the other part of the network accepts Transaction8 as "valid".  The miners that hear about Transaction7 first are trying to confirm Transaction7.  The miners that hear about Transaction8 first are trying to confirm Transaction8. Once a miner succeeds in confirming one of the two transactions it will relay that block to all its connected peers.  The block will spread across the network.  All peers will drop both Transaction7 and Transaction8 from their memory pools, since now one of the 2 transactions is in a block.  Whichever of the two transactions made it into the block becomes the "real" and "confirmed" transaction that all peers now know about.  The other transaction just doesn't exist anymore.

What is A and B?

This is not how transactions work.

There is no -3coins and +3coins.

A transaction completely spends one or more previously received outputs from previously received transactions.
Then it assigns that value to one or more new addresses (some of which might be addresses in the same wallet that is spending the bitcoins).

It is impossible for anyone accept you to know how many addresses are in your wallet unless you tell them.

So for example...

Wallet A has for example 3 addresses Wallet_A_Address_A, Wallet_A_Address_B, and Wallet_A_Address_C

That wallet A has received transactions at each of those addresses in the past:

• Transaction1 sending 1 bitcoin to Wallet_A_Address_A
• Transaction2 sending 0.5 bicoins to Wallet_A_Address_A
• Transaction3 sending 1.2 bitcoins to Wallet_A_Address_A
• Transaction4 sending 0.1 bitcoins to Wallet_A_Address_B
• Transaction5 sending 0.25 bitcoins to Wallet_A_Address_C

Unless you tell everybody that your wallet contains those three addresses, nobody can determine that the addresses belong to the same wallet A at that time, so nobody except you knows that the balance displayed by the wallet A is 3.05 BTC.  Other than the display to you, there is no "account" that is being updated with a total.  Each of those outputs is completely separate. (They can see that Wallet_A_Address_A controls 2.7 total bitcoins, Wallet_A_Address_B controls 0.1 bitcoins, and Wallet_A_Address_C controls 0.25 bitcoins, but they can't tell from the addresses that they all belong to the same wallet or who they belong to)

Now the user of wallet A decides to send 1.3 BTC to an address supplied by the user of wallet B.  The user of wallet A does not know how many addresses wallet B has or what the addresses are.  The user of wallet B creates a brand new address with no bitcoins in it yet.  We'll call it Wallet_B_Address_A (since this is the ONLY address of wallet B that the user of wallet A now knows about).

Wallet A creates Transaction6 spending one or more of the previously received outputs to provide at least 1.3 BTC of value to the transaction.  As an example, we'll assume that wallet A chooses the 0.5 BTC from Transaction2 and the 1.2 BTC from Transaction3.

This supplies a total of 1.7 BTC of value to Transaction6.  Then wallet A creates 2 outputs.  One output assigns 1.3 BTC to Wallet_B_Address_A.  Wallet A creates a brand new empty address Wallet_A_Address_D and creates a second output in Transaction6 assigning the remaining 0.4 BTC to this new address.

Wallet A then signs the two inputs with an ECDSA digital signature of a digest of Transaction6 using the private key associated with Wallet_A_Address_A (since both those inputs were previously outputs that were sent to that address).

Wallet A then broadcasts this transaction to all the peers that it is connected to.

Each peer verifies that the signature is valid, that the inputs provide sufficient value to the transaction to account for the sum of the outputs, and that the transaction conforms to any other rules of the protocol.  If the transaction meets all these requirements, then the peers add the transaction to their own memory pool, and relay it to all the peers that they are connected to.  Each peer on the network, as it receives the transaction, re-verifies all the requirements before relaying it to it's own peers.

Eventually one of the peers that wallet B is connected to broadcasts the transaction to wallet B.  Wallet B recognizes that one of the outputs belong to an address that it has the key to.  Wallet B verifies the transaction (just like every other peer), and relays the transaction (just like every other peer), but it also updates the balance that it displays to the user of wallet B indicating that the wallet just received an unconfirmed transaction for 1.3 BTC.


At this point almost the entire network can see that bitcoins that were previously received in two transactions at Wallet_A_Address_A have been spent.  They can also see that the transaction sent 1.2 BTC to an address and 0.4 BTC to another address.  Unless the users of one of the wallets tells people, it is not possible to know for certain what wallet owns each of those addresses.  It is not possible to know that the 0.4 BTC are being sent back to the originating wallet as "change" or that the 1.2 BTC is going to a wallet that is owned by the reciever.


Including transactions in a block is entirely voluntary.  As Transaction6 is being relayed throughout the network, eventually some miners and mining pools receive it. They verify it and relay it just like any other peer.  Then they decide if Transaction6 meets the criteria that they have set for including transactions in the blocks that they create.  If it does meet that criteria, then the miner (or mining pool) builds a new block that includes Transaction6 and begins attempting to solve the block.  Solving a block is a random and difficult processes.  The protocol automatically adjusts the difficulty so that the entire combined mining power on the bitcoin network solves a block approximmately once every 10 minutes.  If the miner (or mining pool) that solves that block did not choose to include Transaction6, then Transaction6 has to continue to wait until a miner that does include the transaction succeeds in solving a block.


There is no guarantee that it is 10 minutes.  The difficulty is adjusted so that the long term average is 10 minnutes, but it is a random processes. It is possible
to have 2 blocks that happen within less than a second of each other. It is also possible to have more than an hour until the next block.

10 minutes was chose by Satoshi as a way to allow reasonably fast blocks while limiting the time wasted mining the wrong block.  Each block builds on the previous block.  This means that if someone solves a block, you working on a block that is likely to be invalid until you hear about the solved block from a peer.  Meanwhile the miner that solved the block has a headstart on you working on the next block.  If it takes your node 5 seconds to hear about a block that has been solved, and the average time between blocks is 6 seconds, then most of the time, you are going to be working on the wrong block (until you succeed in hearing about a block fast enough and solve the next block first).  The longer the average gap between blocks, the smaller percentage of the time you will waste on the wrong block.

Perhaps 5 minutes would have worked.  Perhaps 1 minute would have worked.  Satoshi chose 10 minutes, so that's the way bitcoin operates.

1. thanks
2. thanks
3. ill consider it "random"...

when a transaction is labeled 'spent' ?
i an not sure if its right after the first indication in the receiver wallet or after the mining process...?

thanks

1. entire network as well.
2. no - basically you need to convince a miner to mine your transaction - it might just as well be forever
3. ask satoshi

Hello ! set of new queries if you will.

the transactions status before entering a block

A-----3coins--->B
they can right away see that A wallet=(-3coins) and B wallet=(+3coins).
1. only they can see that as this point or the entire network as well?
2. is there a term for that period of time(before Hasing into a block)?
3. why conformation is 10 minutes long and not 5? or any other number?

thank you!
Gol

super clear now!
i have many more questions... but ill do some more reading before asking.

thank you!

No.  Neither are correct.

There is a private key (a random 256 bit number).
ECDSA is used to generate a public key from that private key (compressed or uncompressed).
The public key is hashed (PubKeyHash).
The PubKeyHash is versioned, checksumed and then encoded in base58 to produce the address.

There are four distinct things
Private Key
PubKey
PubKeyHash
Address

Each of these are used in different areas in the Bitcoin protocol.  A user may provide you an ADDRESS which your client reverses to the PUBKEYHASH.  Your client create a transaction which uses the PUBKEYHASH in the output of the transaction.  The transaction is signed by your PRIVATE KEY(s) your PUBKEY(s) are included in the input to allow other nodes to verify the signature.