Updated directions for converting eth to dai using metamask

Screen Shot 2019-02-10 at 10.11.14 PM

As of the end of the month of January 2019, the original oasis.direct page has been replaced with https://eth2dai.com/. This page has expanded functionality but if you’re looking for a simple place to convert your ether to dai stabletoken, you can use the old oasis.direct frontend which is now independently hosted on IPFS.

goto: https://forkoasisdex.com/direct/

How to convert ether to dai stabletoken using metamask wallet.

WARNING: Using cryptocurrencies means accepting the risk that your funds can be irrevocably lost or stolen. Use best practices when managing your private keys! There is no substitute for knowledge and proper precautions.

This guide will walk you through converting ether into DAI stabletokens using a decentralized exchange. This guide assumes you have metamask installed as a browser extension and that you have ether in your metamask wallet that you’d like to convert (minus an additional gas fee) into the DAI stabletoken. You can add funds to your wallet using an exchange such as coinbase. Completing this tutorial on Ethereum mainnet will require converting at least $30 plus a fee into 30 DAI stabletokens.

What is DAI?

DAI is an ethereum stabletoken. Unlike other stabletokens (e.g. Tether, USDC), DAI does not use fiat as collateral. Instead DAI uses a dynamically allocated pool of ether to maintain the value of DAI.

DAI is a “soft” peg to the US dollar. As of this writing the maximum and minimum values of DAI were $1.06 and $0.97 respectively. The token usually trades within a cent or two of $1. DAI has maintained its peg of $1 USD since it’s inception on December 18th 2017. This gives the DAI stabletoken the distinction that it has weathered the erosion of value of ethereum and other cryptocurrencies relative to the US dollar experienced since their peak in January 2018.

dai-price-chart

Stablecoins are useful because they enable the exchange of goods and services using a cryptocurrency while keeping the price denominated in a global reserve currency (in this case the US dollar). Stabletokens are also useful as a hedge against the excessive volatility of cryptocurrencies, effectively allowing users to increase their ethereum holdings if they can correctly anticipate a reduction in the eth -> usd exchange rate. Stablecoins could potentially serve as means to stabilize local economies that suffer from corruption or high inflation (e.g. Venezuela, Zimbabwe. See step 3).

How does it work?

While most users will only use DAI as a medium of exchange, there is a complex credit market operating in the background. This is what actually maintains the stabletoken peg. Note that it isn’t necessary to understand this part of DAI to use it as if it were USD. Regular users will not create DAI, they’ll simply exchange their ether for it at a decentralized exchange.

The DAI peg is maintained using a game where borrowers act selfishly, and in doing so maintain the peg. In this economic game, the supply of DAI is regulated in response to demand for the stabletoken. If the peg slides too far in either direction of $1, borrowers can get “free money” from an exchange, which in turns causes the price to go in the other direction. If the demand for DAI stabletoken goes up, borrowers are incentivized to create more DAI. If the falling demand for DAI pushes down the peg, borrowers are incentivized to reduce its supply. Meanwhile, bots known as “keepers” ensure there is sufficient collateral in the system. Keepers are free to liquidate insolvent loans once they fall below a global threshold (150% collateral). Borrowers can prevent being declared insolvent by ensuring that there is sufficient collateral backing their loan.

The stabletoken protocol is implemented using a two types of erc20 tokens: MKR and DAI. DAI is the actual stable token, MKR is a governance token that is used to create loans and allow users to participate in the governance process.

The lender(s) of last resort:

Every store of value includes some level of risk. DAI is not FDIC insured. Instead it uses market mechanisms to ensure that DAI is safe to hold. In this system, the lender of last resort is not a single entity (the Fed), instead it is the total pool of DAI collateral.

Excluding systemic risk to the DAI stabletoken system itself, the risk in the DAI stabletoken system is assumed by MKR holders, i.e. users who create DAI by taking out a loan on their ethereum holdings and receiving DAI in return. These users take responsibility and are potentially rewarded for the task of regulating the amount of DAI stabletoken in existence.

Users who merely exchange DAI for goods and services can safely assume that their tokens have stable value in the short to medium term. The DAI peg could fail in a “black-swan” event or a financial attack where the markets for MKR or Ether collapse to a very small value. Presumably the decentralized nature of these markets makes them resistant to these types of collapses, however these markets are still quite young, so proceed with due diligence and care!

Procedure:

Step 1: Add DAI ERC20 token to metamask ethereum client
Follow these directions to configure your metamask wallet to store DAI stabletokens:
Adding tokens to metamask
How To Add A Custom Token In MetaMask
Dai token on etherscan

Step 2: Use oasis.direct to convert ethereum in your wallet to DAI stabletoken
Oasis direct is an open-source, decentralized eth to dai exchange. There are no fees other than the gas fees required to execute the smart-contract. NOTE: This step will be updated soon

