-
Notifications
You must be signed in to change notification settings - Fork 31
/
Week 2 : How Bitcoin Achieves Decentralization
565 lines (491 loc) · 34 KB
/
Week 2 : How Bitcoin Achieves Decentralization
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
2.1 Centralization vs Decentralization
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------
- Almost no system is purely decentralized or centralized.
- Example : Email - follows the SMTP (Simple Mail transfer Protocol) - decentralized protocol, but dominated by centralized webmail services.
* Aspects of decentralization in Bitcoin:
1. Who maintains the ledger?
2. Who has authority over which transactions are valid?
3. Who creates new bitcoins?
4. Who determines how the rules of the system change?
5. How do bitcoins acquire exchange value?
* Beyond the protocol : exchanges, wallet softwares, service providers, etc
* Three aspects of bitcoins and where they fal on the centralization and decentralization spectrum:
1. Peer-to-peer network : (closest to decentralization)
- open to anyone,
- low barrier entry.
- Anybody can run a bitcoin node - download the software and run it.
2. Mining : (Not very decentralized)
- open to anyone.
- but requires a very high capital cost
- inevitable concentration of power
- undesirable;
3. Updates to softwares: (Not purely decentralized)
(Coenceptually anybody can look into the specifications and develop their own bitcoin node, but practically doesn't work so.)
- Core developers trusted by the community work on the softwares;
- Developers have great power;
----------------------------------------------------------------------------------------------------------------------------------------
2.2 Distributed consensus
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------
- A challenge to solve inorder to build a distributed e-cash system is called distributed consensus. (how to decentralize ScroogeCoin);
- Traditional Motivation - Distributed Systems
Big companies have thousands or millions of servers that form a massive distributed database and any action performed by users will be stored multiple databases. When a new comment, post, etc comes in then in the massive backend there might be multiple copies of this action. The server must ensure that all copies are saved in the respective databases or none are saved otherwise it could cause inconsistency in the database data.
- Distributed consensus protocol - (maps arbitrary keys to arbitrary values) it will enable multiple applications.
1. DNS (Domain Name System) - Distributed Domain Name System - mapping between human-understandable domain names io IP addresses.
2. Public key directory - Mapping between user email addresses and to their public keys.
3. Stock trades - who's transfered what units of which stock to whom.
4. Altcoins - (Altcoins are systems built on Bitcoin like principles to achieve different goals, currency systems, not-currency systems (DNS, PKD, stock trades));
* Technical definition of Distributed Consensus:
- Imagine there is a fixed number n, of nodes or processes, each of these nodes has some input value and then a consensus protocol happens, and the two requirements on this consensus protocol are:
a. The protocol should terminate and all correct nodes decide/agree on the same value.
b. This value must have been proposed by some correct node.
* Distributed consensus can work in bit-coin
--------------------------------------------
-> Bitcoin is a peer-to-peer system.
-----------------------------------
- When Alice wants to pay Bob: she broadcasts the transaction to all Bitcoin nodes.
____________________
Alice | signed by Alice | --------->
|--------------------| ---------> Nodes .....
| Pay to pk(bob): H()| --------->
|--------------------| --------->
* Structure of transaction (Similar to GoofyCoin) -
- Signed by Alice(This is required by the other nodes to verify it has actually come from Alcie), and
- has Bob public key (Address at which Bob wants to receive the bitcoin).
- Hash (way for Alice to link together this transaction/coin to her receipt of this coin from someone else previously).
* In case Bob's computer is not in the picture of the nodes, then if he wants to be notified that this transaction did occur and he got paid, he might have to run a bitcoin node that is in one of these peer-to-peer nodes, in order to listen in on the network and be sure that he received the transaction.
* How consensus could work in Bitcoin
-------------------------------------
- All nodes have a sequences of blocks of transactions they've reached consensus on.
- Each node has a set of outstanding transactions it's heard about.
- Could have a sequence of blocks that everybody has agreed upon. (Block - A sequence of transactions);
___________ ____________ ___________
| Tx | | Tx | | Tx |
----------- ------------ ------------
| Tx | | Tx | | Tx |
----------- ------------ ------------
| ... | | ... | | ... |
----------- ------------ ------------
| Tx | | Tx | | Tx |
----------- ------------ ------------
- Consider there are 3 nodes in the system - Each of whom proposes, has a input , a set of tranactions it has heard about.
- They execute together some consensus protocol and for the consensus protocol to succeed, you can select any valid block, even if it is a valid block propsed by only one node.
A
____________
| Tx |
------------
| Tx |
------------
| ... |
------------
| Tx |
------------
/\ /\
/ \
/ \
/ Consensus \
/ protocol \
\/ B <-------------> \/ C
___________ ___________
| Tx | | Tx |
----------- ------------
| Tx | | Tx |
----------- ------------
| ... | | ... |
----------- ------------
| Tx | | Tx |
----------- ------------
- For a block to be valid, all of these transactions must have the right crypto signatures, etc.
- Maybe the A block gets selected and gets added to the ceonsensus block chain and so forth.
A
___________ ____________ ___________ ___________
| Tx | | Tx | | Tx | | Tx |
----------- ------------ ------------ ------------
| Tx | | Tx | | Tx | | Tx |
----------- ------------ ------------ ------------
| ... | | ... | | ... | | ... |
----------- ------------ ------------ ------------
| Tx | | Tx | | Tx | | Tx |
----------- ------------ ------------ ------------
* Why consensus is hard
------------------------
1. Nodes may crash
2. Nodes may be malicious
-> Network is imperfect
a. Not all pairs of nodes are connected.
b. Faults in network.
c. Latency (Happens over the Internet) - no notion of global time (not all nodes can agree to a common ordering of events based on observing timestamps)
* Many impossible results (Due to the above issues)
--------------------------
a. Byzantine generals problem
b. Fischer-Lynch-Paterson (deterministic nodes): consensus impossible with a single faulty node.
* Some well-known protocols
---------------------------
-> Paxos - Never produces inconsistent result, but can (rarely) get stuck.
* Understanding impossibility results (consensus model)
-------------------------------------------------------
-> These results say more about the model than about the problem.
-> The models were developed to study systems like distributed databases.
[Bitcoin violates a lot of the assumptions that go into the models, therefore consensus in bitcoins work better in theory and practice];
* Bitcoin consensus: theory & practice
-----------------------------------------
-> Bitcoin consensus work better in practice than theory. Theory important to help predict unforseen attacks.
* Things Bitcoin does differently
----------------------------------
a. Introduces incentives:
- possible only because it's a currency.
b. Embraces randomness:
- Does away with the notion of a specific end-point (start-point, end-point);
- Consensus happend over long time scales - about 1 hour. (Even after that time, you are not sure if the transaction/block you are interested in has made it into the consensus block chain). (Instead as time goes on, the probability that it has made it goes higher and higher, and the probability of you making an assumption about the transaction reduces exponentially).
----------------------------------
Question 1: Which of these factors make distribution consensus hard?
a. Nodes may crash - Correct
b. Nodes may be taken over by malware - Correct
c. Encrypted messages may be intercepted and decrypted - Wrong
d. There is latency on the network - Correct
----------------------------------
Question 2:Why is Bitcoin able to reach consensus in practice despite this being a generally difficult problem?
a. Financial incentives cause participants to work together - Correct
b. Only small groups of nodes have to reach consensus rather than the network having to globally reach consensus - Wrong
c. The order of blocks doesn’t matter for consensus - wrong
d. Consensus only has to be reached over long time scales - Correct
----------------------------------------------------------------------------------------------------------------------------------------
2.3 Consensus without identity : the block chain
----------------------------------------------------------------------------------------------------------------------------------------
-> Nodes don't have persistent long term identities.
* Why identity?
----------------
a. Pragmatic : some protocols need node IDs.
b. Security : assumes less than 50% of the nodes are malicious.
* Why don't bitcoin nodes have identities?
--------------------------------------------
a. Identity is hard in a P2P (peer-to-peer) system (decentralized) (no central authority to assign and verify node creation)- Sybil attack (Sybil are just copies of nodes that a malicious adversary can create at will - pseudo participants).
b. Pseudonymity is a goal of Bitcoin. (You are not forced to put your identity inorder participate in the transaction).
* Weaker assumption : select a random node
----------------------
-> Analogy : lottery or raffle -> When tracking and verifying identities is hard, we give people tokens, tickets, etc.
-> Now we can pick a random ID and select the node.
* Key Idea: implicit consensus
---------------
-> In each round (multiple rounds - different block in the block-chain), random node is picked.
-> This node proposes the next block in the chain.
-> Others nodes implicitly accept/reject this block.
- by either extending it.
- or ignoring it and extending the chain from earlier block.
-> Every block contains the hash of the block it is extending.
* Consensus algorithm - Bitcoin (simplified - since assuming that the node is selected magically/ramndomly)
------------------------
1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. In each round a random node gets to broadcast its block.
4. Other nodes accept the block only if all the transactions in it are valid (unspent, valid crypto signatures, double spend);
5. Nodes express their acceptance of the block by including the hash in the next block they create.
* Why the Consensus algorithm works? What can a malicious node do?
--------------------------------------------------------------------
-> Consider a couple of blocks in the chain, assume that it extends to the left all the way back to the genesis block.
-> The pointer (<---) a block referring to what is the previous block that it extends by including the hash of the previous block within its own contents.
___________ ____________ ___________
| Tx | | Tx | | Tx |
----------- ------------ ------------
| Tx | | Tx | | Tx |
----------- ------------ ------------
| ... |<---| ... |<---| ... |
----------- ------------ ------------
| Tx | | Tx | | Tx |
----------- ------------ ------------
-> Consider a malicious attacker Alice attempts
--------------------------
1. Can she steal Bitcoins belonging to another user at a different address that she doesn't control?
(Nope, even if she can propose the next valid node, she cannot steal Bitcoins belonging to another user - since she cannot forge their signatures);
2. Can she prevent blocks of transactions from certain users into the valid block-chain - Deny service to Bob?
(Not really, if Bob's block doesn't make it into the next block that Alice proposes, then he can wait for another block until an honest node gets a chance to propose a block and then his transaction will be appended to the block-chain)
3. Double-Spending Attack
i. Consider Alice is a customer of some online merchant/website run by Bob who provides services in exchange for payment in Bitcoins.
ii. Alice goes to Bob's website and decides to buy an item, and pays for it in Bitcoins - Bitcoin transaction from her address to Bob's address and broadcasts it to the network.
iii. An honest node creates the next block, listens to this transaction(Alice -> Bob) and includes it in that block.
C(A) - coin belonging to Alice; B - Bob's address;
Transaction is a datastructure that contains Alice's signature, an instruction to pay to Bob's public key and also hash(pointer to transaction where Alice received it from somebody ... start of the block chain);
------------------------------------------------------------------------------------
| |
\ / |
___________ ____________ ___________ ___________ |
| Tx | | Tx | | Tx | | Tx | |
----------- ------------ ------------ ------------ |
| Tx | | Tx | | Tx | | Tx | -------------------|--
----------- ------------ ------------ ------------/ -- | signed by A | |
| ... |<---| ... |<---| ... | <----- | C(A)-> B | -------------------|--
----------- ------------ ------------ ------------\ -- | Pay to pk(B) : H(|) |
| Tx | | Tx | | Tx | | Tx | ----------------------
----------- ------------ ------------ ------------
iv. Consider a malicious node controller by Alice, she proposes the next block, ignores the current valid block and instead contains a pointer to the previous block - This is going to contain a transaction of coins rfom Alices to another address controller by Alice (A').
- This is a double spend - Alice creates a new transaction that transfers the coins to another address owned by her rather than to Bobs's address. (From the figure below, two completly different signatures and pointing to the same hash function.)
------------------------------------------------------------------------------------
| |
\ / |
___________ ____________ ___________ ___________ |
| / \ Tx | | Tx | | Tx | | Tx | |
---|------- ------------ ------------ ------------ |
| | Tx | | Tx | | Tx | | Tx | -------------------|--
---|------- ------------ ------------ ------------/ -- | signed by A | |
| |... |<---| ... |<---| ... | <----- | C(A)-> B | -------------------|--
---|------- ------------ ------------ / \ ------------\ -- | Pay to pk(B) : H(|) |
| | Tx | | Tx | | Tx | | | Tx | ----------------------
---|------- ------------ ------------ | ------------
| |
| | -------------
|__________________________________ | | |
| | -------------
------------------|--- |------| |
| signed by A | | -------\ --------------
------------------|--- | C(A) -> A' |
| Pay to pk(A'): H(|) | -------/ --------------
---------------------- | |
--------------
How do we know if the double spend is successful?
---------------------------------
- Depends on which transaction block ends up in the consensus chain.
- That is based on the fact the honest blocks are always extending the longest valid branch. (It is not easy to say - technically < - for other nodes to identify between valid or double-spend);
- If the double-spend block is successful it gets extended.
------------------------------------------------------------------------------------
| |
\ / |
___________ ____________ ___________ ___________ |
| / \ Tx | | Tx | | Tx | | Tx | |
---|------- ------------ ------------ ------------ |
| | Tx | | Tx | | Tx | | Tx | -------------------|--
---|------- ------------ ------------ ------------/ -- | signed by A | |
| |... |<---| ... |<---| ... | <----- | C(A)-> B | -------------------|--
---|------- ------------ ------------ / \ ------------\ -- | Pay to pk(B) : H(|) |
| | Tx | | Tx | | Tx | | | Tx | ----------------------
---|------- ------------ ------------ | ------------
| |
| | ------------- -------------
|__________________________________ | | | | |
| | ------------- --------------
------------------|--- |------| | | |
| signed by A | | -------\ -------------- -------------
------------------|--- | C(A) -> A' |<---- | |
| Pay to pk(A'): H(|) | -------/ -------------- -------------
---------------------- | | | |
-------------- -------------
How can a merchant(Bob) protect himself from this attack?
---------------------------
___________ ____________ ___________ | ______________ |
| Tx | | Tx | | Tx | | | | |
----------- ------------ ------------ | ------------- |
| Tx | | Tx | | Tx | | | | | ..... 6 confirmations
----------- ------------ ------------ | ------------- |
| ... |<---| ... |<---| ... | | | C(A) -> B | |
----------- ------------ ------------ | ------------- |
| Tx | | Tx | | Tx | | | | |
----------- ------------ ------------ | ------------- |
| |
| |
Hear about C(A) -> B transaction Confirmation 1
peer-to-peer n/w (0 confirmation)
-> Double spend probability decreases exponentially with the number of confirmations.
-> Most common heuristics : 6 confirmations.
* Summary
-----
i. Protection againsr invalid transactions is cryptographic but enforced by consensus.
ii. Protection against double spending is purely by consensus.
iii. Never sure if the transaction is in the consensus block.
* Question
----------
What can a malicious node do?
Create valid transactions originating from someone else’s address - false
Prevent a valid transaction from getting any confirmations - false
Ignore the longest valid branch rule when proposing a new block - true
----------------------------------------------------------------------------------------------------------------------------------------
2.4 Incentives and proof of work
----------------------------------------------------------------------------------------------------------------------------------------
-> Assumptions of nodes to be honest and not an adversary is problematic.
-> Can nodes that are honest be given some incentives?
-> Can we penalize nodes for creating adversay block-transactions into the chain?
------------------------------------------------------------------------------------
| |
\ / |
___________ ____________ ___________ ___________ |
| / \ Tx | | Tx | | Tx | | Tx | <---------------------|-Can we reward nodes that created these blocks?
---|------- ------------ ------------ ------------ | (No since nodes don't have identities)
| | Tx | | Tx | | Tx | | Tx | -------------------|-- (Decentralized approached needed to)
---|------- ------------ ------------ ------------/ -- | signed by A | | (incentivize nodes with units of currency);
| |... |<---| ... |<---| ... | <----- | C(A)-> B | -------------------|--
---|------- ------------ ------------ / \ ------------\ -- | Pay to pk(B) : H(|) |
| | Tx | | Tx | | Tx | | | Tx | ----------------------
---|------- ------------ ------------ | ------------
| |
| | -------------
|__________________________________ | | |
| | -------------
------------------|--- |------| |
| signed by A | | -------\ --------------
------------------|--- | C(A) -> A' | <---- Can we penalize the node that created this block?
| Pay to pk(A'): H(|) | -------/ -------------- (Problematic - since nodes don't have identities)
---------------------- | |
--------------
-> Everything so far is just a distributed consensus protocol. But now we utilize that currency has value.
* 2 sperate Incentive methods in Bitcoin
------------------------------------------
Incentive 1 : block reward
-------------------------
Node that creates a block gets to
a. include special coin-creation transactions in the block.
b. chooses recipient address of this transaction. (the node can chooses it's own address and thereby paying itself);
-> Value is fixed: currently 25 BTC, halves every 4 years. (2nr period - previously 50BTC);
-> Block creator gets to "collect" the reward only if the block ends up on long-term consensus branch!
In this incentive method: There's a finite supply of bitcoins
-> if every 4 years in halves (BTC value)-> geometric series then:
# Total supply : 21 millions.
# Block reward is how bitcoins are created.
# Run out in 2140. No new bitcoins unless rules change.
Incentive 2 : transaction fees
--------------------------------
-> Creator of transactions (not nodes , transaction) can choose to make output value less than input value.
-> Remainder is a transaction fee and goes to the block creator.
-> Currently purely voluntary, but eventually can get mandatory.
* Remaining problems to know - to get to decentralization in Bitcoins
---------------------------------------------------
1. How to pick a random node?
2. How to avoid a free-for-all due to rewards?
3. How to prevent Sybil attack? (An adversary might try to create a number of sybil nodes - malicious nodes - subvert the consensus chain);
-> Same solution for all the above 3 -> "Proof of Work".
* Proof of Work
----------------
-> Instead of picking a node we can approximate selecting a random node:
Select nodes in proportion to a resource that no one can monopolize (hope);
a. In proportion to computing power : proof-of-work (Allowing nodes to compete with each other by using their computing power and that will result in nodes being automatically being picked in that proportion).
b. In proportion to ownership (of currency) : proof of-stake
-> Equivalent views of proof of work
--------------
1. Select nodes in proportion to computing power.
2. Let nodes compete for the right to create blocks.
3. Make it hard to create new identities. (Helful against sybil attack - adbersary attempting to create malicious blocks);
* Hash puzzles
----------------
-> So far blocks were considered to just contain transactions, but consisder each block has a "nonce", "previous hash" -> points to the previous block, list of transactions.
-> For a node to successfully create a block it must create a hash output that matches that target size and this demands high computation power and is not very easy. In this manner picking a node for creating a block is random and decentralized.
-> To create a block , find nonce s.t.
H(nonce || prev_hash || tx || ... || tx) is very small
-------------
| nonce |
-------------
<----|-- prev_h |
-------------
| Tx |
-------------
| Tx |
-------------
<-------------------------------------- Output space of hash ---------------------------------------------------->
------------------------------------------------------------------------------------------------------------------
|*********|\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|
------------------------------------------------------------------------------------------------------------------
<-------->
Target space
-> If hash function is secure: only way to succeed is too try enough nonces until you get lucky.
-> This is the fundamental problem that a node faces when it needs to create a block.
-> Node are independently and always competing to solve hash puzzles and when one of then gets lucky and will find a random nonce that satisy the target zise prpoerty (hash small) - then that node gets to propse the next block. - "Decentralized".
* Three properties PoW (Proof of Work)
---------------------------------------
i.PoW property 1 : difficult to compute
- As of August : about 10^20 hashes/block; (target space - 1 / 10^20 of the output space);
- Only some nodes bother to compete - miners. (Bitcoin mining - process of repeatedly trying and solving hash puzzles);
ii. PoW property 2 : parametrizable cost
- Nodes on the peer-to-peer network will automatically re-calculate the target (target space as a fraction of the output space) every two-weeks.
- Goal : average time between blocks = 10 minutes (10 mintes needed , inorder to put the a lot of transactions in a block)
- Prob(alice wins the next block) = fraction of global hash power she controls.
- If Alice has minimg hardware that's about 0.1% of the total hash power, she will computer roughly one in every thousand blocks.
* Key security assumption ->
------
Attack infeasible if majority of miners "weighted by hash power" (computation power) follow the protocol.
* Solving hash puzzles is probabilistic
------
- Nobody can predict which nonce is used (instead trail and error) - Bernoulli trails.
- poisson process - distribution to find the next block.
- If a block is find now, then the next block will be found soon and there is a small probability that it will take a long time to find the next block.
p | 10 minutes
r |\ |
o D | \ |
b e | \ |
a n | \ |
b s | \ |
i i | \|
l t | | \
i y | | \__
t | | --- __________
y |------|-----------------------------------------
Time to next block (entire network)
# For an individual miner
# Mean time to find a block = 10 minutes / fraction of hash power;
-> Consider Alice has 0.1% of the hash power
-> Alice's chance to find the next block = 10 / 0.1% = 10 / 1 / 1000 = 10 * 1000 = 10000 minutes (several days);
iii. PoW propert 3 : trivial to verify -> gets rid of the centalization property
- Nonce must be published as part of block.
- Other miners simply verify that
H(nonce || prev_hash || tx || ... || tx) < target
Question 1:
Proof of work is a way to:
a. Select nodes in proportion to computing power (true)
b. Let nodes compete for the "right" to create blocks (true)
c. Make it impossible for one miner to act like many different miners (false)
Question 2:
A block in the block chain was found at time t. What is the probability that the next block was found at or before time t+10 minutes? Assume that the total hash power of the network stays constant.
a. More than 50T% - true
b. Lesss than 50% - false
c. Exactly 50% - false
----------------------------------------------------------------------------------------------------------------------------------------
2.5 Summary
----------------------------------------------------------------------------------------------------------------------------------------
* Mining Economics
--------------------
If mining reward (block reward + Tx fees) > Hardware + Electricity cost -> Profit
Complications:
a. fixed vs variable costs. (hardware - fixed cost, electricity - variable - incurred over time);
b. rewards depends on gloabl hash rate. (miners - gets block -> global power)
c. pay - dollars, payed - bitcoins; exchange rate matters;
d. miners can extebded other blocks.
* Terminology
--------------
1. Identities - No identities needed, any user can create a pseudonymous key pair at any moment , and any number of them.
2. Transactions - Messages that are broadcast to the Bitcoin peer-to-peer network - instructions to transfer a coin rfom one address to another.
3. P2P network - propagates all new transactions/blocks to all the Bitcoin peer nodes.
4. Block-chain & Consensus - security . transaction in the block-chain only after confirmations (>6) - part of the consensus chain;
Orphan block - blocks not a part of the consensus chain - due to double spend, network latency, invalid bliock, etc;
5. Hash Puzzles and Mining - Miners are special type of nodes that compete for creating new blocks and are rewarded for their efforts in terms of Bitcoins.
* Bitcoin has three types of consensus
---------
a. Value
b. State - record of which transactions are valid or occured.
c. Rules
* Bitcoin is bootstrapped
------------------
Security of block chain
/\ \
/ \
/ \
/ \/
health of mining value of
ecosystem currency
/ \ |
|___________________________|
* What can a "51% attacker" do?
----------------------
1. Steal coins from existing address ? (No cannot change the cryptography / digital signatures of underlying transaction in invalid blocks created by the attackers -> as these blocks will not be accepted into the consensus chain by honest nodes);
2. Suppress some transactions?
a. From the block chain -> yes, a block creator can subvert certain transactions into the block created by them
b. From the P2P network -> No, sinec P2P network cannot wholly be controlled by an adversary, eventually a certain honest node will pick up the valid tramnsaction block.
3. Change the block reward? - No cannot change the bit-coin reward installed the software of other valid nodes. (w.r.t changing the rules);
4. Destroy the confidence in Bitcoin? -> Yes;
Question 1:
A 51% attacker can potentially: (check all that apply)
a. Steal coins from an existing address - false
b. Make it unprofitable for other miners to mine - true
c. Change the block reward - false
d. Suppress transactions from the block chain - true
Question 2:
Which of the following are true? (check all that apply)
a.51% attacks are difficult because an adversary would need to control more than half of the nodes on the Bitcoin network - false
b.Proof-of-work is essential for preventing sybil attacks on the Bitcoin blockchain - true [proof-of-work - decentralizing the selectioon of node - compete for computation power]
c.As a transaction gets buried deeper in the blockchain, it becomes less and less likely that it will ever be undone because the work required to make a longer alternate branch becomes more and more difficult - true.
----------------------------------------------------------------------------------------------------------------------------------------