Lions, and Tigers and Bears, oh my! Hot and Cold Storage, Hierarchical Wallets, and Brain Wallets, Oh my!

Last time, I just discussed local storage. I listed several options for storing bitcoins and I talked about storing bitcoin from a security, availability, and convenience standpoint. This lecture is again looking at different key management system but from the idea of access to the internet/blockchain. I talk about hierarchical wallets, brain wallets, and paper wallets. I would say “All the wallets” but there are more wallets to come…

Questions answered in this Post:

• What is cold and hot storage? How does that influence what wallet I choose?
• This cold storage seems cool. Can I make it myself?
• Why would you and how can you transfer coins from hot to cold and vice versa?
• What is this hierarchical wallet? Is it similar to a hierarchical deterministic wallet?
• What is a deterministic wallet? Has it been implemented and where?
• What are the mechanisms used to do cold storage?
• What is a brain wallet?
• What is a tamper-proof seal device and give an example.

Hot and Cold Storage

If you have worked in technology the words hot and cold storage may have popped up before. Hot storage simple means it’s connected to the internet and thus has the opportunity to be considered risky. Thus when you put your key management on a internet connected computer, phone, or a browser, this would be hot storage. Hot storage is not bad; it is even necessary if you want to conveniently make transactions. Cold storage is when the key management that is offline and can be considered more archival. That paper wallet is a form of cold storage. Also, if you manage your keys on a non internet device, this is also cold storage.

I saw quite a few tutorials online showing how to create a cold storage device. I’ve listed them below since I thought it was interesting.

1. Using Old Cellphone as Cold Storage: These instruction show how you can use an old cellphone as a cold storage device. It is a bit difficult to follow but there is a video here.
2. Creating a Bitcoin Cold Storage Wallet: This creates a cheap cold storage wallet using Mycelium. The phone was an android phone.
3. Creating a USB Bitcoin Wallet with MultiBit: This tutorial shows you how to make an encrypted USB Bitcoin Wallet.
4. RavenBit: DIY Physical Bitcoin: This company actually sends you a brass coin.
5. Cold Storage Paper: This tutorial came from Bitcoin.com where they describe creating a secure paper wallet.

Remember
Hot- online convenient but risky
Cold – offline archival but safer

 

Now that we know what hot and cold storage means, why did the people from Princeton devote an entire lecture to them and transferring bitcoin between each system? It is because it is something that will be necessary for owners and is non trivial. Suppose you get quite a bit of bitcoin via gambling in your hot storage and you need to offload that amount to your cold storage. You’ll need to transfer the coin from the hot key address to the cold key address. This can all be done with the cold storage offline, so this is an easy move. However, let us say you have been having a terrible gambling run and you have depleted your hot storage wallet. You can A. Quit and decide you’re done or B. Get more bitcoin into your account by transferring some of your secured funds from the cold storage to the hot.

 

How can you transfer from cold to hot if you’d prefer to keep your cold storage device offline for security? Likely, you’ll want to receive coins in a separate address with different secret keys each time, thereby requiring some mechanism to actively generate new fresh cold addresses each time. Having new addresses improves anonymity since someone cannot be identified for having several transactions between a single address. Also, if one private key is compromised, it’s good to have other options.

A very simple approach reminds me of a feature in Gmail. With Gmail, you can set up 2-Factor Authentication. (If you don’t have 2-Factor Auth set up, do it now!) 2-Factor Authentication means that when you log in, you submit your password but then you have to submit a second code. This enables better security since that second code is usually sent to a device that thwarts hackers from just brute forcing your password. This means every time you log into your Gmail, you type your password and then Google sends a code to you via email or text message. There are times when you’re not online or you’re traveling where that secondary device is just unavailable. At moments like that, Google allows you to print a list of codes and just use those codes to log in. These codes can be printed out before your trip and you’ll take this sheet of paper with you so that when you want to check your Gmail, you’ll use these codes as a replacement for that second code.

Thus cold storage can just generate a bunch of addresses and send them to the hot storage. The only problem is that periodically, the cold storage device will have to go online to generate and deliver a new set of codes to the hot storage.

This is where hierarchical wallets come into play.

Hierarchical Wallet

A hierarchical wallet allows the cold storage side to have an unbounded number of addresses and the hot side knows these addresses vi a short, one time communication between the both sides. This sounds perfect!

I’ll explain how it works as well as I understand it. We will still be using the ECDSA scheme since it has special properties which I”ll touch upon later. For hierarchical wallet, key generation is slightly modified. Regular key generate (generateKey) creates a public key (address) and a secret key. Instead, the generate key creates a public and private key generation info. With the generation info and an index number, you can generate the ith address in the sequence.

With this “generation info”, you can create a sequence of addresses instead of just one. The cool part is that the address generation info does not leak information regarding private keys so giving people the index and generation info is reasonably safe. The reason this works is because ECDSA supports hierarchical key generation. Now as long as the hot and cold side know the right sequence number, you can generate addresses from the hot side and private keys on the cold side. Also, the public key are not linkable meaning that even if you figure out one, you can just reverse engineer in some way to get the rest of them an that the private keys are still safe.

Now you must be thinking, where is this hierarchical, I just see two different sides hot and cold? There can actually be more levels with this wallet. Currently the hot side is the lower level while the cold is the top level. As with a company employee chain, the higher the chain the more secure you want the communication chain.

(HIerarchical) Deterministic Wallets

While this word was not mentioned in the lecture, I think it is worth mentioning deterministic wallets. A deterministic wallet allows the user to generate data for their keys from a single seed instead of randomly generating them The nice benefit of the deterministic wallet is that you can recreate your lost keys if say your hard drive gets corrupted as long as you know this seed. Honestly, to me this sounded just like hierarchical wallet ie a special generateKey function. Within the article that I linked to, when the author, Buterin explain the wallet, it sounds exactly the same as the hierarchical just with different words. If you read the article, just substitute the word generation info with master public key.

