Greg Brockman

Page 2


#define CTO

I joined Stripe as an engineer in 2010. I began by working on the backend infrastructure: designing the server architecture, creating our credit card vault, and producing internal abstractions to make people’s jobs easier. I loved writing code, but I also spent a bunch of time on other things: figuring out our recruiting program, shaping the culture, or making our first T-shirts (which have been banned since we hired our first designer). I wasn’t doing these things particularly because I preferred them to coding: instead, I had a very strong vision of the environment I wanted to be a part of, and I was willing to go out of my way to make it exist.

As time went on, I accumulated more and more responsibilities which were not strictly writing code. As Nelson Elhage liked to put it, my job became full-time “early employee”. My days were filled with writing cultural guides, acclimatizing new...

Continue reading →


A Twitter bot which issues its own currency

(Update: I’ve now taken my instance of the bot down, but the code should still work if you want to run your own.)

I spent some time this weekend putting together a proof-of-concept Twitter bot which issues its own “upvote” currency. You use it by tweeting something like the following:

@stellarjob +++@thegdb cool bot!

Live demo

!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');

The bot then walks the user through linking their Stellar account and extending trust for its +++ currency. Once the trust has been granted, the bot issues a +++ credit. Each subsequent upvote results in another +++ being issued.

Because the credits are issued on Stellar, they can be...

Continue reading →


What to build on Stellar

Many people have started building Stellar applications and infrastructure, but even more have been asking for suggestions or a place to get started. Here are a few examples of the kinds of things you could build on top of Stellar. They’re not all new ideas, but they would be new to the Stellar ecosystem.

Applications

  • Games. Many games already have virtual credits. Imagine embedding those credits into the Stellar ledger (or just making those credits be stellars). This would make them instantly tradable, and something that users could bring with them from game to game.
  • Psychology experiments (just let people know that they’re in an experiment). There are many classic experiments, such as the dollar auction, which are really interesting to read about. With Stellar, you could actually implement them and see how people behave in practice.
  • Apps for tracking and paying back expenses among...

Continue reading →


Setting up federated addresses with Stellar

Fun fact: the username you sign up with on Stellar’s hosted web client is actually a federated address rather than a username. That is, the username gdb is actually short for gdb@stellar.org. If you control a domain, you can set up federated addresses for your domain.

We’ve now set up federated addresses on stripe.com. You can now use your client to make a payment to gdb@stripe.com.

Setting up federation

You can set up federation for your domain too — it’s pretty easy (though per the below, the protocol may end up being changed). I’ll walk you through how a client or browser resolves gdb@stripe.com.

stellar.txt

First, the client finds Stripe’s stellar.txt file by requesting the following URLs until one works:

  • https://stellar.stripe.com/stellar.txt
  • https://stripe.com/stellar.txt
  • https://www.stripe.com/stellar.txt

We’ve set up our stellar.txt on stripe.com, which is served as...

Continue reading →


The Stellar object model

Stellar attempts to encode a relatively direct model of real-world
finance. Here’s an overview of the main concepts you need to know to
start building using Stellar’s API.

Credits

Think of the credit system as a graph. Each account is represented as
a node, and the credits are represented as per-currency weights
on the edges. For example, if Joyce owes me 10 GBP, then from my
perspective the balance between us is set to +10 GBP. If she later
gives me 15 GBP in person, then our balance should adjust down to -5
GBP.

From her perspective, everything is the same except the signs are
reverse.

Note that it’s possible to issue credits in arbitrary (even user-defined) currencies. The implications here are pretty interesting, and I’ll likely address them in a subsequent post.

Trust

Trust lines are effectively permission for an edge’s nodes to move the balance in one direction. By default...

Continue reading →


System Design: Stripe Capture the Flag

We launched Stripe CTF 2.0 on Wednesday. Thus far we’ve had 14,000 signups, and over 500 people have captured the flag. Designing an architecture to handle this many users, all running their potentially malicious code on the level servers, was definitely a challenge, but it was also a ton of fun.

Our first and foremost design goal was pretty simple: don’t let people root the machines. It’s horrendously difficult to keep a shared Linux login machine secure, so the best you can do is apply all of the security countermeasures you can think of. Each level server is configured in the same way (maintaining multiple configurations is a great way to end up with an oversight due to increased complexity). All user-facing services run in a chroot with only /home, /tmp, /var/tmp, and /var/log writeable. This is implemented by mounting a filesystem (created using debootstrap) at /var/chroot and...

Continue reading →