SF Cryptocurrency Meetups


Note: These are snippets from a series of blog posts from my old site. I have compiled the pieces of those posts that pertain to the cryptocurrency meetups I attended in San Francisco during the summer of 2018. The date listed here is the date of the original post containing Entry 9.


Entry 1

I made it to an exciting blockchain meetup. The SF Cryptocurrency Devs meetup is co-organized by my good friend and fellow Colby math student Rob Durst. We discussed MimbleWimble. What's cool about this protocol is that incorporates blinding factors into transaction values, so that irrelevant parties can never learn metadata about transactions. Another cool thing is that unnecessary baggage is removed from transaction structure so that blocks are much less bulky.


Entry 2

I made it to my second blockchain meetup with SF Cryptocurrency Devs. I had free dinner (wrap + salad) thanks to Google catering the event. The featured speaker was James Prestwich of Summa. Prestwich spoke about the use of timelocks in cross-chain atomic transactions (XCAT) to build contracts that link top cryptocurrencies. At the meetup I also met Bram Cohen, the creator of BitTorrent!


Entry 3

At my third blockchain meetup of the summer, I met Aviv Eyal, co-founder of Spacemesh. The motivation for Spacemesh is to build a fair, secure, highly-distributed programmable cryptocurrency. The founders see the following problems in the present crypto space: mining can be impractical for the average Joe; mining often devolves into a competitive race; only one miner is rewarded; there is an incentive to hoard (#HODL) rather than to use currency; and others.

This new protocol runs on a blockmesh operating system. A blockmesh is a new craze in the crypto space: it's basically multiple layered blockchains. According to the Spacemesh whitepaper, a blockmesh is a layered DAG in which each node is a ​ block​, each block is a member of an indexed layer, and edges only point "backwards".

Spacemesh also replaces the prevalent Proof of Work model with Proof of Space-Time. A PoW proves that a user has put in a requisite amount CPU work. A PoST proves that a user has set aside a requisite amount of storage space computed over a certain amount of time; the Proof of Space is combined Proof of Time to verify that the space was not faked (thanks Taariq for the correction).

While this sounds great, there seem to be a lot of technical issues with Spacemesh, one being inability to deal with bots buying up storage and messing with the PoST model. This begs the question: maybe Proof of Work, centralized as it can get, is decentralized enough. At least I picked up a sick Spacemesh sticker for my laptop …


Entry 4

I guess I've become something of a regular at these meetups. This time around the presenter was John Pacific, an engineer at NuCypher. This protocol deals with a type of cryptography known as proxy re-encryption to securely store and send data. This presentation was really difficult to follow due to the high-level math involved. What I did glean, however, is that NuCypher truly could have a significant place in the future of crypto. The key concepts in this protocol are: the Umbral algorithm, developed at NuCypher; Shamir's secret sharing; non-interactive, symmetric encryption; IND-PRE-CCA security; secp256.


Entry 5

A few weeks ago I attended a whitepaper reader for Mimble Wimble (see Week 1 summary). I attended another meetup on Mimble Wimble, this time featuring Quentin Le Sceller. Quentin is on the developer team of Grin, an open source project with the aim of filling the gaps in Mimble Wimble. We also discussed Dandelion, a protocol whose development is motivated by the need for privacy when it comes to transaction history. With currencies like Bitcoin, eavesdroppers can view entire user histories in plaintext; the only claim to anonymity for Bitcoin is that user histories are published under pseudonyms. From a basic privacy standpoint, this really doesn't cut it. The motivation behind Dandelion is to redesign the peer-to-peer network from first principles to provide provable anonymity guarantee. For a detailed introduction to Mimble Wimble, check out this introduction on GitHub.


Entry 6

I decided it was time to check out some of the other cryptocurrency meetups in SF, and so went to a Bitcoin Devs meetup. The speaker was Peter Wiulle, co-founder of Blockstream. He gave an overview of updates to come to BTC in the coming years. Although I am nearly done with the Bitcoin Core scene (details in a forthcoming post), it was helpful nonetheless in improving my technical understanding. Wiulle spoke on upcoming updates such as Taproot and Schnorr.

Schnorr is set to be to biggest change to Bitcoin Core since Segregated Witness. The goal in implementing Schnorr is to give users a better way of generating keys in terms of privacy and scalability. How?

  • Firstly, Schnorr signatures are built on the same assumptions as the Elliptic Curve Digital Signature Algorithm (which is used in bitcoin today), which allows for compatibility.

  • Schnorr improves scalabilityby being more compact, thus reducing the data footprint of the blockchain.

  • Schnorr improves multi-signature transactions by allowing multiple signatures to be combined into a single delegated signature that carries the authorization capabilities of the separate signatures.

Taproot is an idea that serves to improve the privacy of MAST. The latter is a technology which allows users to more efficiently  describe the requisite conditions under which their bitcoin can be spent; this is a necessary technology in the presence of scripts (click here for a great introduction to MAST).


Entry 7

This presentation was led by Mark Nadal of GunDB, a protocol for P2P synchronization (superior to Socket.IO). Mark talked about a solution he is implementing to create scalable, accessible realtime cryptographically secure data sync. The presentation was really quite intense. A main takeaway is that DAGs (directed acyclic graphs) present major scalability challenges that give rise to centralization. To solve this issue, blockchains must become mutable. This solution can retain transparency, etc. and remove auxiliary information.


Entry 8

I heard of this event just one day in advance, and managed to make it there with some of my Horizons friends (it was just down the street). Making up the panel were Jed McCaleb of Stellar (also Ripple and Mt. Gox), Brian Behlendorf of Hyperledger, and others. It was refreshing to see leaders in the crypto space speak frankly and chat informally about the present and future of crypto as well as the historical roots of the decentralized Internet. Events such as these reaffirm my belief that crypto communities, the Linux Foundation, and other similar groups must play a noteworthy role in society's future.


Entry 9

Two of the biggest buzzwords in tech: blockchain, and IoT (Internet of Things). Why not combine the two? Many projects have begun to do so. IoTex is an IoT-oriented blockchain platform emphasizing scalability, privacy, developability, privacy, security, and did I mention privacy?

In all seriousness, I was really impressed with the IoTex team's background as well as its focus on cryptography.

A major component of the project is Roll-DPos (Roll Delegated Proof of Stake). DPos is a consensus mechanism limiting block production to a fixed number of delegates; it allows for faster block production and lower latency than with other mechanisms. Roll-DPos is IoTex's own randomization design. To enhance the democratic aspect, every epoch, token holders can vote for a producer and are able to view to nominated nodes' available hardware and software resources. Nominees are filtered into a candidate pool via voting, after which the producer is selected randomly from the pool.

More details on IoTex can be found here and here.