IT代写 IS3101 Cryptocurrency & Blockchain – cscodehelp代写
IS3101 Cryptocurrency & Blockchain
Lecture 9 Bitcoin Storage
• Bitcoin Storage
Copyright By cscodehelp代写 加微信 cscodehelp
– Hot vs. Cold
– Keys management – Wallet & Exchange
• Payment Service & Transaction Fees
• Currency Exchange Markets
• Smart Contracts Interactions
How to Store and Use Bitcoins
How to Store and User Secret Keys
To spend a Bitcoin, you need to know:
* some info from the public blockchain, and * the owner’s secret signing key
So it’s all about key management.
1. Availability: You can spend your coins.
2. Security: Nobody else can spend your coins. 3. Convenience
Local storage approach
○ store key in a file, on your computer or phone
○ As available as your device.
■ device lost/wiped ⇒ key lost ⇒ coins lost ○ As secure as your device.
■ device compromised ⇒ key leaked ⇒ coins stolen
● Keeps track of your coins, provides nice user interface.
● Nice trick: use a separate address/key for each coin. ○ benefits privacy (looks like separate owners)
○ wallet can do the bookkeeping, user needn’t know
● Encode as text string: base58 notation
● or use QR code
Hot storage Cold storage
archival but safer
convenient but risky
hot secret key(s)
cold secret key(s)
hot secret key(s)
Want to use a new address (and key) for each coin sent to cold
But how can hot wallet learn new addresses if cold wallet is offline?
● Awkward solution:
Generate a big batch of addresses/keys, transfer to hot beforehand
● Better solution: Hierarchical wallet
Regular key generation:
Hierarchical key generation:
doesn’t leak keys
address gen info
private key gen info
address gen info
private key gen info
cold side i
How to store cold info
(1) Info stored in device, device locked in a safe (2) “Brain wallet”
encrypt info under passphrase that user remembers (3) Paper wallet
print info on paper, lock up the paper (4) In “tamperproof” device
device will sign things for you, but won’t divulge keys
Example: Paper wallet
● like a local wallet but “in the cloud”
● runs in your browser site sends code
site stores keys
you log in to access wallet
Online wallet tradeoffs
● convenient: nothing to install, works on multiple devices ● but security worries
vulnerable if site is malicious or compromised ● ideally, site is run by security professionals
● 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 invests the money
keeps some around to meet withdrawals (“fractional reserve”)
● 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 buyer with BTC seller
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 + 5 BTC
note: no BTC transaction appears on the blockchain only effect: Exchange is making a different promise now
Exchanges: Pros and Cons
● pro: connects BTC economy to fiat currency economy easy to transfer value back and forth
● con: risk
same kinds of risks as banks
● for traditional banks, government typically: ○ imposes minimum reserve requirements
○ must hold some fraction of deposits in reserve ○ regulates behavior, investments
○ insures depositors against losses
○ acts as lender of last resort
Proof of Reserve
● Bitcoin exchange can prove it has fractional reserve. fraction can be 100%
● Prove how much reserve you’re holding:
publish valid payment-to-self of that amount sign a challenge string with the same private key
● Prove how many demand deposits you hold: …
Proof of Reserve
● Prove that you have at least X amount of reserve currency ● Prove that customers have at most Y amount deposited
● So reserve fraction ≥ X / Y
– customer wants: to pay with Bitcoin
– merchant wants:
• to receive dollars
• simple deployment
• low risk (tech risk, security risk, exchange rate risk)
HTML for payment button
● customer: pays Bitcoins
● merchant: gets dollars, minus a small percentage ● payment service:
pays dollars (keeps small percentage)
absorbs risk: security, exchange rate
needs to exchange Bitcoins for dollars, in volume
transaction fee = value of inputs – value of outputs fee goes to miner who records the transaction
• Interesting economics, discussed in later lecture
• How are transaction fees set today?
● Costs resources for
peers to relay your transaction miner to record your transaction
● Transaction fee compensates for (some of) these costs
● Generally, higher fee means transaction will be forwarded and recorded faster.
● Current consensus fees:
● No fee if
○ tx less than 1000 bytes in size,
○ 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 Ninputs+ 34 Noutputs + 10
● Most miners enforce the consensus fee structure.
● 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.
Currency Exchange Markets
• The most convenient way to buy Bitcoin is an ATM.
• Usually you only need to show the ATM the QR code of your Bitcoin address, insert bank notes and confirm the exchange rate.
• The process takes less than 30 seconds, is anonymous but can cost up to 8% in fees.
• Prepare your wallet ahead of time, and bring exact change.
• ATMs generally accept only HKD bank notes, some insist on the first note being of HKD 500 denomination or above.
Smart Contract V
• Contract to Contract
s: Evaluating Smart Contracts
● Best practices for designing blockchain-based applications
● Best practices for designing solutions with smart contracts using Solidity & Remix IDE
When to use blockchain
● Make sure your application requirements need blockchain features
Blockchain is most suitable for:
1. Decentralized problems
2. Peer-to-peer transactions
3. Beyond boundaries of trust among unknown peers
4. Require validation, verification & recording of timestamped, immutable ledger
5. Autonomous operations guided by rules & policies
1. Keep the smart contract code simple, coherent, and auditable
2. Make smart contract functions auditable by using custom function modifiers
3. Keep only the necessary data in the smart contract
4. On-Chain Data vs Off-Chain Data
1. Use appropriate data types.
2. Make sure you use the integer arithmetic for most of your computational needs.
3. Understand the public visibility modifier for data.
4. Maintain a standard order for different function types within a smart contract.
● Functions can have many different modifiers.
● Use Solidity-defined payable modifier when sending value.
● Pay attention to the order of statements within a function.
1. Use modifier declarations for implementing rules.
2. Use function access modifiers for:
○ Implementing rules, policies and regulations.
○ Implementing common rules for all who may access a function.
○ Declaratively validating application-specific conditions.
○ Providing auditable elements to allow verification of the correctness
of a smart contract.
3. Using events in smart contract.
4. Beware of Block.timestamp time variable
● Use secure hashing for protecting data.
Interactions between Smart
● Several ways of enabling contracts to interact with other contracts
● Smart contracts can call functions of other contracts and are even able to create and deploy other contracts
● Upgradeable contracts ○ Delegating calls
● Other contracts as libraries ● Contracts as data stores
Smart Contract Tutorial 9
● In Tutorial 9, we will learn 2 different ways to interact between smart contracts
History of payment systems and the road to Bitcoin Narayanan et al. Ch. 4
Remix IDE Document https://www.tutorialspoint.com/solidity/
程序代写 CS代考 加微信: cscodehelp QQ: 2235208643 Email: email@example.com