I’ve also listed several links that either talk about hierarchical deterministic (HD) wallets or are implementation of HD wallets. Just know, many wallets nowadays do implement this feature. Hierarchical Deterministic Wallet (HD) term was more prevalent than just the hierarchical wallet. I feel like the lecturers may have chosen a less used term to explain this feature.

• Understanding Hierarchical Deterministic Wallets – This youtube video by LTB Network features a podcast type explanation of the different wallets. It is about an 11 minute video. He explains the BIP: 32 in a nice clear fashion.
• Hierarchical Deterministic Wallets BIP: 32 – This links contains the exact Bitcoin Improvement Protocol (BIP) for adding HD wallets. It is a technical read but incredibly informative.
• Electrum Protocol – This company which I listed last week as a bitcoin wallet. As mentioned from Bitcoin Magazine, the wallet full implement BIP32 making it a Hierarchical Deterministic Wallet
• TREZOR – This is another bitcoin wallet that implements HD wallet. Different from other wallets discussed, this is a hardware wallet. Thus when you buy TREZOR, they will send you palm sized, tamper and water- proof device which is your wallet.
• Armory Deterministic Wallet – I mentioned this company last time as being a security conscious bitcoin wallet. They have a neat implementation for a deterministic wallet.

Now, I know I listed some practical ways to do cold storage. I listed those DIY resources on how to make your phone, paper, or USB device into a cold storage. These methods incorporate methods such as brain wallets, paper wallet, and tamper-resistance devices. A paper wallet sometimes contains a tamper-evident seal over the private key. This makes sure there is not way to output or divulge the key. A brain wallet secures the bitcoins by a secret passphrase which I’ll discuss below.

Brain Wallets

A brain wallet is nice because you don’t need to have extra hardware to store your bitcoins. You only need to have a good memory or an effective but secure way to determine your passphrase. Once you have a good passphrase, then you can just hash it twice, maybe using SHA-256 to give you a secure public and private key. Now your password while it may look random, if the adversary knows how you generated the key and your passphrase, you will be at a loss. With your email, if someone puts into too many password, you can locked out, this does not happened with bitcoin. Thus if your passphrase is common, hackers can just use something called offline guess or password cracking to steal your coins. The lecture does discuss one way to do passphrase generation.

You just choose a random sequence of 6 random words from among the top 10,000 works in the English language. They are easy to remember and have roughly 80 characters. From there, use a hash function SHA-256 and compute is 2^20 times to just make it hard for the attacker.

Key Stretching – use a deliberately slow function to derive the private key from the passphrase to make it harder for attackers to brute force.

Metamask.io is a Chrome plugin. Besides having a cute evil fox, they use this brain wallet approach. When you create your new vault, as they call it, they give you 12 words that allows you to restore your MetaMask accounts for the vault. So you’ll be given words like “retreat brain math envelope earth dutch fake tired dot occasions worn focusing” which you need to store and use to recover your accounts.

There is one downside, if you forget the passphrase, you’re screwed…

4 Ways to do Cold Storage

1. Information stored in device, device locked
2. Brain wallet encrypt info under passphrase or password that a user remembers
3. Paper wallet -print info on paper, lock up the paper
4. “Tamper-proof device” device will sign things for you but won’t divulge keys

Wrap-Up

I’ve wrapped up below what I’ve talked about because it combined several components. I first discussed why there is a need for hot and cold storage as well as why you would want to transfer coins between these storage components. Additionally, I gave some links to tutorials on how to create a cold storage device. Next, I walked through how hierarchical wallets work. Next, I discussed deterministic wallets since this term is more actively used than hierarchical  wallet. Lastly, I discussed, what methods are used to do cold storage which involve offline devices, brain wallets, tamper-proof devices, and paper wallets.

Which of the following statements are true about cold wallet storage
Cold storage keys in device without network access
hot storage wallets can generate arbitrarily many cold storage addresses without contacting the cold storage

What is local storage of Bitcoin? How can we manage Bitcoin secret keys? 20+ options listed

The entire week four is devoted to storing and using bitcoins. Yes, this will be a practical week of lectures! The first lecture felt very simple. Basically, the conversation of storage of bitcoin is focused on the management of secret keys. There are a variety of ways to do local storage on your phone which I’ll list at least 10 different wallets for your phone and desktop. I’ll talk about bitcoin vanity addresses as well.

Questions answered in this Post:

• What does local storage of bitcoin mean?
• When considering local storage, what should you focus on?
• What is a bitcoin wallet?
• I want a wallet! What are some of my options?
• How are addresses encoded to be sent to another party?
• What is a vanity address?

What does local storage of bitcoin mean?

When I think simple storage of money, I think of that crazy uncle who hid/stored all his money under his mattress. It was safe as long as the house was intact and no one knew where to look. One issue I have with that approach is that $100 sitting in a mattress from 1950 is still only $100 in 2017 though $100 does not go as far as before. Clearly those $100 were better invested in a bank at the very least or a stock market index….

The approach of simple local storage of bitcoin is something like that. The bitcoin is stored on some local device. That local device can either be your home computer, phone, or a USB stick with some wallet software to help you manage that data.

How do you spend a bitcoin?

To spend bitcoin, think about what information needs to be shared so that a transaction can take place. There needs to be some connection to the blockchain, the identity of the coin to spend, and the worth of the coin. Also, you have a secret key which you use to sign transactions and verifies the owner. At the core, storing bitcoin boils down to storing and managing Bitcoin secret keys. The lecture broke down the key management into three approaches: availability, security, and convenience

Three Approaches

• Availability: How quickly can you spend your coins?
• Security: How safe are my coins to ensure no one else spends my coins?
• Convenience: How easy is it to management my coins?

.Evaluation of different methods

Paper Wallet