Step 3 (optional): Donate your DAI to Venezuelans
Airdrop Venezuela

See Also:
oasis.direct github
Maker DAI Dashboard
DAI token contract
FAQ: Possibly everything you ever wanted to know about Liquidation
MakerDao Docs on Keeper Bots
Helpful medium post explaining CDP market dynamics

Modify jenkins sshd server to run interactive bash shell

Step 1: Modify jenkins sshd server

This will additionally run a bash shell
Turn on jenkins sshd server and set port.

// Activate sshd server
// "Manage Jenkins"
//    ->
//    "Configure Global Security"
// then copy/paste this into script console

import jenkins.model.*;
import org.apache.sshd.server.shell.*;

def inst = Jenkins.getInstance()
def sshDesc = inst.getDescriptor(
    "org.jenkinsci.main.modules.sshd.SSHD")

sshDesc.sshd.setShellFactory(
    InteractiveProcessShellFactory.INSTANCE)
println 'Done with step 1!'

Step 2: get sh shell

ssh -p <jenkins-sshd-port> <jenkins-fqdn>

Step 3: get python shell

python -i

Step 4: spawn pty bash shell

>>> import pty
>>> pty.spawn("/bin/bash")

NOTE: bash shell has a weird double echo effect

crafting commits

“Anyone moderately familiar with the rigours of composition will not need to be told the story in detail; how he wrote and it seemed good; read and it seemed vile; corrected and tore up; cut out; put in; was in ecstasy; in despair; had his good nights and bad mornings; snatched at ideas and lost them; saw his book plain before him and it vanished…”

– Virginia Woolf

Good code is easy to understand. In a good codebase, changes to code are easy to understand. This requirement is fundamentally at odds with the messy, organic way that code emerges from the mind of the developer. Thankfully, git comes bundled with tools to help developers mold their changes into a concise, logical structure.

This is the first in a series of blog posts on crafting good commits. In future posts, we’ll explore 3 options to basic git commands that can help us make good commits: git add --patch, git merge --squash, and git rebase --interactive.

But first: what is a commit and what makes it good?

Understanding the past:
Software development is a team effort and code itself changes constantly. Most authors write for the general public, whereas code’s authors and audience are usually one and the same. While prose can be considered finished (or perhaps merely abandoned) at the time of publication, software must be supported. Older versions must be patched; breaking changes reverted. These facets of software development have led to an engineering standard: code repositories must have logically coherent history of changes. These changes come in discrete steps, or commits. Commits are comprised of a diff, as well as some metadata, usually in the form of a commit message. Commits form the basic, atomic units of change in a codebase. In git and other distributed version control systems, commits are nodes in a directed acyclic graph.

commit-graph

The rigours of composition:
At odds with the need for a logically coherent history of a piece of software is the way it is created. Crafting good commits is usually an afterthought to the initial work of writing code. Inspiration is fleeting; better to get your ideas down before they’re gone forever. However, a few sketches of code can quickly turn a working tree into a tangled mess of disparate, disconnected changes.

xkcd-git-commit-comic

Good commits:
Good commits have some useful properties.

Property: Atomicity
Commits should comprise a single logical change. Good commits are cohesive and self-contained. They encapsulate a single, logical change to the codebase. Commits to master or stable branches should have the added property that they result in a passing build.

Property: Revertability
Good commits can be reverted. If a new feature has a bug or introduces a regression, it should be possible to revert a commit or series of commits to rollback to a previous good state.

Property: Portability
Good commits are portable. It should be possible to port a commit or series of commits from one branch to another. For example, if a feature needs to be backported to a previous release, it should be clear which commits correspond to the feature, and it should be possible to apply these commit(s) to the release branch (say using rebase or cherry-pick).

Now that we understand a bit more about commit is, what makes a commit good, and useful, we can start exploring some tools that can help ease the tension between turning ideas into code, and making good commits. Stay tuned.

Hashimoto on Terraform and Consul

In this infoq talk, Mitchell Hashimoto gives an overview of Terraform and Consul: what they actually do, and how you might use them to solve specific problems. The best thing about this talk is the chance to see how Hashimoto envisions some of these problems that are common to almost all large scale distributed software systems, and how his vision shapes the tools that come out of Hashicorp.

Many great points made in this talk, but if you were to pull away one key point form this talk, it’d be this: containers are probably here to stay, but they aren’t the entire story when it comes to running distributed systems. In the midst of the overwhelming (and justified) hype surrounding Docker and its burgeoning software ecosystem, it’s important to note that a lot of problems in the datacenter are orthogonal to containers and the problems they aim to solve.

While containers do solve a lot of problems, and people are quick to adopt them because of their advantages, we all realize very quickly that their are a lot of other pieces to this puzzle that containers just don’t address at all

Source: Orchestrating Containers with Terraform and Consul