Bitcoin Forum
November 07, 2024, 04:27:23 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How exactly do Transactions work in Bitcoin Network?  (Read 2753 times)
NeonFlash (OP)
Full Member
***
Offline Offline

Activity: 198
Merit: 100



View Profile
March 08, 2013, 07:09:23 AM
 #1

I was reading about Transactions on the wiki here:

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

From what I have understood, a Transaction will have inputs and outputs. Inputs will reference the output of some other transaction. At the same time, output will have the details of sending bitcoins.

How does this relate to a simple example in Bitcoin Network such as:

"at this very moment, when all the nodes in the Bitcoin Network are working to complete a new block, let's say, Bruce sends 1 BTC to Linda's Bitcoin Address".

What exactly happens now?

How will the Bitcoin Transaction format look like? What will be the inputs and outputs?

I am trying to correlate it to what is mentioned on the Wiki about Transactions.

Will this information (Bruce sent 1 BTC to Linda), be announced to all the nodes in the Bitcoin Network?
How exactly do other nodes in the Network verify this Transaction?

example from wiki:

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

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG

If someone can correlate it, it would be great.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
March 08, 2013, 08:34:10 AM
Last edit: March 08, 2013, 11:21:57 AM by Stephen Gornick
 #2

What exactly happens now?

How will the Bitcoin Transaction format look like? What will be the inputs and outputs?

[Edit: Most] everything you need to know about transactions you can learn from Blockchain.info.  

Here's some random transaction pulled from a recent block:

Quote
INPUTS:
1PvFignfc4H1hvUJU8EuoeUNMh7WtdJPgp  247.495 BTC

OUTPUTS:
1Gd2SRTE7GC6GHwtSaAeV7d1xhJ7t5iYJ6  245.614 BTC
1CF7wTZM7FmXrioP6ZhSjVuk77CNyPJe2T  1.88 BTC
Fees   0.001 BTC

 - http://blockchain.info/tx/9f0003404687772167a216a8939c7bd77cd75b6e5ce607a872c7c5e62e78d975


Let's say this was Bruce's payment to Linda.  There's no way to know if the 1.88 was the payment to Linda or if 245.614 BTC was the payment.  Arbitrarily let's pick the 1.88 BTC as being the payment, and the 245.614 BTC was the change back to a new address in Bruce's wallet.

To see the scripts, Blockchain.info gives a link "Show scripts & coinbase".  After you click that, scroll down to see the scripts.

To see the previous outputs for Bruce's payment, at the very bottom you'll see Advanced: Enable, click Enable.    Then next to Bruce's 1PvFignfc4H1hvUJU8EuoeUNMh7WtdJPgp input, you'll see the link Output which will bring you to the transaction in which Bruce received the 247.495 BTC.

That should give you about everything you need to know to have a general understanding about Bitcoin transactions.  There are further details, such as how BTCs don't exist ... there are only Satoshis.  (e.g., 188,000,000 Satoshis = 1.88 BTC).  And other scripts that might be used, etc.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
March 08, 2013, 08:40:50 AM
 #3

Then for how that transaction is used (as far as getting into the blockchain), see:



 - https://i.imgur.com/DKa2T7q.jpg  <--- Full size JPG, 1871 X 1420.


So in the example of Linda receiving 1.88 BTC, that amount will be added to the balance shown by her client until she has spent that transaction.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


NeonFlash (OP)
Full Member
***
Offline Offline

Activity: 198
Merit: 100



View Profile
March 08, 2013, 09:55:03 AM
Last edit: March 08, 2013, 10:05:47 AM by NeonFlash
 #4

Thanks Stephen for the details. I find blockchain.info very useful as well.

I have understood something now (I was wondering yesterday, why are there 2 addresses in the output. So, it means, one of them was the amount sent to the recipient and the other amount was returned to the other bitcoin address of the sender).

I am trying to understand in more detail, that what happens before all this?

Taking the same example further.

let's say, Bruce wanted to send 1.88 BTC to Linda.

In his wallet, he will enter the Bitcoin Address of Linda and click send.

Let's assume Bruce has two Bitcoin Addresses (1PvFignfc4H1hvUJU8EuoeUNMh7WtdJPgp and 1Gd2SRTE7GC6GHwtSaAeV7d1xhJ7t5iYJ6 ). Both these addresses were generated using his Bitcoin Wallet's private key.