Back to my example of storing the bitcoin on your local device, it’s pretty simple. You can actually have a paper bitcoin wallet. I think several years ago at some of the early bitcoin conference, people were presented with paper wallets for attending certain talks. This is just like putting money in the mattress. Your bitcoin wallet will contain your public key and the private key. Usually there is also a QR code so that the wallet can be quickly scanned. I created a wallet just for academic purposes at BitAddress. While paper wallets are simple, they are just as secure and available as your regular wallet. Though, you’ll likely have to use your phone or type out the address to use it. During that point, there is a potential for a hack to occur. Honestly, if you’re going to do this, at the very least laminate the paper wallet.

DIGITAL WALLET: PHONE and DESKTOP

What about storing the keys on a digital device like your phone or computer. It’s convenient since you can think of it just like your wallet especially if you store your coins on your phone. Also, to make sure you’re not writing individual transaction in C++ or Go, you will likely use a bitcoin wallet software. A bitcoin wallet software is one that keeps tracks of coins, manages details of your keys, and usually has a slick user interface. In terms of availability, the coin is only available when you have your device. Thus, all questions regarding availability and security are tied to that device. Simple problems like your phone getting lost/wiped/stolen could turn into a catastrophe if you have a lot of bitcoin stored. Similarly, if someone hacks your computer and steals your private keys, then your bitcoins are lost. While, I feel like I’ve painted a grim picture, there are quite a bit of wallet softwares on the market.

I’ve listed and provided links to many desktop and mobile wallets. Some of the companies will be listed on multiple categories. If you’re going to use any of these wallets, please do your own research just to make sure they fit your needs.

Local Storage: Bitcoin Wallets for Desktop

1. Bitcoin Core: solid multipurpose software including a wallet
2. MultiBit: available on multiple platforms
3. Armory: security focused wallet
4. DarkWallet: private bitcoin wallet focused on privacy with a Browser and Ubuntu download
5. Bitcoin Knots
6. Electrum
7. mSIGNA
8. Bither
9. MultiBit HD
10. Green Address
11. ArcBit
12. CoPay
13. BitGo

Local Storage: Bitcoin Wallets for Phone

1. breadWallet iOS Android
2. Bither: iOS
3. Coin.Space: available for Android Windows iOS
4. Simple Bitcoin Wallet Android
5. ArcBit iOS Android
6. CoPay all
7. Airbitz iOS Android
8. Mycelium Android
9. Green Address iOS Android
10. Coinomi Android

Encoding Keys with base 58 or QR code

Now that I’ve overwhelmed some people on the various wallet companies, I’ll discuss a bit on how keys are encoded to be sent to other parties. They can get sent via a text string or a QR code. To send a text string is relatively simple. You just take the bits of the key and convert it from binary (ones and zeros) to a base 58 number. Base58 means that in total there are 58 symbols in the alphabet. The English alphabet can be thought of as base 26. Binary is base two 2 because it only contains ones and zeroes. The base58 contains upper case letters, lower case letters and digits. If you’re thinking that is way more than 58 you’re right. Upper Case letters ie ABC… (26) + Lower Case letters ie abc… (26) + Digits 0123… (10) would be 62. Certain symbols were removed since they look too alike with other characters such as the capital letter ‘O’ and the number zero ‘0’. Below is the address of the first Bitcoin block reward in the genesis block, base58 encoded.

1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

I mentioned there was a second method with the QR code. Just take a picture with a smart phone and the wallet software will convert it into the correct bit sequence for the address and allows you to spend that money.

Speaking of addresses, there is something called a vanity address. Vanity addresses unrelated to bitcoin just refer to some name manipulation to an identifying object to make it aesthetically more pleasing. This NYT article from 1988 talks about real estate buildings that have nicer names such as changing 338 East 44th Street to Three United Nations place. Within the bitcoin landscape, it is a address that starts with some human-meaningful text. According to the “Princeton Bitcoin Book”, they are generated by people repeatedly generating private keys until the public key has this nice name on them. There are techniques for generating vanity address more efficiently by incrementing the private key instead of choosing a new random one each time. If you’re interested they’re some tools that provide this service. Vanitygen is a command-line too to do this. BitcoinVanityGen is an online too that will allow you to choose the first 6 characters free. This Vante company provides this as well. Be careful though using another source since they now have the potential to know your private key. If you’re going to do this, I’d recommend doing the generating yourself.

Limitations with Bitcoin due to hard-coded limits and scalability issues? Hard-forking? Soft forking?

This lecture, admittedly seemed dry. After the excitement of talking about the block chain and all the potential it has, this lecture brought us back to reality. It explained where some of the shortcomings are and what would be required to make these changes, ie hard-fork. Also, we discussed how pay-to-script-hash was a successful soft fork change.

Questions answered in this Post:

• What are these hard-coded limits?
• What is a hard-fork?
• What are some of the challenges faced with hard-forking?
• What is a soft-fork?

What are these hard-coded limits in Bitcoin?

Most of these limits I’ve already talked about. First, there is a 10 minute time interval between block creation. The below table indicates that other cryptocurrencies now have much shorter time intervals. Ethereum has on average 14 – 17 sec. Even, Litecoin which was launched in 2011 uses only 2.5 minutes. Another drawback is that there can only be 1 million bytes in a block. There can only be 20,000 signature operations per block. There are 100 million satoshis per bitcoin. The bitcoin mining reward is completely fixed. Lastly, only 21 million bitcoin will be created.

There are some throughout limits that are worth looking at as well. First that there is 1 million bytes per block and a block is created every 10 minutes. Also, each transaction have at least 250 bytes meaning that the network can only handle 7 transactions per second. That’s not very fast. Credit card companies handle significantly more such as Visa (10,000/sec) or Paypal (100/sec).

Other limits refer to the choice of cryptographic algorithm. There is only ECDSA/P256 signature algorithm used and at least the lecturer mentioned that cryptoprimitive might break by 2040. I discussed earlier this year that SHA-1 has been broken. Thus that future may already be upon us.

