This is a picture of the book Red Mars, the first volume in the Mars Trilogy, by Kim Stanley Robinson. It too is about terraforming (among other things). Its a fun book, I recommend it.

But today, I am going to talk about the other terraforming involving dev ops – and that is Terraform by Hashi Corp.  Terraform is a framework for making and executing automated script based deployments. I have seen this story before with ansible, salt stack, chef, puppet there are probably more.  I have always revered back to bash scripts because I am old school and these tools were not 10x. But then I started playing around with ILP nodes and used their fantastic terraform scripts.  (ILP is a technology that provides cross blockchain interoperability).  Basically the scrips spun up so many aws services in such an elegant design, that, if I would have done it by hand, it would have taken me forever and would probably look a bit gnarly  (since I would just want to get it over with and would not take time to make in beautiful).

Fellow recurser Akiva gave a lovely terraform tutorial, which really demystified everything. We talked a tiny bit about providers. Providers, in terraform, are definitions for, or extensions of, services that you are integrating with e.g., AWS, GCS, Digital Ocean, Heroku, etc. I would like to write a terraform provider, but I am not sure what environment needs one.  If someone comes up with one let me know.

I missed the consciousness reading group, because terraform ran over and I just wanted to get back to my rust cryptopals.  I am really enjoying programming in Rust, feel like I am getting a hang of the language.  I sort of just want to lie on a couch and program in Rust reverie.

Ben and I continued our ad hoc contract reading group and looked at ERC721 in openzepplin  – Non Fungible Tokens (ie cryptokitties).  There was a bunch of weird magic involving hex referring to function stubs. Not quite sure why we need that.  We are considering submitting a sample contract for ERC721 to github- which would be exciting.

I also did the first chapter of cryptozombies, a fun website that walks you through recreating cryptokitties but with zombies.  I was fast, fun and reinforced my cryptocurrency knowledge – also I think it was a well made app, but the compiler does not recognize blank lines and spaces – where can I send a git pull. I kinda want to create cryptosucculents now.  The day is not over yet and I hope by the end of the day to have deployed my UnpaidLaborCoin app via heroku. This would satisfy my tech proof of concept for the prayer blockchain and remove the unknown unknowns (for the most part). I also hope to finish the first two lessons in fast.ai.  If I can get this done – then maybe I can write up a tutorial tomorrow on creating a blockchain app with truffle and react and revisit the Haskell music prayer wheel.

There was this random url in my browser.  Its cool so I am including it hear. I am not sure where I got it from but who does not love Tan Lin?

Today I continued building out the prayer project by adding token functionality to the reactjs project via the abi and address generated in the build file of the truffle project.  This was punctured my slow going Rust implementation of cryptopal solutions.

In the morning Ben and I went over setting up truffle and the ganache to create a ERC20 token. It was helpful for me to review what I had learned by teaching another person. And we founds things that neither of us knew.  The best though,w was taking a deep dive into the ERC20 documentation (hence the title of this blog post). This raised two questions.

First, where is the documentation that tells us to define the symbol and description variables of a ERC20 Contract? ERC20Details.sol! (Thanks Ben) Second, what is up with the Approve and Allow functions? Why does ERC20 need them?  I have read a bunch of different answers that range from:  it is because everything on ethereum operates by push notification (there are no listeners), to it is a security measure to make sure that only a certain number of tokens can be transferred by a smart contract execution.

I still don’t have a great intuition around it, but I read this very helpful article, and I think I somewhat get it. It is sort of a a failsafe.  I would like to read through the documentation for ERC721 with Ben tomorrow. These sorts of exercises are very useful and rarely are you able to engage with them when you have tight deadlines and just have to sling code.

This afternoon there were fantastic non-programming related presentations about everything from how the democratic party works, to polyamory, to hiking the pct. Fellow recursers are so interesting!  I followed this with some cryptopals with Austin and Liz. We discussed different algorithms for implementing a weighting algorithm to figure out which message is most likely to be a  plain english message base on word frequency.

One thing we talked about was using the sum of least squares as a weighting algorithm. This I somewhat remembered from my finance days and finding the best fit of a line among a cloud of points. It is the square of the standard deviation. So for example if ‘e’ is found at a .15 frequency and in this message it is found .25 frequency the standard deviation and ‘f’ is found at a .20 frequency and in the message at a .25 frequency. We average the difference so .10 + .05 = .15/2  = .0072 subtract this from each frequency. so .25 – .075 and .25 – .075  then square each result (to get rid of negative numbers).  Finally average those out  – this is sigma squared or the Variance. When you take the square root, sigma, this is the standard deviation.   The standard deviation brings everything back into the same units as your original measurements or quantities.

This reminds me of options trading, where you are trading the volatility rather than the price. That means you are looking at sigma – the standard deviation in stock price. This helps you understand the risk that a option will move X standard deviations away from its current price.  But it means that you think there is a bell curve (normal) distribution of prices.

This is not the case! First, there is skew – ie the curve is not symmetrical.  You also have kurtosis which describes the distribution at the tails of the curve which also do not follow assumptions that they are 3 standard deviations away – yada yada yada. Both of these could be applicable to the word frequency weighting algorithm.  Word frequency probably does not follows a bell curve (normal) distribution.   There is also the concept of Heteroskedasticity which refers to sigma changing over time. That is, volatility is not constant over time.  I dont think this is applicable our problem of word frequency unless we are looking at messages trying to be deciphered from a long time ago -but then I would just get the word frequency from that moment in time.

I am super exhausted. I wanted to say something about log normal and keeping your volatility between 0 and 1 BUT it is quite possible whatever I just wrote does not make sense, so I am going to hold that thought.

Austin came up with a brilliant idea for the physical implementation portion of the prayer blockchain. It is super cool and I cannot wait to build it. I am going to keep it secret.

And the bookstore from yesterday’s post is topos bookstore and there is another group Patrick told me about is called I/O that hosts radical-tech events at various locations. Thanks again Patrick for telling me about these and sending me the info on zulip!