-
Notifications
You must be signed in to change notification settings - Fork 32
/
Week 4 : How to store and Use Bitcoins(Secret Keys)
593 lines (479 loc) · 30 KB
/
Week 4 : How to store and Use Bitcoins(Secret Keys)
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
-------------------------------------------------------------------------------------------------------------------------------------------
4.1 Simple Local Storage
-------------------------------------------------------------------------------------------------------------------------------------------
-> It is the simplest way to store bitcoins bu putting it into a local device.
-> To spend a Bitcoin, need certain information:
a. Information from the public blockchain.
b. The owners secret signing key.
-> The information from the blockchain is publically avaiable, and hence can be gathered any any time, but it is essential to keep track of the owners seecret signing key.
-> Therefore storage of Bitcoins mostly deals with key management(secret key management).
* Goals - Bitcoin storage and Usage
------------------------------------
1. Availability - You can spend your coins.
2. Security - Nobody else can spend your coins.
3. Convience - easy to use.
* Simplest Approach - Managing keys
-----------------------------
-> Take the key, and store the key in a file on your computer or phone.
Evaluating this method against the goals.
1. Availability -> As a available as the device. (If the device is lost/wiped -> key is lost and coin is lost);
2. Security -> As secure as the device. Device compromised -> key leaked -> coins stolen.
3. Very convenient.
* Wallet software
------------------
-> Keeps track of coins, provides nice user interface.
-> Nice trick : use separate address/key for each coic.
- benefits privacy (looks like separate owners - provides ananymity/privacy)
- wallet can do the bookkeeping, user needn't know.
* Encoding Address
--------------------
-> Payments are made via exchanging address. The address needs to be encoded or conveyed to make a transaction possible.
-> Addresses are exchanged in 2 manners:
a. Encoded as text string: base58 notation. -> The key is taken and encoded in base58 notation. Then 58 characters are used to encode digits in base 58 notation. Here likely looking characters and numbers are excluded (O,0);
b. QR (Quick Response) code -> 2D barcode, Phone can scan the 2D barcode and extract the bits of the address.
Q. What is a Bitcoin wallet?
a. An address that contains a lot of unspent bitcoins
b. A piece of software that remembers an individual's Bitcoin addresses and keys - true.
c. A type of mining software
d. An online exchange that people can go to in order to acquire bitcoins
----------------------------------------------------------------------------------------------------------------------------------------
4.2 Hot and Cold Storage
----------------------------------------------------------------------------------------------------------------------------------------
# Hot storage -> Online (Conveninet but risky) - (money in your wallet); <-------|
| <--- Separate Keys/Addresses
# Cold storage -> Offline (Archival but safer) - (money in the safe); <-------|
# How to moved between hot and cold sides (relationship)?
-> Each side will have to have separate secret keys;
-> Each side should know the others address in order to make payments.
------------------------------------------------------------
Hot Storage | Cold Storage
-------------------------------------------------------------
|
(online) | (Offline)
|
Hot secret key(s) Payments Cold secret key(s)
<-----------|---------------->
cold address(es) | Hot address(es)
|
* In practice -> hot storage is online and cold storage is offline and hence they cannot connect to each other.
-> But the hot storage know the address at which the cold storage accepts payment, therefore the hot storage can send coins across to the cold storage, even while cold storage is offline.
-> Next time the cold storage connects it will receive the information from a block-chain about those transfers.
* Problem
----------
Want to use a new address (and key) for each coin sent to cold. But how can hot wallet learn new address if the cold wallet is offline?
-> Awkward Solution :
Generate a big batch of address/keys, transfer to hot beforehand. In case the addresses run out then reconnect the hot-side to the cold-side inorder to fetch more addresses.
-> Better Solution :
Hierarchical wallet. It requires cryptographic trickery.
* Regular Key generation
------------------------
-> Digital signatures, key generation - API operation called generateKeys();
|--------> address / Bitcoin addresses
------------ |
|generateKeys|-|
------------- |
|---------> private key
* Hierarchical key generation ith
------------------------------ |
\ /
---------
|---------> Address gen info ----> | genAddr | ---> ith Address
----------------- | ----------
|generateKeysHier| -|
------------------ | ---------
|---------> Private key gen info ---> | genKey | ---> ith Key
---------
/ \
|
ith
-> This information can be taken and multiple keys can be generated.
-> On the "Address gen info" you can run "genAddr" operation along with interger i -> to generate ith address.
-> Similarly, on the "Private key gen info" you can run "genKey" operation along with integer i -> generate ith key.
This has two properties:
------
a. The ith address and the ith Key match up and correspond to each other.
b. Security property: The address generation info doesn't leak the keys. Address generation info key can be given to anybody.
-> Not all digital signature schemes can be modified to support hierarchical key generation.
-> Fortunately the digital signature scheme used by Bitcoin "ECDSA" (Elliptic Curve Digital Signature Algorithm) -> does support hierarchical key generation.
---------> Address gen info
generateKeysHier -|
---------> Private key gen info
* Operation split on the hot-side and cold-side
-----------------------------------------------
ith
HOT-SIDE |
* \ /
* ---------
*************** |---------> Address gen info ----> | genAddr | ---> ith Address
----------------- | ----------
|generateKeysHier| -| **############**********************##############*****************
------------------ | ---------
############## |---------> Private key gen info ---> | genKey | ---> ith Key
# ---------
COLD-SIDE / \
|
ith
-> On the cold-side perform the generateKey hierarchical operation.
-> Then take the private key generation info and keep it at the cold side.
-> We take the address generation info that it makes and pass it across to the hot side.
-> Then the Hot-side can make an entire sequence of addresses on its own without needing any further communication with cold side.
-> The private/cold-side secret keys can be generated without communicating with the hot-side.
-> Only at the very beginning there is a communication between the HOT-SIDE and the COLD-SIDE.
-> This enables to use separate keys and addresses for every coin that is passed across from the cold side.
* How to store cold info ?
---------------------------
1. Info stored in device(laptop,phone, etc), device is locked in a safe.
2. "Brain Wallet" -> encrypt info under passphrase that user remembers.
3. Paper wallet (checkout on web)
- print info on paper.
- lock up the paper.
4. In "tamperproof" device
- device will sign things for you, but won't divulge(give out) keys.
Q. Which of the following statements are true about cold wallet storage?
a. Cold storage keys in a device without network access - true.
b. Cold storage tends to be more convenient
c. Cold storage can store more bitcoins
d. Hot storage wallets can generate arbitrarily many cold storage addresses without contacting the cold storage - true.
---------------------------------------------------------------------------------------------------------------------------------------
4.3 Splitting and Sharing Keys
---------------------------------------------------------------------------------------------------------------------------------------
-> Storing the Key at a certain place alone - could cause a single point of failure problem. Inorder to avoid this situation, the key needs to be shared or split.
* Secret sharing
------------------
-> Idea: split secret into N pieces, such that:
# given K pieces, can reconstruct the secret
# given fewer than K pieces, don't learn anything
-> Example: N=2, K=2
P = large prime
S = secret in [0,P)
R = random in [0,P)
split: X(1) = (S+R) mod P
X(2) = (S+2R) mod P
reconstruct:
(2X(1) - X(2)) mod P = S
(2 S mod P + 2 R mod P - S mod P - 2 R mod p) = (S mod p) ~ S
* Secret Sharing - (N can be any value, but k values are needed to recover the secret)
----------------
-> support K-out-of-N splitting for any K, N;
-----------------------------------------------------------------------------------------
| Equation | Random Parameters | Points needed to recover S (K) |
------------------------------------------------------------------------------------------
| (S + RX) mod P | R | 2 |
-----------------------------------------------------------------------------------------
|(S + R(1)X + R(2)X^2) mod P | R(1), R(2) | 3 |
-----------------------------------------------------------------------------------------
|(S+R(1)X+R(2)X^2+R(3)X^3) mod P| R(1), R(2), R(3) | 4 |
-----------------------------------------------------------------------------------------
etc.
* Good: Store shares separately, adversary must get(compromise) several shares to get the key. Additionaly, incase some of the shares are lost or compromised by the adversary, it may not cause much problem if (n-k) shares are lost.
* Bad : To sign, need to bring the shares together, reconstruct the key. <= vulnerable.
* Multi-sig
------------
-> Lets you keep shares apart, approve transaction without reconstructing key at any point.
-> It enables to store large-bodies of cold-stored coins in a way that is relatively secure and that requires action from multiple people before anything drastic can happen.
-> Example:
# Andrew, Arvind, Ed, and Joseph are co-workers.
# Their company has a lot of Bitcoins.
# Each of the four generate a key-pair, puts secret key in a safe/private/offline place.
# The company's cold-stored coins uses multi-sig, so that three of the four keys must sign to release a coin.
Q. In the K-out-of-N secret sharing scheme presented, the size of each share (in bits) will be
a. 1/K times the size of the secret
b. equal to the size of the secret - true
c. K times the size of the secret
d. N times the size of the secret
---------------------------------------------------------------------------------------------------------------------------------------
4.4 Online Wallets and Exchanges
---------------------------------------------------------------------------------------------------------------------------------------
* Online Wallet
----------------
-> like a local wallet but "in the cloud" (user interface);
-> runs in your browser
- site sends codes - that does the operations
- site stores keys - encrypt the keys and password
- you log in to access wallet
* Online wallet trade-offs
---------------------------
-> convenient - nothing to install, works on multiple devices.
-> Security worries - vulnerable if site is malicious or compromised. (Ideally site run by security professionals.)
* Bank-like services
----------------------
-> Alternative approach.
# You give the bank money (a "deposit")
# Bank promises to pay you back later, on demand.
# Bank doesn't actually keep your money in the back room.
- typically, bank invest money
- keeps some around to meet withdrawals ("fractional reserve").
* Bitcoin Exchanges
---------------------
-> Similar to "Bank-like" services.
-> Accept deposits of Bitcoins and fiat currency ($,€,£,...)
-> Promise to pay back on demand.
-> lets customers:
- Make and receive Bitcoin payments.
- Buy/sell Bitcoins for fiat currency - typically, match up BTC buyers with BTC sellers. (Opposite position in a transactions);
* What happens when you buy BTC?
---------------------------------
# Suppose my account at Exchange holds $5000 + 3 BTC.
# I use exchange to buy 2 BTC for $580 each
# result : my account holds $3840 + 5BTC.
# note: no BTC transaction appears on the blockchain.
# effect: Exchange is making a different promise now.
- before = 3 BTC + $ 5000
- now = 5 BTC + $ 3840
- value in account is same;
* Exchanges: Pros and Cons
-----------------------------
-> Pros: connects BTC economy to fiat currency economy.
Easy to transfer value back and forth.
-> Con: risk - same as banks.
1. Bank run - deposited money in the bank is used else where and hence not enough money to cover indiviuals withdrawals.
2. Owners/ Banks - might be crooks - might cheat.
3. Cyber attack - penetrate the security of exchanges - money can get stolen.
* Study (2013): 45% of Bitcoin exchanges end up closing. (Mt. Gox -> Japanese company)
* Banks don't share the same fate as that of the BTC exchanges risks
----------------------------------------------------------------------
* Bank Regulations
-------------------
-> For traditional banks, governments typically:
- impose minimum reserve requirements - must hold some fraction of deposites in reserve.
- In the U.S. the reserve is about 3% to 10% of demand deposits a bank is required to have.
-> Banks regulate behaviors, investments -> place money in assets that bear low risk since the assets are of other depositors.
-> Insures depositors against losses.
-> Acts as lender of last resort.
* Proof of Reserve
-------------------
-> Bitcoin exchanges can prove it ha fractional reserve. Fraction could be 25% or even 100%.
Part 1: Prove how much reserve you're holding:
- publish a valid payment-to-self of that amount.
- sign a challenge string with the same private key.
Part 2: Prove how much demand deposits you hold:...
-> The owner of the BTC can choose to publish only a fraction of the amount, The proof of reserve shows that a person atleast has that much amount.
* How to determine how much demand deposits you hold?
------------------------------------------------------
-> Relates to the Merkel tree
-> Merkle tree is a binary tree that is built with hash pointers so that each one of these pointers gives
- cryptographic hash of the information.
- pointer to the information.
- each hashpointer includes total value in its subtree.
-> Shows O(log n) items to prove the account held in the transaction.
* Binary tree with Hash Pointers = "Merkle tree" - Ralph Merkel
----------------------------------------------------------------
|
____\ /______
| H( ) H( ) |
|___|______|__|
| |
________________________________________| |_______________________________
| |
______\ /_________ ________\ /________
| H( ) H( ) | | H( ) H( ) |
|____|________|___| |_____|_________|___|
| | | |
________| |__________ _____________________| |_______________
| | | |
______\ /________ ________\ /____ _______\ /__________ _________\ /_______
| H( ) H( )| | H( ) H( ) | | H( ) H( ) | | H( ) H( ) |
|___|_________|_| |___|_______|__| |___|___________|__| |___|____________|_|
| | | | | | | |
| | | | | | | |
\ / \ / \ / \ / \ / \ / \ / \ /
-------- --------- -------- --------- --------- --------- --------- ---------
| | | | | | | | | | | | | | | |
| DATA | | DATA | | DATA | | DATA | | DATA | | DATA | | DATA | | DATA |
| | | | | | | | | | | | | | | |
|________| |_______| |________| |_______| |_________| |________| |________| |________|
- From a bunch of data blocks at the bottom, consecutive pais of the data blocks are taken;
- For these two data blocks a data structure with two hash functions is built, so on till the root of the tree.
- We can traverse down through the hash pointers to any point in the list and ensure that the data has not been tampered with.
- If an adversary tampers with the data, then the hash pointer will be tampered with and so on, one -level upwards, eventually the aversary won't be able to tamper with the hash pointer at the head that we have remembered.
* Proving the membership in a merkel tree
-------------------------------------------
| show O(log n) items
____\ /______
| H( ) H( ) |
|___|_________|
|
________________________________|
|
______\ /_________
| H( ) H( ) |
|____|____________|
|
________|
|
______\ /________
| H( ) H( )|
|___|___________|
|
|
\ /
--------
| |
| DATA |
| |
|________|
We remember the root, and someone wants to convince us that the data block belongs to the merkel tree, then they need to show the data block and verify that the hash matches along all levels;
This takes (log n) items to be shown and therefore (log n) time to verify;
-> Can prove the amount in the hashpointers.
# The exchange builts a tree (Merkle) that includes all their customer accounts and sums the total value going up the top, then all customers.
Proof of Reserve
-----------------
-> Prove that you/Bank have atleast X amount of reserve currency.
-> Prove that customers have atleast Y amount deposited.
-> So reserve fraction >= X / Y;
Q. Which of these are risks of Bitcoin exchanges that are NOT risks of maintaining one’s own hot or cold wallet? (Check all that apply)
a. Bank runs - true
b. Ponzi schemes - true (cheat)
c. Key compromises or leaks
d. Double-spend attacks
---------------------------------------------------------------------------------------------------------------------------------------
4.5 Payment Services
---------------------------------------------------------------------------------------------------------------------------------------
* Scenario : merchant accepts BTC
--------------------------------
# customer wants : to pay with Bitcoin
# Merchant wants:
- to receive dollars
- simple deployment
- low risk (tech risk, security risk, exchange rate risk);
-> The merchant will first go to a payment services website and fill out a form.
------------------------------------------------------------------------------------
| Choose A Way To Accept Bitcoin |
| |
| Type * Button * Hosted Page * Forms * Email Invoice |
| Payment * Buy now * Donation * Subscription |
| |
| |
| Button Style |
| |
| ----------------------- --------- -------- |
| Item Name | | Amount | BTC | 0.00 | |
| ----------------------- --------- -------- |
| |
| -------------------------------------------------------------- |
| Item Description | | |
| | | |
| -------------------------------------------------------------- |
| |
| ---------------------- |
| Send Funds To | My Wallet (0.00 BTC) | |
| ---------------------- |
| |
| ----------------------- |
| | Generate Bitcoin Code | |
| ------------------------ |
|-----------------------------------------------------------------------------------|
-> On click of the Generate Bitcoin Code , a HTML will be created, that the merchant can drop into their website.
-> Then when a customer wants to make payment, on pushing that button a payment will be made.
Merchant Customer Payment Service
-------------------------------------------------------->
(1) Pay with BTC button <transID, amount>
------------------------------------------------>
(2) clicked <transID, amount>
<------------------------------------------------
(3) Payment Interaction
<------------------------------------------------------------------------------------------------------------
(4b) ok so far (4) redirect
<------------------------------------------------------------------------------------------------------------
(5) confirm <transID, amount>
* End Result
-------------
# customer : pays Bitcoins.
# merchant : gets dollars, minus a small percentage.
# payment service:
- gets Bitcoins
- pays dollars
- absorbs risk : security, exchange rate.
- needs exchange Bitcoins for dollars, in volume (Participate in the market).
Q. In the scenario presented, which of these parties are exposed to exchange rate risk? (Check all that apply)
a. User - True (The user is exposed to exchange rate risk to some degree since they must hold bitcoins at least temporarily to be able to pay with bitcoins.)
b. Merchant
c. Payment Service - True
---------------------------------------------------------------------------------------------------------------------------------------
4.6 Transaction Fees
---------------------------------------------------------------------------------------------------------------------------------------
-> Whenever a transaction is put into a blockchain, then that transaction might pay a transaction fee.
-> Transaction fee = value of inputs - value of outputs
fees goes to miners who records the transactions.
* How are transaction fees set today?
--------------------------------------
-> Costs resource for
- peers to relay your transaction
- miners record your transaction
-> Transaction fee compensates for (some of) these costs.
-> Generally, higher fee means transactions will be forwarded and recorded faster.
* Current consensus fees
---------------------------
-> No fee if:
- tx less than 1000 bytes in size and
- all outputs are 0.01 BTC or larger, and
- priority is large enough.
Priority = (sum of inputAge*inputValue) / (trans size)
-> Otherwise fee is 0.0001 BTC per 1000 bytes.
-> Approx transaction Size : 148 N(inputs) + 34 N(outputs) + 10
* Most miners enforce the consensus fee structure. (Not all miners)
* If you don't pay the consensus fee, your transaction will take longer to be recorded.
* Miners prioritize transactions based on fees and the priority formula.
---------------------------------------------------------------------------------------------------------------------------------------
4.7 Currency Exchange Markets
---------------------------------------------------------------------------------------------------------------------------------------
-> Markets on which you can trade Bitcoins against fiat currencies.
-> Sites like http://bitcoincharts.com/markets
- shows exchange that trade dollars against Bitcoins.
-> Meet people online to Buy or Sell Bitcoins -> LocalBitcoins.com
-> Physical places - trade bitcoins.
-> Basic market dynamics:
----------------------------
# market matches buyers and sellers.
# large, liquid market reaches a consensus price.
# price set by supply (of BTC) and demand (for BTC).
-> Supply of Bitcoins
-------------------------
# supply = coins in circulations (+ demand deposits?)
# coins in circulation : fixed number , currently ~ 13.1 million; (eventually will reach - 21 Million);
# When to include demand deposits?
- When they can actually be sold in the market. (When a portion of the deposit reserve is utilized in the market)
-> Demand for Bitcoins
-----------------------
Two means:
1. BTC demanded to mediate fiat-currency transactions.
- Alice buys BTC for $. ------|
- Alice sends BTC to Bob. |---- BTC "out of circulation" during this time.
- Bob sells BTC for $ ------|
2. BTC demanded as an investment
- If the market thinks demand will go up in the future.
* Simple Model of transaction-demand
--------------------------------------
T = total transaction value mediated via BTC ($ / sec);
D = duration that BTC is needed by a transaction (sec); (held out of sirculation; Payer buys BTc from market and receiver sells them back to the market);
S = supply of BTC (not including BTC help as long-term investments) (BTC);
P = Price of BTC ($ / BTC);
-> Supply
--------------
S
--- = Bitcoins become available per second
D
-> Demand
------------
T
--- = Bitcoins needed per second
P
-> Equilibrium
----------------
T * D
P = ---------
S
-> Supply > Demand
--------------------
# Price goes down, hence demand increases.
-> Demand > Supply
-------------------
# Price goes up, hence demand decreases.
Q. In the model presented, which of these are sources of demand for bitcoin?
a. Mediating fiat-currency transactions - true
b. Demand deposits of bitcoin
c. Gambling
d. Investment - true
e. Paying transaction fees
The model presented considered only two sources of demand: mediating fiat-currency transactions and investment. Theoretical models must often leave out some factors that matter in practice in order to keep the analysis tractable. Arguably, paying transaction fees is also a source of demand for bitcoins.
----------------------------------------------------------------------------------------------------------------------------------------