Cryptocurrency Name	Symbol	Creation Year	Time Between Blocks	CryptoMechan
Bitcoin	BTC	2009	10 min	SHA-256
Ethereum	ETH	2015	10 – 20 sec	Ethash
Dash	DASH	2014	2 – 3 min	X11
Monero	XMR	2014	1 – 2 min	Cryptonote
Ripple	XRP	2011	–	ECDSA?
Litecoin	LTC	2011	2 – 3 min	scrypt

How do changes occur to Bitcoin? Hard-fork? Soft-fork?

A hard-fork change means that there would be a change to the Bitcoin protocol and all the software would need to be upgraded. What makes it “hard” is that the new version of the software may validate previously rejected blocks. At this point, if some nodes on the network upgrade and others do not, then potentially there may be two longest branches where one would be with the upgraded software and one with the older software. Thus the block chain will split. Every node would be segmented into one or the other version and the branches would not be joined. This is unacceptable according to the lecturer.

On the other hand, a soft fork makes validation rules stricter. So the hard fork was widening the requirements where soft fork is restricting it. This means that previously valid transactions are now going to be considered no longer valid. Will there be a risk of the block chain splitting as before?

The new version gets introduced with the soft forking change. The nodes with the new software enforce tighter rules and if the majority of the nodes switch to the new software, then the network will actively be enforcing these new rules. Once that occurs, there will be a single block chain. Let’s say that there are old miners who are mining invalid blocks because they are putting in some transactions that previous were valid but are now invalid. Their blocks will keep getting rejected and they will realize they need to upgrade their software.

Soft fork example: Pay-to-script-hash

Pay-to-script-hash was not present in the original version of the Bitcoin protocol. The change made it such that original pay-to-script-hashes which were previously correct were now going to be invalid. The pay-to-script-hashes in the old system would just hash one data value and check if the hash matches the specified value in the output script. The new change would do a verification to make sure the previous value of the hash also was a valid script.

Proposed hard fork changes

Hard fork changes as mentioned are difficult. To add new opcodes to Bitcoin, changing the hard-coded limits on block and transaction size would require a hard fork. Even some bug fixes aren’t fixed because of this issue. If you look at some new cryptocurrencies, you can see that they fixed some of the perceived issues with bitcoin.

Bitcoin P2P Network

This lecture focused on the bitcoin peer-to-peer (p2p) network. While this lecture just talked about the current network and its implementation which I will discuss,

Questions answered in this Post:

• What are characteristics of the blockchain network?
• How do you as an individual connect to the blockchain network?
• What is a full node and what is a SPV?
• What is the size of the network?

What is the blockchain network and how can people join this network?

The Bitcoin P2P network is quite similar to other peer-to-peer networks. I only know a few p2p networks outside of Bitorrent which is Gnutella and e2dk. I remember that there were many issues with Gnutella regarding scalability and message propagation. Similar to other peer-to-peer networks, it has the properties that all the nodes are equal and there is no hierarchy. It uses TCP (Transmissiong Control Protocol) with a random topology. Anyone can join the network and leave the network as well. Leaving the network is easy since if the network doesn’t hear from the node for three hours, it is just assumed that it is no longer online and stops sending messages to it.

Again, I’m talking about the Bitcoin P2P network and as I’ll talk about later this notion of equality does not stand true for other side bitcoin networks.

Key Characteristics

• ad-hoc protocol (runs on TCP port 8333)
• ad-hoc network with random topology (random nodes peering)
• all nodes are equal (no central/master)
• new nodes can join at any time (anyone can download and get started)
• forget non-responding nodes after 3 hours

What does it mean that anyone can join at anytime?

Well anyone can download something like Bitcoin Core or use npm to install Bitcore and become a full node. As with any peer-to-peer network, pay attention to security, bandwidth, and actual space concerns.

How does a new node connect to the network?

Simple answer would be just connect to one node and then more will follow. Though, there are a few more steps then just that.

1. Connect to a seed node with a message like, “Hello World! I’m ready to Bitcoin”. Seed nodes are hard coded IP addresses that one an use to connect to another active node. Instead of using the IP addresses, some program with use DNS seeds, which let you look up the IP addresses instead of just providing one. A few DNS seed names are bitseed.xf2.org or seed.bitcoin.sipa.be
2. To first connect, send a version message and receive a version message back. Then send a verack to confirm the connection.
3. Send the messages getaddr and addr to the seedNode
4. Next you connect to the nodes that seedNode sends you
5. Repeat with the new nodes to be better connected.

What happens in the network?

Transactions that one node hears are shared across the entire network. This is Transaction propagation (flooding) or a gossip protocol. It is a simple gossip Protocol where the network is just sending the message to every node it knows. At certain short time periods, a message gets sent to random targets in a pairwise fashion and each time, the node is responsible to update its view of the blockchain and determine whether to send the transaction outwards. Each node has its own list of pending transactions and must decide to forward or not based on a certain set of criteria. Also, like a breadth first search, it has a check to see whether it has seen a certain transaction before to prevent message from being sent forever. According to bitcoin.stackexchange, it takes about 15 seconds for a message to be propagated.

There are a set of checks to determine whether the transaction should be propagated. Note that these checks are not enforced. They can be ignored if certain nodes have different incentives or are malicious. One check is to just make sure that the transaction is valid within the blockchain. A few of those checks are for syntactic correctness, size in bytes is less than the MAX_BLOCK_SIZE as well as the size of the output must be legal monetary range. Then, it checks whether the transaction has been seen before which it can look up into the pending transactions list. Also, it needs to check that this transaction has not been incorporated in another block or has already been spent. This site has the documented protocol rules.

What are some checks done to see if the node should propagate the message?

• Transaction valid with current block chain
• default script matches a whitelist (avoid unusual scripts)
• won’t relay by default (Why not)
• haven’t seen before (avoid infinite loops)
• doesn’t conflict with others transactions previously relayed (avoid double-spends)
• Documented protocol rules

