Bitcoin Transactions
Honestly, initially, this lecture sounded intimidating. He’s like “we’re going to talk low level, real scripts, details and structure of bitcoin scripts in a precise way”. I had flashbacks of x86 machine code taunting me. Don’t be afraid though, it was well presented and well paced.
Also if you watch this lecture, count how many times the word “real” gets used?
Questions answered in this Post:
- What arguments makes transaction based ledger more suitable than account based for bitcoin?
- What are the components of a transaction?
- Explain the reason for a change address.
Bitcoin Consensus gives us:
- Append only ledger
- Decentralized consensus
- Miners to validate transactions (making sure transactions are well-formed)
Assuming a currency exists to motivate miners!
He started out with this chart of what an account-based ledger (not Bitcoin) looked like before showing the bitcoin based ledger. The issues with this account-based ledger is that everyone needs to keep track of the account balances.
Transaction Based Ledger (Bitcoin)
Transaction | Input | Output | Signed |
---|---|---|---|
1 | 0 | 25 ->Alice | no one |
2 | 1[0] | 17 ->Bob,8 -> Alice | signed(Alice) |
3 | 2[0] | 8 -> Carol,9-> Bob | signed by Bob |
4 | 2[1] | 6 -> David,2 -> Alice | signed by Alice |
2[1] mean transaction 2 output 1
This is all implemented with hash pointers which have been covered in week 1 as well as building upon it constantly. Thus by the time transaction 4 occurs, there is now a long chain. Transaction specific the number of inputs and number of accounts and thus keep track of the state.
For these transactions it’s important to note that when Alice gives 17 coin to Bob, she also needs to give 8 coin back to herself.
Change Address – because coins are immutable, the entirety of a transaction output must be consumed by another transactions. The left over amount that has the potential for being given back to the original input still has a transaction to receive the coin.
Efficient Verification This new ledger means that you do not have to go up the entire change. You only need to scan the block chain between a reference transaction (input) and the latest block.
Join Payments instead of doing 2 transactions
Transaction | Input | Output | Signed |
---|---|---|---|
2 | 1[0] | 17 ->Bob, 8 -> Alice | signed(Alice) |
3 | 2[1] | 6 -> Alice, 2-> Bob | signed(Alice) |
4 | 3[0], 3[1] | 8 -> David | signed by Alice, Bob |
There seems to be quite a few issues on the video which are mentioned below. I have changed the examples to reflect these inconsistencies.
https://www.coursera.org/learn/cryptocurrency/discussions/weeks/3/threads/ngwguLVDEeatew7zqUaXxg
Bitcoin transaction representation
{
"hash": "5a42...",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":0,
"size":404,
"in": [{
"prev_out":{"hash":"3be4",
"n":0},
"scriptSign":"3044"
}],
"out":[{
"value":"10.122",
"scriptPubKey":"OP_DUP OP_HASH160 69e... OP_EQUALVERIFY OP_CHECKSIG"}]}]}
3 parts
- Meta Data – Housekeeping that has size of trxn, # of input, # of output, and has of entire trxn
"hash": "5a42...",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":0,
"size":404
- Inputs – array of previous trxn (hash form)
prevTrans
Signatures - Outputs – contain the value and the sum of all output
value
Recipient Address? but its really a script