Programming

Lecture 3: Bitcoin overview There are three Bitcoin protocols Consensus Protocol - decides what the ledger is Transaction Protocol - assigns meaning to the ledger Network Protocol - the P2P protocol which decides what new should be added to the ledger Consensus Protocol Bitcoin fields (Virtual field) Hash - 4 bytes. SHA256-squared. This is not part of the block but is calculated on the fly. Version - 4 bytes. Set to 3, might never change. Previous block - 32 bytes. Hash of the previous block on which we build this block. mrkl_root (Merkle root) - 32 bytes Time - 4 bytes. Timestamp of mining the block. Bits - 4 bits. This is the difficulty level. Lock time - 4 bytes. The transaction cannot be posted on the blockchain till the lock time constraint is met. Nonce - 4 bytes. Random nonce tweaked to find a block with the right difficulty. n_tx & txn_data in the Merkle root are stored separately. The nonce is only 32 bits, Changing that might not be sufficient to get the desired number of difficulty(70+ zeros). Therefore, changes can be made to the Coinbase transaction (explained below) to generate more randomness. ...

Lecture 2: Creating a digital currency Desirable properties of a good digital ledger No deletion Temporal ordering Global consensus Semantic correctness Live - writable, no DOS, no censorship Attempts to create a digital currency in the increasing order of sophistication. A signing key based approach can confirm the authenticity of the transaction but cannot prevent double-spend. Append-only ledger with signing keys ensures a temporal ordering and global consensus, thus, prevents double-spending. Sign “new transaction + hash of the previous transaction”. But if there is a single trusted signing authority, it can still give different signing blocks to the different parties and engage in double-spend. Or it can append invalid transactions to the ledger. To reduce the risk, we can have n signers and require k <= n signers required for a transaction to be a valid part of the ledger. Further safety can be ensured by rotating the trusted signers. The signers will build on (one of the) longest valid chain. The signer will reject any chain with a bad block in it. If the majority of the signers is honest, this works. Otherwise, it does not. A malicious actor can perform a Sybil attack on the system by generating tons of signers who are participating in the system and hence, a majority of signers might end up representing a single entity. Bitcoin (Nakamoto consensus) treats everyone as a trusted signer. The signer in round n is the first signer to solve a proof-of-work (PoW) puzzle. There are no signing keys anymore. The random nonce of the block which leads to H(block) <2256 - d suffices as the valid proof of signing. Two signers can end up signing simultaneously, but eventually, one of the chains will become longest and wins. Each block ~ 1MB and each transaction ~512 bytes. After your transaction ends up in a block, wait for up to 6 blocks to ensure that a different chain won’t become the longest one. Majority of the mining power should be honest though, 51% attack is possible on Bitcoin.

Lecture 1: Introduction Bitcoin is a cryptocurrency with distributed trust. The blockchain is a public append-only ledger. The append-only property is sufficient for having a currency. Hash functions: H: M -> T where |M| » |T| that is space of messages is larger than space of the hash. If H(m0) =H(m1) => collision. Hash function H is collision-resistant if it is hard to find the collision of H. For example, SHA-256 maps long strings to 256-bit hashes. ...

Don’t use platform fragments (android.app.Fragment), they have been deprecated and can trigger version-specific bugs. Use the support library fragments ( android.support.v4.app.Fragment) instead. A Fragment is created explicitly via your code or recreated implicitly by the FragmentManager. The FragmentManager can only recreate a Fragment if it’s a public non-anonymous class. To test for this, rotate your screen while the Fragment is visible. FragmentTransaction#commit can fail if the activity has been destroyed. “java.lang.IllegalStateException: Activity has been destroyed” Why - This can happen in the wild where say right before FragmentTransaction#commit() executes, the user gets a phone call and your activity is backgrounded and destroyed. How to trigger manually - The easy way to manually test this is to add a call to Activity#finish() right before FragmentTransaction#commit. Fix - Before doing FragmentTransaction#commit(), check that the activity has not been destroyed - Activity#isDestroyed() should return false. ...

A JPEG file can have Exif metadata which can provide the rotation/translation field information for a raw JPEG image. So, a landscape raw JPEG image could actually be a portrait because it’s EXIF orientation could be set to ORIENTATION_ROTATE_90, the best way to handle such scenarios is to either use a library like Picasso or Glide or at least learn from them. Here is a piece of code from Picasso which loads a JPEG as an in-memory bitmap and performs the right translation/rotation. ...

I installed Android Studio via homebrew “brew cask install android-studio” as a part of my automated Mac OS setup. Recently, Android Studio prompted me that an update is available. When I accepted to update, it failed with an error “Studio does not have write access to /private/var/folders/wt/rjv6_wcn4f97_2nth7fqftqh0000gn/T/AppTranslocation/19A80F28-865B-41FC-AA87-B8E43C826FCB/d/Android Studio.app/Contents. Please run it by a privileged user to update.” This error was confusing; I was running Android Studio as myself, a nonprivileged user and the same user owned this directory. Googling it a bit for AppTranslocation took me here. ...

All languages have certain semantics for dealing with error cases. C deals with them by setting error codes. Java deals with them by throwing exceptions. JavaScript deals with them by throwing exceptions as well but unlike Java, it does have any concept of checked Exceptions. The JS interpreter just stops. And this has some interesting implications in hybrid scenarios like a Webview based app. Consider a simple Android app where most of the code is in JavaScript but is making a request to Java layer. ...

The core idea behind resumable upload is straightforward if you are uploading a big file, then you are going to encounter users in the network conditions where they cannot upload the file in a single network session. The client-side code, to avoid restarting the file upload from the beginning, must figure out what portion of the file was uploaded and “resume” the upload of the rest. How to do resumable upload Before starting the upload, send a unique ID generated from the file contents to the server like MD-5 or SHA-256. The server decides and declares what the format of that unique ID is. Next, the server responds with an offset which indicates how many bytes server already has. The client uploads rest of the bytes with a Content-Range header. ...

Some video streaming websites like YouTube provides an option for speeding up/slowing down videos; some don’t. The trick is simple, find out the Video object via Js 1 document.querySelector("video") and then set its playbackRate property to the desired value ...

This is a long post. It covers several decisions like API version, distribution beyond play store, UI & network performance, and minimizing RAM, disk, and battery usage.