To send 1.88 BTC to Linda, first the Bitcoin Client on Bruce's machine, has to scan the entire block chain and locate all the transactions corresponding to 1 of the above 2 Bitcoin Addresses where Bruce received some amount.

It will then use the latest transaction in the history corresponding to Bruce's Bitcoin Address.

This transaction will have an Output (which has a value and a Bitcoin Address stored in it? )

here, value corresponds to the Balance of Bruce's Bitcoin Address and the bitcoin Address is Bruce's own Bitcoin Address?

now, once the Bitcoin Client has located the latest transaction in the block chain, where Bruce received some amount, it will generate the Input Script to prove that Bruce is the owner of those BTC as mentioned in the Output of Transaction, correct?

This input script, will use the Public Key (corresponding to Bruce's Wallet) and a signature (generated using his Private Key). It will also have an index that links to the output of the Transaction (where Bruce received some amount).

Now, the output script, will verify that Bruce is indeed the owner of the BTC as mentioned in the Output part of the transaction. so, Bruce can claim them and use them to send to Linda?

So, the input and output scripts are only used to verify that Bruce is the owner of the BTC and can claim them. Then, this amount is sent directly to Linda?
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
March 08, 2013, 11:21:13 AM
Last edit: March 08, 2013, 11:48:56 AM by Stephen Gornick
 #5

Let's assume Bruce has two Bitcoin Addresses (1PvFignfc4H1hvUJU8EuoeUNMh7WtdJPgp and 1Gd2SRTE7GC6GHwtSaAeV7d1xhJ7t5iYJ6 ). Both these addresses were generated using his Bitcoin Wallet's private key.

The wallet.dat holds a collection of private keys.  Each private key yields a unique bitcoin address.  So the wallet doesn't have a single private key, it has many private keys, and each one can be hashed to come up with the corresponding Bitcoin address.

To send 1.88 BTC to Linda, first the Bitcoin Client on Bruce's machine, has to scan the entire block chain and locate all the transactions corresponding to 1 of the above 2 Bitcoin Addresses where Bruce received some amount.

Well the Bitcoin-Qt client will look at all unspent transactions of Bruce's (i.e., for any address in his wallet) and choose one or more based on a set of rules (which include minimizing the change amount, for example).

This transaction will have an Output (which has a value and a Bitcoin Address stored in it? )

So the two outputs are Linda's Address (with amount 1.88 BTC) and then the client pulls an unused address from the keypool and adds that as a second output (with the amount being the total input amount(s) less 1.88 BTC to Linda less the fee to give to the miner).

now, once the Bitcoin Client has located the latest transaction in the block chain, where Bruce received some amount,

Not necessarily the latest.  The specific unspent transaction used will be whatever one the client chose based on the client's ruleset.  This is different for different clients.  Bitcoin-Qt uses one method for coin selection, Armory uses its own, etc.

it will generate the Input Script to prove that Bruce is the owner of those BTC as mentioned in the Output of Transaction, correct?

No.  For this "transfer to bitcoin address" action, each output is simply:

Quote
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
- http://en.bitcoin.it/wiki/Transactions#Principle_example_of_a_Bitcoin_transaction_with_1_input_and_1_output_only

There's nothing in each OUTPUT other than the output instruction and the hash of the public key -- specifically RIPEMD160(SHA256(PubKey)).  And there's nothing that would indicate that one of the addresses happens to be an address that is from Bruce's own wallet.

All the signing and full public key is in each INPUT, not the OUTPUT.  Only during transaction verification are these two used together:

Quote
The input's scriptSig and the referenced output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true
- https://en.bitcoin.it/wiki/Transactions#Verification

[I'm not well versed on transactions at the script level so I may be describing it incorrectly so if anyone has corrections or comments feel free to share.]

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


NeonFlash (OP)
Full Member
***
Offline Offline

Activity: 198
Merit: 100



View Profile
March 08, 2013, 01:24:41 PM
 #6

I was trying to understand the verification process done using Input and Output Scripts.

So, for the transaction between Bruce and Linda, these scripts should look like:

Code:
Input:
Previous tx: <The hash of unspent Transaction of Bruce>
Index: 0 <This points to Output of the above Transaction>
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 (contains Pubkey of Bruce along with the signature of the message)

Output:
Value: 188000000
scriptPubKey: OP_DUP OP_HASH160 <Pub hash Key of Linda/Bruce?>
OP_EQUALVERIFY OP_CHECKSIG

on wiki for "transfer to Bitcoin Address", I have following questions:

Q #1. "A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey."

Here, the sender is Bruce? Which "full public key" are we talking about here? The public key corresponding to the private key of Bruce? or the public key corresponding to Linda's private key?

Q #2. "When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key."

In our example, it would be Linda providing the signature and public key? It is confusing when it says, "redeemng coins that have been sent to a Bitcoin address".


Q #3. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

This text is really not clear to me Smiley

I thought I understood it but I don't think so.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
March 11, 2013, 07:16:07 PM
 #7

I was trying to understand the verification process done using Input and Output Scripts.

So, for the transaction between Bruce and Linda, these scripts should look like:

Code:
Input:
Previous tx: <The hash of unspent Transaction of Bruce>
Index: 0 <This points to Output of the above Transaction>
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 (contains Pubkey of Bruce along with the signature of the message)

Output:
Value: 188000000
scriptPubKey: OP_DUP OP_HASH160 <Pub hash Key of Linda/Bruce?>
OP_EQUALVERIFY OP_CHECKSIG

on wiki for "transfer to Bitcoin Address", I have following questions:

Q #1. "A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey."

Here, the sender is Bruce? Which "full public key" are we talking about here? The public key corresponding to the private key of Bruce? or the public key corresponding to Linda's private key?

Linda's pub key.

Quote
Q #2. "When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key."

In our example, it would be Linda providing the signature and public key? It is confusing when it says, "redeemng coins that have been sent to a Bitcoin address".

no, Bruce has to provide his sig and the pub key associated with the address he's spending from.

Quote
Q #3. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

This text is really not clear to me Smiley

I thought I understood it but I don't think so.

Bruce has to provide his pub key when spending from his address.  the script performs a hash on that pub key to make sure it corresponds to the address.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
March 13, 2013, 04:21:23 AM
 #8

Q #1. "A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey."

Here, the sender is Bruce? Which "full public key" are we talking about here? The public key corresponding to the private key of Bruce? or the public key corresponding to Linda's private key?

Linda's pub key.

Bruce's client does not know Linda's public key.  Bruce knows Linda's Bitcoin address.

In the wiki article it reads "<pubKeyHash>".  I believe that can be used interchangeably with Bitcoin Address.    But it is not Public Key.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
March 13, 2013, 05:14:23 AM
 #9

Q #1. "A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey."

Here, the sender is Bruce? Which "full public key" are we talking about here? The public key corresponding to the private key of Bruce? or the public key corresponding to Linda's private key?

Linda's pub key.

Bruce's client does not know Linda's public key.  Bruce knows Linda's Bitcoin address.

In the wiki article it reads "<pubKeyHash>".  I believe that can be used interchangeably with Bitcoin Address.    But it is not Public Key.

correct.  neon asked who's pub key can't be provided in scriptPubKey.  answer:  Linda's.

so instead Bruce signs his coins over to Linda's hash160=Bitcoin address.
wingding
Hero Member
*****
Offline Offline

Activity: 770
Merit: 504



View Profile
April 17, 2013, 02:24:19 PM
 #10

I have one question related to this: Do the miner check the validity of all transactions that he puts into his new block? What if Bruce write his own wallet that can send more coins than he posess?
DannyHamilton
Legendary
*
Offline Offline

Activity: 3486
Merit: 4801



View Profile
April 17, 2013, 05:06:31 PM
 #11

I have one question related to this: Do the miner check the validity of all transactions that he puts into his new block? What if Bruce write his own wallet that can send more coins than he posess?

Not only the miners, every peer checks the validity of every transaction before they accept and relay it.

If Bruce tries to send a transaction to his connected peers that attemtps to spend an output hash that doesn't exist in the blockchain (or list of unconfirmed transactions), or attempts to spend an output hash that he can't provide a proper signature for, every peer he's connected to will refuse to accept and relay the transaction.  The transaction will therefore never make it off his computer onto the network.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!