-
Notifications
You must be signed in to change notification settings - Fork 31
/
Week 3 : Mechanics of Bitcoin
816 lines (687 loc) · 40.5 KB
/
Week 3 : Mechanics of Bitcoin
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
--------------------------------------------------------------------------------------------------------------------------------------
3.1 Bitcoin Transactions
--------------------------------------------------------------------------------------------------------------------------------------
Recap : Bitcoin consensus
Bitcoin consensus gives us:
1. Append-only ledger - datastructure that we can only write to and once data is there , it's forever.
2. Decentralized consensus - decentralized protocol for establishing the value of that ledger.
3. Miners to validate transactions. (no double spends);
I. An account-based ledger (not Bitcoin)
------------------
(Simplification : only one transaction per block)
---------------------------------------------------------
| |Create 25 coins and credit to Alice (Asserted by Miners) |
| -----------------------------------------------------------
t| | Transfer 17 coins from Alice to Bob (Signed by Alice) |
i| -----------------------------------------------------------
m| | Transfer 8 coins from Bob to Carol (Signed by Bob) |
e| -----------------------------------------------------------
| | Transfer 5 coins from Carol to Alice (Signed by Bob) |
| -----------------------------------------------------------
| | Transfer 15 coins from Alice to David (Signed by Alice) | <- Is this valid? Requires to know the data in each members account
| ----------------------------------------------------------- Need to go back to the history(account, genesis to keep track)
\ /
It is an infinite backward scan, because of the need to keep track of transactions - and add them up tally the transaction - Bitcoin doen't follow an account-based ledger;
Bitcoin uses a ledger that keeps track of transactions.
II. A transaction-based ledger (Bitcoin)
-----------------------------------------'
(Simplification : only one transaction per block)
| -----------------------------------------------
| |1 |
| | Inputs: ∅ | (First transaction)
| | Outputs: 25.0 -> Alice |
| | |
| -----------------------------------------------
T| |2 |
I| | Inputs: 1[0] |
M| | Outputs: 17.0->Bob, 8.0->Alice |
E| | (Signed by Alice)|
| -----------------------------------------------
| |3 |
| | Inputs: 2[0] |
| | Outputs: 8.0->Carol, 7.0->Bob |
| | (Signed by Bob)|
| -----------------------------------------------
| |4 |
| | Inputs: 2[1] | <- Is it valid ? (Finite scan to check validity)
| | Outputs: 6.0->David, 2.0->Alice |
| | (Signed by Alice)|
| -----------------------------------------------
|
\ /
-> Transactions explicitly specify the number of inputs and the number of outputs.
-> Transactions also have a unique identifier - here noted by serial number, by actually implemented via "hash pointer";
-> Transaction 1 -> No input since it is newly created , but an output of 25 coins going to Alice, and since it is a new transaction no new coins are created here.
-> Transaction 2 -> Alice wants to send coins to Bob;
Inputs : 1[0] -> 25.0 coins
Outputs : (2) -> Bob (17); (Remainder) -> 8 coins -> payed to change address -> Back to Alice;
Signed by Alice -> validation of the transaction.
**** Always completely need to consume the output of the previous transaction.
-> Here it is much easier to look at the transaction and know whether the transaction is valid or not. It requires a finite scan.
Example: Transaction 4 (By looking at the previous transaction 2[1] -> able to validate the transaction)
Inputs : 2[1] -> Signed By Alice -> Value = (2nd block, 2nd output) = 8;
Outputs : 6.0 -> David, 2.0 -> Alice; = total bitcoins = 8
* Joint Payments
----------------------
| -----------------------------------------------
| |1 |
| | Inputs: ∅ | (First transaction)
| | Outputs: 25.0 -> Alice |
| | |
| -----------------------------------------------
T| |2 |
I| | Inputs: 1[0] |
M| | Outputs: 17.0->Bob, 8.0->Alice |
E| | (Signed by Alice)|
| -----------------------------------------------
| |3 |
| | Inputs: 2[0] |
| | Outputs: 8.0->Carol, 7.0->Bob |
| | (Signed by Bob)|
| -----------------------------------------------
| |4 |
| | Inputs: 2[1] |
| | Outputs: 6.0->David, 2.0->Alice | ----
| | (Signed by Alice)| | 6 -> David
| ----------------------------------------------- | 2 -> Alice
| |5 | |
| | Inputs: 4[0], 4[1] | <--|
| | Outputs: 6.0->Bob | <--- Joint Payment (2 inputs, 1 outputs)
| | (Signed by David) , (Signed by Alice)| <--- 2 Signatures
| -----------------------------------------------
|
\ /
The real deal : A Bitcoin transaction
--------------------
-> It's actually a compact binary format of the data shown that it gets compiled into.
-> Data structure - 3 parts - Metadata, inputs, outputs.
1. Metadata
{
transaction hash -> "hash" : "5a57fdg93....2443",
"ver":1,
housekeeping "vin_sz":2,
"vout_sz":1,
"lock_time":0, **
"size":404,
....
}
2. Input
"in": [
{
"prev_out": {
"hash": "3be4...89gfh", <----- Previous transactions
"n":0
},
"scriptSig": "3f3we46", <----- Signatures
},
....
],
3. Output
"out": [
{
"value": "10.235969544", <-- Each output can have value.sum(output) < sum(input)
"scriptPubKey": "OP_DUP_OP_HASH89324..568 <---- Script - with public key
OP_EQUALVERIFY OP_CHECKSIG"
},
...
]
Q . In a typical transaction
a. There is one signature that covers all the inputc - false
b. Each input contains a signature - true
c. There is one signature that covers all the output - false
d. Each output contains a signature - false
--------------------------------------------------------------------------------------------------------------------------------------
3.2 Bitcoin Scripts
--------------------------------------------------------------------------------------------------------------------------------------
-> Each transaction output key scpecifies and script.
"out": [
{
"value": "10.235969544", <-- Each output can have value.sum(output) < sum(input)
"scriptPubKey": "OP_DUP_OP_HASH89324..568 <---- Script - with public key
OP_EQUALVERIFY OP_CHECKSIG"
},
...
]
* Inorder to redeem a previous transaction by signing with the correct public key
-> Input "address" and output "address" are both scripts, they are concatenated together and run, if successful it is a valid. transaction.
----------------------------
scriptSig 304521245522...
45344gsjdui9... input
-----------------------------
OP_DUP
scriptPubKey OP_HASH160
69efrfg18.. output
OP_EQUALVERIFY OP_CHECKSIG
-----------------------------
* Bitcoin scripting language ("Script")
------------------
Design goals
1. Built for Bitcoin (inspired by Forth)
2. Simple, compact
3. Support for cryptography (hash functions, compute signatures, verify signatures, etc)
4. Stack-based language
5. Limits on time / memory
6. No looping
Bitcoin script execution example
------------
-> If data is seen it's pushed onto the stack.
-> Here - write data into the memory (stack);
<sig> <pubkey> OP_DUP OP_HASH160 <pubKeyHash?> OP_EQUALVERIFY OP_CHECKSIG
# OP_DUP -> take value on top of the stack, pop off, and write two copies back to stack.
# OP_HASH160 -> Take the value on top of stack and compute cryptographic hash of it.
# OP_EQUALVERIFY -> Check if the two values at the top of stack equal.
# OP_CHECKSIG -> Verify the signatures
* Stack structure -> command by command
------
<sig> <pubkey> OP_DUP OP_HASH160 <pubKeyHash?> OP_EQUALVERIFY OP_CHECKSIG
i. <sig>
----------
| <sig> |
----------
ii. <pubkey>
------------
| <pubkey> |
------- ---
| <sig> |
-----------
iii. OP_DUP
------------
| <pubkey> |
------------
| <pubkey> |
------- ---
| <sig> |
-----------
iv. OP_HASH160
-------------
|<pubkeyhash>|
--------------
| <pubkey> |
------- ----
| <sig> |
-------------
v. <pubKeyHash?>
-------------
|<pubKeyHash?>| <--sender
--------------
|<pubkeyhash> | <- recipient
--------------
| <pubkey> |
-------------
| <sig> |
-------------
vi. OP_EQUALVERIFY - consumes <pubkeyhash> and <pubkeyhash?>
--------------
| <pubkey> |
-------------
| <sig> |
-------------
vii. OP_CHECKSIG - > checks the transaction signature. -> pops the commands from the stack, public key is already verified.
* Bitcoin script instructions
------------------------------
* Small -> 256 opcodes total (15 disable, 75 reserved)
* Arithmetic
* If/then
* Logic/data handling
* Crypto!
* Hashes
* Signature Vwerifications
* Multi-signature verification -> Instruction -> OP_CHECKMULTISIG
* OP_CHECKMULTISIG
--------------------
-> Built-in support for joint signatures
-> Specify n public keys
-> Specify t (threshold)
-> Verifications requires t signatures (t of n signatures need to be valid);
# Bug: Extra data-value popped off and ignored;
* Bitcoin scripts in practice (2014 ->)
-------------------------------
1. Most nodes whitelist known scripts.
2. 99.9% - simple signature check.
3. ~0.01% are MULTISIG
4. ~0.01% are Pay-to-Script-Hash
6. Remainder are error, proof-of-burn scripts.
* Proof-of-burn script
---------------------
-> It can never be redeemed , those coins have been destroyed and can't be used again.
-> OP_RETURN
-> Used for:
a. <arbitrary data> -> (stays forever) timestamp, write something in exchange for a little loss of Bitcoins.
b. use alternative coin to bitcoin.
* Pay-to-Script-Hash script
-----------------------------
* Rather than the sender having to send a script as an address they just send a hash of the script.
* Eventaully added to BITCOIN.
STEP 1 STEP 2
(redemption script has right hash) (redemption script-desearalized - actual signture check)
---------------------------- ----------------------------
Recipient <signature> <signature>
<<pubkey> OP_CHECKSIG>
----------------------------- ----------------------------
OP_HASH160
Sender <hash of redemption script> <pubkey>
OP_EQUAL OP_CHECKSIG
----------------------------- ----------------------------
Q. Bitcoin’s script supports instructions whose effect is: (check all that apply)
a. Adding two numbers - true
b. Conditional execution (if/then) - true
c. Looping - false
d. Recursion - false
e. Hashing - true
--------------------------------------------------------------------------------------------------------------------------------------
3.3 Applications of Bitcoin scripts
--------------------------------------------------------------------------------------------------------------------------------------
1. Escrow Transactions
---------------------
-> Online Transactions
Example:
- Problem : Alice wants to buy online from Bob. Alice doesn't want to pay until Bob ships. Bob doesn't want to ship until after Alice pays.
- Solution : Introduce a third party and do ("escrow" transaction);
Alice <----------------------------------------------------------------> Bob
---------------------------------------------
| Pay x to 2-of-3 Alice, Bob, Judy (MULTISIG) |
| (signed Alice)|
-----------------------------------------------
# Alice will not pay directly to Bob, but will instead create a MULTISIG transaction that requires two or three signatures to redeem a coin (Say -> Alice, Bob, , Judy) - Judy is a Judge that comes into place in case of any disputes.
# Alice creates the transaction with the desired amount with 2-out of 3 MULTISIG between Alice, Bob and Judy.
# Alice signs the transaction redeeming some coins that she owns and this will get published in the Block-chain.
# At this point, the coins are held in "escrow" between Alice, Bob and Judy and any two of them can specify where the coins should go.
# Bob is now satisified and is safe to send the goods over to Alcie,
# In normal case (hope) Alice and Bob are both honest and goods arrive on time and Alice wants to release the amount from escrow so that Bob receives the money.
# If the above situtation occurs then Alice and Bob can both sign a transaction, redeeming the funds from escrow and consuming it. Moreover Judy din't have to get involved in the transaction, no dispute.
(normal case)
____________________________________________
| Pay x to Bob |
| SIGNED(ALICE,BOB) |
|___________________________________________|
_________________
/ /|
/________________/ |
| | |
| To :Alice | |
| From: Bob | /
|________________|/
Alice <----------------------------------------------------------------> Bob
---------------------------------------------
| Pay x to 2-of-3 Alice, Bob, Judy (MULTISIG) |
| (signed Alice)|
-----------------------------------------------
# In case the transaction fails -> goods are lost, not delivered then Alice doen't want to pay and wants to get back her money.
# In this case both Alice and Bob are both not gonna sign a transaction and release the money to Bob, or deny Alice'd fraud claim.
# Judy get involved to solve the dispute, she will sign the transaction with the honest party . Here there will be 2-out-3 signatures to release the money from the transaction.
- Alice is honest, Judy, Alice sign the transaction and money is refunded to Alice.
- Bob is honest, Judy, Bob can sign a transaction and money sent to Bob.
(dispute case)
____________________________________________
| Pay x to Alice |
Judy | SIGNED(ALICE,JUDY)|
|___________________________________________|
_________________
/ /|
/________________/ |
| | |
| To :Alice | |
| From: Bob | /
|________________|/
Alice <----------------------------------------------------------------> Bob
---------------------------------------------
| Pay x to 2-of-3 Alice, Bob, Judy (MULTISIG) |
| (signed Alice)|
-----------------------------------------------
-----------------------------------------------------
(dispute case)
____________________________________________
| Pay x to Bob |
Judy | SIGNED(BOB,JUDY) |
|___________________________________________|
_________________
/ /|
/________________/ |
| | |
| To :Alice | |
| From: Bob | /
|________________|/
Alice <----------------------------------------------------------------> Bob
---------------------------------------------
| Pay x to 2-of-3 Alice, Bob, Judy (MULTISIG) |
| (signed Alice)|
-----------------------------------------------
2. Green Address
-----------------
Problem : Alice wants to pay Bob. Bob can't wait 6 verifications to guard against double-spends, or is offline completely.
(To send money to a person using Bitcoin without the recipient being able to access the block-chain - need to introduce another third party which is the bank).
(Green Address - provides a means to do payments quickly without accessing the block-chain).
-> Alice contacts the Bank and asks them to help transfer money to Bob.
-> Bank debits amount from Alice's Bank account and draws a transaction from one of the Banks green address to Bob, and some amount to the bank itself.
-> Since money is coming from the bank , the bank assures/guarentees there is no double spend and the address (green address) - bank controlled address.
-> Bob gets the transaction and can choose to accept it based on the banks guarentees and can evetually be uin the block-chain.
-> This is not a Bitcoin enforced guarantee, but instead it is a real-world guarantee.
-> Two most prominent services that implemented green addresses - Instawallet and Mount Gox both collapsed. Therefore not popular protocol.
Bank
payment / |
/ |
/ \ /
/ _____________________________________________ (out of network/block-chain)
Alice | Pay x to Bob, y to Bank (No double spend) | Bob
| SIGNED(BANK) |
|_____________________________________________|
3. Efficient micro-payments
-----------------------------
Problem : Alice wants to pay Bob for each minute of phone service. She doesn't want to incur transaction fee every minute.
- It won't be optimum to create a Bitcoin transaction for every minute Alice is on call. then the transaction fee incured will be too high for the service. Too many transaction fees - not optimum.
-> Solution: Create a low value transaction for every minute that Alice talks on phone. There is a problem with this system is that the transactions might all be very low value and the transaction fees might be too high.
-> Required solution : Combine all these small payments into one big payment at the end. It can be done with serial micro-payment.
# Start with a MULTISIG transaction that pays the maximum amount Alice would ever need to spend to a MULTISIG transaction requiring both Alice and Bob to sign to release the coins.
# After 1 minute of the service, Alice signs the transaction spending those coins signed in the MULTISIG address, sending one coin to Bob and returning the rest to Alice.
# After 2nd minute, Alice signs another transaction this time paying 2 coins to Bob and rest to herself.
# Alice is gonna keep sending these transactions to Bob.
# These transactions are not getting published in the block-chain.
# Evetually Alice is done with the service and notifies Bob.
# Bob then takes the last transaction -> signs it and that gets published in the Block-chain.
# (Technically all the above transactions are double-spends )
-----------------------------------------------------------
| Input : x Pay 42 to Bob, 58 to Alice |
all | SIGNED(ALICE) SIGNED(BOB)|
are -----------------------------------------------------------
double ....
spends
-----------------------------------------------------------
| Input : x Pay 02 to Bob, 98 to Alice |
| SIGNED(ALICE)___________ |
------------------------------------------------------------
| Input : x Pay 01 to Bob, 99 to Alice |
| SIGNED(ALICE)___________ |
------------------------------------------------------------
Alice Bob
-----------------------------------------------------------
| Input : y, Pay 100 to Bob/Alice (MULTISIG) |
| SIGNED(ALICE)|
------------------------------------------------------------
# Issue -> In case Bob doesn't sign the last payment made by Alice, and is happy to let the coins sit in escrow, but Alice will be out of full value that she paid at the beginning.
*** Solution -> Feature - "Lock Time"
- Even before the micro-payment protocol can begun, Alice and Bob will both sign a transaction which will refunds all of Alice's money back to het, but is locked until sometime in the future.
- Even before the first minute service begins, Alice must await the refund transaction from Bob.
- If she makes it to time t and Bob hasn't signed the small transaction Alice has sent.
- Alice can publish this transaction (refund-agreement with Bob) which refunds all the money back to her. (Safety Valve)
-> Bitcoin Data structure - 3 parts - Metadata, inputs, outputs.
* Metadata
{
transaction hash -> "hash" : "5a57fdg93....2443",
"ver":1,
housekeeping "vin_sz":2,
"vout_sz":1,
"lock_time":315415, ******
"size":404,
....
}
-> If the lock-time has value other than 0, then that tells moners to not publish this transaction until the time soecified in the variable "lock_time".
"LOCK_TIME" - Bindex or real-world timestamps before which transactions can't be published.lock
4. Multi-player lotteries -> complicated - multi-step protocol, lot of transactions, lock_time, escrow - cheat safety.
5. Hash pre-image challenges. - brute-force;
6. Coin-swapping protocols.
Q1 . Alice is paying for a service using Bitcoin micropayments. If she simply disconnects at some point without notifying Bob and stops sending micropayments, what can Bob do?
a. Bob is out of luck. He doesn’t earn any Bitcoins and must pursue legal recourse - false
b. Bob can redeem the maximum amount that Alice initially escrowed into a multisig address - false
c. Bob can redeem the latest micropayment transaction that Alice sent in the last time period before disconnecting, which matches the length of service she received - true
d. Bob can refuse to sign the refund transaction, so both Alice and Bob will end up losing Bitcoins, which will sit in the multisig escrow forever - false
Q2 . Bitcoin micropayments require the use of: (check all that apply)
a. Multisignature Transactions - true
b. Proof of burn - false
c. Time-locked transactions - true
d. pay-to-script-hash - false
--------------------------------------------------------------------------------------------------------------------------------------
3.4 Bitcoin blocks
--------------------------------------------------------------------------------------------------------------------------------------
* Why bundle transaction together into blocks?
-----------------------------------------------
1. Single unit of work for miners. (If miners had to work on hashing and adding metadat for each transaction-> a lot of overhead.)
2. Limit length of hash-chain of blocks. (Faster to verify history)
* Bitcoin block structure
--------------------------
-> 2 different hash-based data structures.
1. Top -> hash-chain of blocks. Each block has a header and a pointer to a previous transaction.
2. Hash tree / Merkel tree - of transactions in each block.
Hash chain of blocks
--------------------------------------------------------------------------------------
| |
| -------------- ------------- -------------- |
| | | | | | | |
| | -------------- | ------------ | -------------- |
| | | prev: H( ) | | | prev: H( ) | | | prev: H( ) | |
| <------ -------------- <------- -------------- <--------- -------------- |
| |trans: H( ) | |trans: H( ) | |trans: H( ) | |
| -------------- ----------|--- -------------- |
| | |
-------------------------------------------------|------------------------------------
|
|
-----------------------|--------------------------------------
Hash tree / Merkel tree | \ / |
of transactions in | --------------- |
each block. | | H( ) H( ) | |
| ----|-------|--- |
| -------- --------- |
| | | |
| \ / \ / |
| --------------- -------------- |
| | H( ) H( ) | | H( ) H( )| |
| ---|------|---- ---|-------|-- |
| / | | \ |
| / | | \ |
| / | | \ |
| \ / \ / \ / \ / |
| transaction transaction transaction transaction |
| |
--------------------------------------------------------------
* A Bitcoin block
------------------
-> It has two parts - block header and transaction data (Merkel tree).
1. Header:
{
"hash": "000000000000000001aad2....",
"ver":2,
"prev_block": "000000000000000003043.....",
"time":12355745434,
"bits":14555344,
"nonce":45323458,
"mrkl_root":"434547554...",
...
}
-> mining puzzle information -> hash, bits, nonce.
-> Hash of the block-haeder - must start with a lot of 0's to be valid.
-> Header is the only thing that is hashed during the mining. To verify the chain of blocks - all to do is look at the headers.
-> Only transaction data included in the header is -> "mrkl_root".
2. coinbase transaction - special transaction -> creation of new coins -> almost similar to normal transaction.
value -> 25BTC (It halves every 4 years) -> In practice it'll be more - includes Transaction fees.
Previous output hash -> 000000....000000000 -> since it is a new coin no antecendent.
coinbase -> parameter to add any value.
"in": [
{
"prev_out": {
"hash":"00000000.....000000", <--- null hash pointer - new coin
"n":42156635847
},
"coinbase":"..."
},
"out":[
{
"value":"25.035455654", <- 25 - blockreward, 0.35.. - transaction fee
"scriptPubKey":"OPDUP OPHASH160 ..."
}
]
* Website -> blockchain.info [bitcoin - public data structure]
Q. Blocks contain a tree of transactions instead of a flat list because
a. It results in smaller blocks - false
b. It’s easier to insert or delete new transactions while the block is being assembled - false
c. It enables efficiently proving that a transaction is included in a block - true
--------------------------------------------------------------------------------------------------------------------------------------
3.5 Bitcoin Network
--------------------------------------------------------------------------------------------------------------------------------------
-> It is a P2P network, where all nodes are equal.
-> It runs over TCP and has a random topology - random nodes are peered with random other nodes.
-> New nodes can join at any time. (So you can download the Bitcoin client today -> spin the computer as a node -> participating Bitcoin node - with equal rights and capabilities as the other nodes).
-> Network is dynamic, forget non-responding nodes after 3 hours.
* Join the Bitcoin P2P network
-------------------------------
-> Networks connect to other nodes in a random fashion.
-> Launch a new node and want to join the network.
# start with a simple message to get to one node(seed node) on the network.
# Find the seed node and send a special message - asking for all the peers of the seed node.
# The contacted seed node replies with peered nodes.
# The newly launched node then contacts the seed nodes peers and asking the new seed nodes for their peers.
# Eventually a list of peers will be gathered by the newly lauched node - which then chooses which ones to peer with.
# Then the new node will be a fully functional node in the Bitcoin network. (Memeber of the blockchain);
* Transaction propagation (flooding)
------------------------------------
-> Network maintains the block-chain, so if any transaction is to be published, the entire network needs to know about it.
-> There is a simple flooding algorithm that takes care of it.
# Consider node 4, hears about a new transaction (Alice ->Bob);
# Node 4 communicates the transaction to its peers. Each node maintains a list of all transaction. New transactions are added into the list of the Peer nodes as well.
# In case peer node as already added the transaction into the list, on listening to the same transaction it will notify the node that it has heared the transaction already (memory pool). (won't loop)
# Eventually it stops when all the nodes have noted it. Each transaction is uniquely identified by a hash.
* How do nodes decide when they hear about new transaction whether or not they should propagate it?
-------------------------------------------
-> The nodes check if the transaction is valid w.r.t the current block chain.
Sanity-checks: (Some nodes may ignore them)
-> (default) script matches a whitelist (Avoid unusual scripts).
-> Haven't seen before conditions (Avoid Infinite loops).
-> Doesn't conflict with others relayed (Avoid double-spend)
* Nodes may differ on transaction pool
---------------------------------------
-> Node 1 - hears a new transaction(Alice -> Charlie), node 1 forwards it to its peers and so on.
-> Node 4 - hears a new transaction(Alice -> Bob), node 4 forwards it to its neighbours, etc. (node 1 message hasn't reached node 4);
-> Other nodes in between say node 6 between 1 and 4 has already received message from node 1 and hence refuses to enlist node 4's message.(Conflict) (Race condition).
-> Network is in a divided state.
-> This is fine, since the transaction has not been published yet - eventually nodes will sort it.
* Race Condition
-----------------
-> Transactions or blocks may conflict.
-> Depends on who mines next and decides which of the two pending transactions should endup being put permanently into the block. Other nodes will see the transaction, then nodes that bear the alternative transaction drop it , since it will account as a double-spend -> invalid.
- Default behavior : accept what you hear first.
- Network position matters.
- Miners may implement other logic!
* Block propagation -> similar to transaction propagation -> flooding algorithm
--------------------
-> Nodes compute the hash and validate the block.
-> Relay a new blocks when you hear it if:
- Block meets the hash target. (hash -> begin with lot's of 0's)
- Block must have all valid transactions. (Rum all scripts, even if it won't relay).
- Block builds on the current longest chain (Avoid forks).
* Block Propagation time
--------------------------
Block size (KB) (x-axis) V/s Time (sec) (y-axis)
- 75% - takes > 30sec (long) -> not an efficient algorithm;
- block needs to reach all nodes.
* How big is the network?
-------------------------
-> Impossible to measure exactly.
-> Estimates-up to 1M IP addresses/month
-> Only about 5-10k "full-nodes"
- Permanently connected.
- Fully-validated.
-> This number maybe dropping!
* Fully-validating nodes
-------------------------
-> Permantelty connected.
-> Store entire block chain.
-> Hear and forward every node/transaction.
-> Currently, it takes 20GB to store the entire block-chain.
-> Track the UTXO set
- Unspent Transaction Output (Everything else can be stored on disk)
- Currently ~12 M UTXOs (Out of 44 M transactions)
- Can easily fit into RAM.
* Thin / SPV(Simple Payment Verification) client (not fully validating)
--------------------------------------------------
-> Idea : don't store everything.
- Store block headers only.
- Request transactions as needed. (To verify incoming payments).
- Trust fully-validating nodes.
1000x cost saving! (20GB-23MB)
Q. If two conflicting transactions A → B and A → C are both broadcast almost simultaneously from different nodes, what determines which one will eventually end up in the block chain?
a. The transaction that reaches the majority of nodes first will win
b. The transaction that was broadcast first will win
c. The miner who finds the next block will likely resolve the tie by including one of the transactions in the block - true
d. Each node has its own version of the block chain containing the transaction that it heard about first
--------------------------------------------------------------------------------------------------------------------------------------
3.6 Limitation & Improvements
--------------------------------------------------------------------------------------------------------------------------------------
* Hard-coded limits in Bitcoin
-----------------
1. 10min average creation time pwer block.
2. 1M bytes per block.
3. 20,000 signature operations per block.
4. 100 M satoshis per bitcoin. (Satoshi -> smallest unit of the bitcoin currency recorded on the block-chain);
5. 21M total bitcoins maximum.
6. 50,25,12.5 ... bitcoin mining rewards.
* Throughput limit in Bitcoin
------------------------------
(Throughput -> The amount of items that pass through the system/process).
# 1 M bytes/block (10 minutes)
# > 250 bytes/transaction
# 7 transactions/sec
* Compare to:
# VISA : 2000 - 10000 transactions/sec;
# PayPal : 50 - 100 transactions/sec;
* Cryptographic limits in Bitcoin
------------------------------------
# Only 1 signature algorithm - elliptic curve DSA - (ECDSA/P256).
# Hard-coded hash functions.
# Crypto primitives might break by 2040.
* "Hard-forking" changes to Bitcoin
-------------------------------------
-> Incase there is a need to upgrade the block-chain.
-> It could be possible that not all the nodes are upgraded on time this could lead to issues.
-> The upgarded nodes will still continue to process new blocks while the old nodes will be rejecting the new blocks.
-> Unfortunately, the old nodes will never catch up.
-> It's called "hard-fork" cause the block-chain will split based on which version of the protocol they are running on and will never join again.
* "Soft forks"
---------------
-> Observation : we can add new features which can only limit the set of valid transactions.
-> Need majority of nodes to enforce new rules.
-> Old nodes will approve.
-> Risk : Old nodes might mine new-invalid blocks.
-> New nodes in the network will be enforcing some new tighter set of rules.
-> Relying on enough nodes switching to new version of the protocol that will enable them to enforce new rules knowing that old nodes won't be able to enforce the new rules because thay haven't heard them yet.
-> Risk: Old nodes uighting be mining old invalid blocks - because they might be mining valid block but according to the new, strict rules the block is not valid anymore. Evetually the new nodes will reject the block and the old nodes will accept the reject and move on to the next version of the block-chain.(temporary fork)
* Soft fork example : pay to script hash
-----------------------
-> This was not present in the first version of the Bitcoin protocol.
Pay-to-Script-Hash script
-----------------------------
* Rather than the sender having to send a script as an address they just send a hash of the script.
* Eventaully added to BITCOIN.
STEP 1 STEP 2
(redemption script has right hash) (redemption script-desearalized - actual signture check)
---------------------------- ----------------------------
Recipient <signature> <signature>
<<pubkey> OP_CHECKSIG>
----------------------------- ----------------------------
OP_HASH160
Sender <hash of redemption script> <pubkey>
OP_EQUAL OP_CHECKSIG
----------------------------- ----------------------------
-> Old node view of the pay to hash script - It's hashing the data value and checking to see if it's equal to the specified value in the output script.
-> Old nodes never do the second step of the verification step in the pay to hash script. (signature check);
* Soft fork possiblities
-------------------------
What can be added with soft fork so the Pay to Hash script is successful?
-> New signature schemes.
-> Extra per-block metadata (new cryptographic scheme) - add this into the coinbase parameter and UTXO merkel tree data in each block can be pushed into the paraemter.
- Shove in the coinbase parameter.
- Commit to UTXO tree in each block.
Other changes might require Hard-fork
Hard forks
-----------
1. New op codes.
2. Change size limits.
3. Changes to mining rate.
4. Many small bug fixes. (In multisig instruction - it pops an extra value off the stack and that would require a hard fork.)
"Currently seem very unlikely to happen."
"Seem possible in alternative currencies -> altcoins."
Q. Which of the following requires a hard fork? (check all that apply)
a. Disabling the OP_SHA1 instruction
b. A requirement that each transaction have its outputs sorted by value in ascending (or non-decreasing) order
c. Increasing the maximum permitted size of blocks -> correct
d. Decreasing the maximum permitted size of blocks
e. Adding a new OP_SHA3 script instruction -> correct
--------------------------------------------------------------------------------------------------------------------------------------