It is possible that the nodes will end up with different set of pending transactions or a different ordering of the transaction events. This is called a race condition in bitcoin. Because, only one person is defining the next block, that person who is mining will break up the race condition by publishing. This usually creates a clear set of actions on how to deal with the race condition meaning that one chain may get dropped because it would be a double spend after this block has been published. Nodes will usually accept the transaction that they have received first. A similar algorithm is used for block propagation as well where more information is found here. One thought you may have is what happens to these transactions or blocks that don’t get put on the main block chain. They are called orphan transaction and orphan blocks respectfully. An orphan block does not have a parent on the longest block chain. From blockchain info, one can see there are about 2-3 orphans blocks created per week.

Race conditions: Transaction or blocks may conflict

• default behavior: accept what you hear first
• network positions matters then
• miners have freedom to implement their own logic which could exacerbate these race conditions

Now, that we know what the network is doing, what is the size of the network?

While, not clear how to measure it, there are between 1,000 – 10,000 fully validating nodes. A fully validating node is one that it permanently connected, stores the entire block chain, and is actively hearing and forwarding every node/transaction. They also need to track the unspent transaction output (UTXO). These are all transaction that have not been put into the blockchain. However, there are some nodes that connect in and out of the network maybe just to complete a transaction or check some status of a transactions. In July 2014, the size of the block chain was 20 GB. Now in March 2017, it’s almost 100 GB. Also, while in Jul 2014, the UTXO was only 20 MB. In July 2015, it is 650 MB.

The lecturer, Joseph, mentioned that that the number of full nodes are decreasing. It makes sense since as time passes, to store the chain involves more space and RAM. Unless one is miner, or part of some large organization where you are actively getting some benefit for maintaining the full node, it doesn’t seem reasonable to continue doing. I admit there are people who will continue holding the nodes because they believe in bitcoin and for those people, that’s awesome. When people have clients running on their phones, or PCs, likely it is just a lightweight node. People also refer to these nodes as Simple Payment Verification (SPV) client. Bitcoin wallet programs tend to incorporate SPV nodes. A lightweight node just stores a subset of the transactions sent that may be needed to verify certain transactions. These lightweight nodes only work because they are trusting the fully-validating nodes to do their job. There has been much discuss on the internet regarding how many full nodes are enough and who should run a full node.

Bitcoin Blocks

This lecture talks about what bitcoin blocks are actually composed of in respect to the innards and what the code version may look like. If you’re wondering, it is transactions but it’s not that simple. The transaction are stored in an efficient fashion. They can be visualized pretty easily from a variety of sources.

Questions answered in this Post:

• Why does bitcoin bundle transactions?
• What are the two major data structures that the bitcoin block chain is composed with? Describe them.
• Where can you observe block contents?
• What is a coin base transaction

Why bundle transactions together?

• single unit of work for miners
• limit length of hash-chain of blocks which equals faster verification of history
• too much overhead would be created if you did it per transaction
• allow the hashed chain for blocks to be shorter because you only need one block for multiple transactions

Bitcoin blockchain has two data structures: hash chain of blocks and a merkle tree.

First, the bitcoin block structure contains a hash chain of blocks. A hash chain is that list of blocks where each block also contains a reference to the block previous to it.

A block contains three items:

1. block header
2. hash pointer to transaction data
3. hash pointer to the previous block in the sequence

At this point, even though you don’t know what the hash of the transaction data completely refers to, this structure should sound just like a linked list. When I say hash of some transaction data, I’m referring to that second data structure called a merkle tree. The merkle tree contains all the transactions included within the block. Merkle tree as you might guess looks like a tree specifically a binary tree. The tree contains all the transactions hashed in the leaves. Each node above that contains the hash of the two children that gets concatenated together. The root of the tree, the final node that combines the left and right children is the root hash. This is called the “merkle root”. The merkle root gets stamped on the block header.

I think of the Merkle tree as an efficient transaction storage tree that utilizes hash functions and allows one to verify if a transaction is within the block (tree) in just log(n) where n is the number of transactions in the block. Also, once the tree is computed, it’s easy to tell whether the data has been tampered with.

Right so now that we know what the structure looks like, what do you see if you looked at the written blocks. As I mentioned earlier, a block contains three components: block header, hash pointer to transaction data, and a hash pointer to the previous block in the sequence.

Sample block header

"hash": "000001aad2",
"ver"": 2.
"prev_block": 00001a3",
"time": 139.
"bits": 411900,
"nonce": 459841,
"mrkl_root": "89776..."


all the transaction data

"mrkl_root": "89776...",
"n_tx":354,
"size" 181520,
"tx": [
]
"mrkl_tree":[]
}


If you go to blockchain.info, you can easily see records of these blocks. There are quite a few places to view bitcoin blocks. I’ve listed a few more below.

1. Block Explorer
2. Insight
3. Blockr

This CryptoCoinNews article site teaches you to code a quick Python script to write your own block parser. It’s sparse without any UI but it’ll get the job done. Definitely give kudos to tenthirtyone.

Here’s the link to block that I’m going to explain further

You can see that this is block numbered 456842. As mentioned previous the header contains the hash. Also, it contains the previous block hash linked as well as the Merkle Root hash.

That’s just the beginning looking at this block since block chain pulls out all the components. The number of transactions is 202 transactions where the nonce was 3378386187. Remember the nonce was that small target value that the miner found which enabled them to write the next block.

When I looked at these there were a few values that were interesting specifically block reward and the first transaction listed.

What is a block reward?

A block reward is how much a miner gets getting the privilege to publish the next block. This value is $14,737.28. How was that value calculated? Currently the number of bitcoin a miner earns for publishing a block is 12 BTC. I looked at Bitcoin block half which shows the current block reward and the next time the change is going to occur.

Why does this transaction have the message “No Inputs(Newly Generated Coins”?

Ok, that sounds like a dumb question. It clearly indicates that this is a newly generated coin, which not surprising is called a coinbase transaction.

Unique characteristics of the coinbase transaction

1. has a single input and single output
2. input doesn’t redeem a previous output and thus contains a null hash pointer
3. value is fixed and halves every 210,000 blocks
4. special arbitrary parameter where one can put anything

Applications: Micropayments

This is a continuation of the Bitcoin Transaction Basics lecture. As mentioned before, I watched the entire third week in one sitting so some of my notes may reference previous posts. This part focuses on applications of Bitcoin scripts. There was quite a bit of material so I have broken down this part into 3 parts. This is the third part focusing on Micropayments. Here’s a link to the first part and second part. Honestly, I thought this use case help the most promise or concreteness initially. Then I realized I watched the lecture and came out with more questions and skepticism about why use bitcoin for this. Face palm….

Questions answered in this Post:

• What is a micropayment?
• What do micropayments look like without Bitcoin?
• What are some companies who are doing this
• What does it look like with bitcoin?

What is a micropayment?

It’s what you would think micropayment means, a transaction with a low amount. Specifically though it usually relates to an online transaction involving less than some currency standard like a dollar or a penny. Sometimes though it can be greater than that. As of March 2017, Paypal considers any payments less than $4.00 USD a micropayment. They also charge 5% + $.05 to merchants who process these transactions. Apparently Amazon also has a similar system but I was not able to find the exact documentation. Even so, how do you pay someone less than a penny when that’s not a physical quantity?

There are many technologies just handling micropayments. In most cases, there is some transaction fee associated with each payment which makes sense. These companies are providing a service to handle micropayments. Some may have a third-party micropayment provider who collects these small payments. Then the payment is made from a digital wallet when they have reached a potential threshold. A digital wallet is A site may choose not to make payments until the total amount is greater than 5 dollars. Some platforms have created “prepaid systems” where users add money to create a initial balance. Then the user can purchase these small purchases which may be less than a dollar but can be easily handled since the platform can just subtract from the platform.

Look at this list of companies who are making their business online payments incorporating micropayments.

• BuySimple
• Dwolla
• Boku
• Bango
• Paymentwall
• Fortumo
• milliPay
• payCrony
• LevelUp
• brainTree

Where does bitcoin scripts fit into this?

Bitcoin scripts give users a way to do efficient micropayments. Suppose there is an online music streaming system where Jim has to pay for every minute he listens to Bitotify until he hits some max threshold and then just gets that bill. Maybe, this is likely silly but Spotify should try this. Billing Jim every minute is expensive since if Jim listened for 129 minutes, there would be 129 transactions and the transaction fees would add up. So, why not just combine the payments at the end so that there is only one transaction.

This is what gets done. A MULTISIG transaction gets created which has the maximum amount that Jim could be billed and it requires that both Jim and Bitotify sign the transaction to release the coins. In addition there is a transaction which will refund all of Jim’s money but is locked until a certain time. Just remember that bit for now and I’ll go back to it in a little bit. After each minute, Jim signs a transaction indicating how many coins he owes. Thus by the time minute 20 occurs, Jim will have signed 20 different transactions which were only signed by Jim and thus are not on the blockchain. Jim tells Bitotify when he’s done and Bitotify signs the most recent transaction that was signed and publish that to the blockchain.

This generates the potential double-spends, then Bitotify should only sign the last double spend. Also, if Bitotify never signs the last transasction there is a feature call Lock Time.

Lock Time A time embedded into a transaction that will not publish a certain transaction until a specified lock time. The transaction will be invalidated if a specific block time or a specific point in time are put into blocks. Thus, this transaction of refund only gets kicked off if they haven’t been spent before.

So if you’re now thinking, SO WHAT!, I’ve got what the benefits are. This means that double spends are protected. Transaction fees are reduced since there is only one transaction being put onto the blockchain. There is no third party, it’s just between the two people.

So, escrow payments, green addresses, and micropayments are all examples of smart contracts. Smart Contract refer to contracts that are upheld be technical implementation of Bitcoin as opposed to laws and courts. In many of the examples, the true win for the blockchain was removing that single entity of validation. I know it doesn’t seem like that specifically when you think of the judge from the escrow payments and Mt. Gox from the green addresses.

A few companies that I’m interested in are Brave Browser, SatoshiPay, and FaucetHubIO. I think the biggest improvement with the Bitcoin micropayments is enabling anonymity payments. So if I like a website, I can donate funds from my browser with micropayments instead of having to face the previous minimum donate amount.

Applications: Green Addresses

This is a continuation of the Bitcoin Transaction Basics lecture. As mentioned before, I watched the entire third week in one sitting so some of my notes may reference previous posts. This part focuses on applications of Bitcoin scripts. There was quite a bit of material so I have broken down this part into 3 parts. This is the second part focusing on Green Addresses. Here’s a link to the first part.

Questions answered in this Post:

• What is a green address?
• What problem does green addresses try to solve?
• Why should this work?
• Why is there some negative stigma with this?

What is the problem?

Let’s start with what problem the green address is trying to solve. The goal was to try to do fast transactions for time-critical applications. Generally, bitcoin requires you to wait about 6 confirmations before knowing that your transaction has been incorporated into the blockchain. Thus, using green addresses is supposed to solve this as well as make sure that there are no double spending attacks.

My way of understanding green addresses was to think that the “green address” was more of a marker or reputation address which a third party holds for you. Also, I’ll walk through my example.

Say there is an ice cream seller (Ms. Icee) who accepts bitcoin. When the seller is online, most transactions work out well. However, she drives a truck around a neighborhood and at this point she isn’t connected to the blockchain. How can she still accept bitcoin? He will have made a deal with a respected organization (Mt Gox).

Suzie (prospective buyer) wants a chocolate eclair treat. She will tell Mt Gox who will withdraw from Suzie’s account using the “use green address” check point. Thus, the payment will be sent to the “green address” before forwarding it to Ms. Icee. An extra transaction to the special ECDSA keypair is made before forwarding it to the Ms. Icee. Ms. Icee can check with Mt. Gox and trust the payment because Mt. Gox is trustworthy.

This green address contains special trusted ECDSA keypairs that to indicate the origin of funds to a recipient. It is the Mt Gox controlled address that references Suzie. Everyone needs to trust Mt. Gox and Mt. Gox has to deliver on this.

Negative Stigma

However, Instawallet and Mount Gox fell apart because the transactions were compromised. While, I’m sure someone may try to implement this again, it at least is frowned upon here.

Applications: Escrow Transactions

This is a continuation of the Bitcoin Transaction Basics lecture. As mentioned before, I watched the entire third week in one sitting so some of my notes may reference previous posts. This part focuses on applications of Bitcoin scripts. There was quite a bit of material so I have broken down this part into 3 parts. The first section will focus just on escrow transactions. The next two posts will cover Green Addresses and Micropayments.

Questions answered in this Post:

• What is an escrow transaction?
• Why does escrow transactions appeal to people?
• How does using bitcoin help achieve it?
• Is this use case practical?
• Name some companies that do MULTISIG transactions.

What is an escrow transaction?

Escrow just means that when there is a trade between two people, there is a middle man who ensures both parties uphold their parts of the deal.

For example, say you want to buy a stuffed teddy bear from far far away. You pay the store owner and the store owner sends you the bear. How do you make sure that the store owners will actually give you the bear when they receive your money? How can the store owner make sure that they will actually receive money from you? Yes, you both could trust each other but that is unrealistic since you don’t know anything about each other. This is where the middle man comes in. Since they are in the business of trust and escrow then you have a better shot at trusting them to make sure the transaction takes place. Better yet, you don’t pay them until you’ve received your end of the deal.

Without the middle man, you give the money to the store owner. The store owner tells you he shipped the product.

Scenario 1:

You get the bear and all is well. Simple!

Scenario 2:

You wait 1 month. No teddy bear. You complain to the store owner who insists he sent the teddy bear. You wait 1 more month. Still no teddy bear. You’re angry and frustrated and still no teddy bear. You wait 1 more month. You find out that the store is no longer in business. You lost money and you have no teddy bear.

With the middle man involved, you give the money to the middle guy. The middle guy tells the store owner, I have the money. The store owner ships the stuffed teddy bear to me. I tell the middle man when I received the teddy bear. The middle man releases the money to the store owner. In this case, if you never receive the bear after 1 month, you can just cancel the transaction and get your money back.

With escrow is better for certain transactions!

Where does bitcoin fit into this escrow situation?

Same scenario. You want to buy a teddy bear from far far away. There is a special transaction called a MULTISIG.

MULTISIG (think Multisignatures)

You create a MULTISIG transaction that requires two of three people to sign in order to redeem the coins. Two of the people in the transactions are you and the store owner. The last in this middle man (Judge). The transaction sends the payment that you deposited only if two of the three sign it. The transaction gets put onto the block chain and then can be said to be “held in escrow”. The store owner can look to the blockchain and be convinced that you paid and decides to send the teddy bear.

Scenario 1

After, you say, “I got the goods”, and now the store owner and you can sign the transactions to redeem the escrowed funds. All is well and really the middle man did nothing since there was no need for them to sign anything.

Scenario 2

You claim “I never get the teddy bear”. Thus, you would never release the money to the store owner. The middle man has to step in and decide if the money should go back to you or to the store owner based on who they can deduce is right. If the middle person decides that you are lying and the store owner did send the bear, then the middle person and the store owner can sign the multisig to move the funds to the store owner. If the middle person decides that the store owner never sent the teddy bear, then the middle person and you can sign the multisig and move the funds back to you.

Is it hard to implement?

There is a CHECKMULTISIG instruction within the script language. This instruction to execute correctly says that it needs at least t out of the n public keys to be provided to be valid. In the case with the store owner, you need 2 of the three public keys.

Last time, I talked a bit about the Pay-to-script-hash script. The multisig is just a special type of the P2SH.

The tutorial from 2015 doesn’t work since the link to the actual tool to the site is expired.

Is there anyone actually doing this?

Yes!

1.EscrowMyBits
This site description is doing exactly what is described. There is even a judge program where people can sign up to be the judge.

2. Many Bitcoin Wallets use it, here’s just a few

• Onchain.io
• Coinbase MultiSig Vault
• BitGo
• Blocktrail
• Links to more companies

Bitcoin Scripts

This is a continuation of the Bitcoin Transaction Basics lecture. I watched the entire third week in one sitting so some of my notes may reference previous posts. This part focuses on “Script” the aptly names bitcoin blockchain scripting language. It’s based on Forth which meant little to me but hopefully means more to others.

Questions answered in this Post:

• Why are scripts used instead of just having a public key in transaction outputs?
• How do you validate a transaction output?
What is the proof-of-burn script
• What is the Pay-to-script hash?
• Name at least four characteristics of “Script”.

From the last post, “Each transaction output doesn’t specific a public key, instead it’s a script.” Know that the most import transaction type in Bitcoin is redeeming a previous transaction output by signing it with the correct key. Also, the inputs also contain scripts instead of signature as well.

Output: “Addresses” are really scripts
Simple Script shown has 4 instructions and is called a Pay-to-PubkeyHash.

OP_DUP
OP_HASH160
69e02...
OP_EQUALVERFIY OP_CHECKSIG

So the input address is also a script that gets combined with the output address
Concat(in.scriptSign | out.scriptPubKey)
​
scriptPubKey – output script that public key by specifying address to which the public key hashes
scriptSig – signature with that public key.
Together, this lets you claim a public key.

To Verify: Concat script must execute completely with not errors

Bitcoin scripting language(“Script”) History lesson

h5>Build for Bitcoin (inspired by Forth)

• simple and compact
• support for cryptography (hash function)
• stack-based
• limits on time/memory
• no looping
• 256 opcodes total(15 disabled, 75 reserved)
• logic/datahandling
• crypto CHECKMULTISIG
• OP_CHECKMULTISIGN
• verification requires t signatures

Bitcoin script execution example
This script basically has the sender of the coins specifying the recipient via their public key.


OP_DUP OP_HASH160 <pubKeyHash?> OP_EQUALVERIFY OP_CHECKSIG


1,2 does data instructions ie just push it on the stack
OP_DUP take the value on the top of the stack and duplicate
OP_HASH160 taken the crpytographic hash of the top of the stack
push the pubKeyHash? onto the stack
Now we know what comes next, need to verfiy if they are equal and if equal they get consumed
OP_CHECKSIG verify that the signature is valid, makes sure that the full transaction is valid

Steps in how the stack gets read:
1. Just a data instruction to be pushed onto stack

2.Just a data instruction to be pushed onto stack

3. Next call OP_DUP means creates a copy of the top which was pubKey and place on stack

4. OP_HASH160 means hash that key to create hashed_pubKey
5. Next you’re going to push on another intruction which is pubKeyHash
<pubKeyHash?>

6.OP_EQUALVERIFY as you can infer means check if the top two instructions are equal
<pubKeyHash?> == ?

7. Get the result and then does the signature verify by the instuction OP_CHECKSIG

8. Everything else gets taken off

It’s interesting that 99.9% scripts are just a simple signature script

Proof of Burn script

OP_RETURN
script that can never be redeemed
It’s provable that those costs have been destroyed
OP_RETURN throws an error if ever reached
The data comes after it will never be reached

What’s the point of proof of burn

Write arbitrary data into the block chain
like putting your name or timestamp
destroy a very small amount of currency into the block chain

AltCoins way to bootstrap other coins is by destroying bitcoin

Should senders specific scripts?
If a consumer is ready to pay, what do they need to with bitcoin

Me -> I’m ready to pay
Company -> Cool so we have this multisig which means you have to include a script requiring 2 of out 3 account managers to approve. Make sure it’s perfect or it won’t go through

Me -> Yeah, no.

Instead sender can just send a has of the script that needs

Pay to Script Hash instead

Idea: use the hash of redemption script
OP_CHECKSIG

OP_HASH160

OP_EQUAL

Can create a 2 step process
traditional script had right has

redemption hash deserialized and a second check occurs

so you’re removing complexity from the sender and there is an efficiency gain (only need to put a hash) all the rest of the complexity in the script is pushed to the input script.

Since this was added after the fact, it looks kinda a screwy

FYI: This site has more information regarding he scripting language. Also this is the Github.

Bitcoin Transactions

Honestly, initially, this lecture sounded intimidating. He’s like “we’re going to talk low level, real scripts, details and structure of bitcoin scripts in a precise way”. I had flashbacks of x86 machine code taunting me. Don’t be afraid though, it was well presented and well paced.

Also if you watch this lecture, count how many times the word “real” gets used?

Questions answered in this Post:

• What arguments makes transaction based ledger more suitable than account based for bitcoin?
• What are the components of a transaction?
• Explain the reason for a change address.

Bitcoin Consensus gives us:

1. Append only ledger
2. Decentralized consensus
3. Miners to validate transactions (making sure transactions are well-formed)

Assuming a currency exists to motivate miners!

He started out with this chart of what an account-based ledger (not Bitcoin) looked like before showing the bitcoin based ledger. The issues with this account-based ledger is that everyone needs to keep track of the account balances.

Transaction Based Ledger (Bitcoin)

Transaction	Input	Output	Signed
1	0	25 ->Alice	no one
2	1[0]	17 ->Bob,8 -> Alice	signed(Alice)
3	2[0]	8 -> Carol,9-> Bob	signed by Bob
4	2[1]	6 -> David,2 -> Alice	signed by Alice

2[1] mean transaction 2 output 1

This is all implemented with hash pointers which have been covered in week 1 as well as building upon it constantly. Thus by the time transaction 4 occurs, there is now a long chain. Transaction specific the number of inputs and number of accounts and thus keep track of the state.

For these transactions it’s important to note that when Alice gives 17 coin to Bob, she also needs to give 8 coin back to herself.

Change Address – because coins are immutable, the entirety of a transaction output must be consumed by another transactions. The left over amount that has the potential for being given back to the original input still has a transaction to receive the coin.

Efficient Verification This new ledger means that you do not have to go up the entire change. You only need to scan the block chain between a reference transaction (input) and the latest block.

Join Payments instead of doing 2 transactions

 

Transaction	Input	Output	Signed
2	1[0]	17 ->Bob, 8 -> Alice	signed(Alice)
3	2[1]	6 -> Alice, 2-> Bob	signed(Alice)
4	3[0], 3[1]	8 -> David	signed by Alice, Bob

There seems to be quite a few issues on the video which are mentioned below. I have changed the examples to reflect these inconsistencies.
https://www.coursera.org/learn/cryptocurrency/discussions/weeks/3/threads/ngwguLVDEeatew7zqUaXxg

Bitcoin transaction representation


{
"hash": "5a42...",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":0,
"size":404,
"in": [{
"prev_out":{"hash":"3be4",
"n":0},
"scriptSign":"3044"
}],
"out":[{
"value":"10.122",
"scriptPubKey":"OP_DUP OP_HASH160 69e... OP_EQUALVERIFY OP_CHECKSIG"}]}]}

3 parts

• Meta Data – Housekeeping that has size of trxn, # of input, # of output, and has of entire trxn
  
"hash": "5a42...",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":0,
"size":404

• Inputs – array of previous trxn (hash form)
  prevTrans
  Signatures
• Outputs – contain the value and the sum of all output
  value
  Recipient Address? but its really a script