#14 - The Summer of Bitcoin Experience
Chat with Summer of Bitcoin intern Krystal Maughan and best bitcoin jobs for freshers!
Hello Summer of Bitcoiner!
Thought of the Week
Are you starting out in bitcoin today and want to learn how to build apps on the bitcoin blockchain?
Build On L2 (BOL2) is a community-led effort by contributors and companies building on Core Lightning and the Liquid Network. It's a space to connect with bitcoin builders, product managers, designers and developers through events and mentorship programs and learn from experts building the future of bitcoin.
Completely free and accessible, each layer-2 protocol has a respective community platform that will host activities including:
Localized hackathons
Virtual networking events
Project bounties and other incentive programs
International builder tournaments
Career development programs
Mentorship and coaching
AMAs with leading developers
Visit buildonl2.com to join the community and learn how to build killer apps on bitcoin.
Interview with Krystal Maughan
We spoke with Krystal Maughan, a student researcher at the University of Vermont, United States. Krystal participated in Summer of Bitcoin 2022, with René Pickhardt, on quantifying the robustness of the lightning network and empirically understand its routing constraints - which we go deep into in this podcast. Krystal also shares her experience working on open-source and advice on how should one go about it.
Listen to the full conversation on Spotify here.
You can also watch a video of the conversation here.
Read the full transcript:
ADI SHANKARA: Hey Krystal, welcome to the Summer of Bitcoin experience. Great to have you.
KRYSTAL MAUGHAN: It's great to be here. Thank you so much Adi.
SHANKARA: Let's start with your introduction. Can you tell the audience who you are and where you come from?
MAUGHAN: Sure. So I'm originally from Trinidad and Tobago, which is in the Caribbean, I did my undergrad in Ithaca in upstate New York. And now I'm a PhD student at the University of Vermont.
SHANKARA: Awesome and what is your PhD about? What research areas do you look into?
MAUGHAN: So I originally started my PhD working in particularly machine learning, so interoperability, which means that I'm looking at, well, in one particular project that was long term, we looked at this mechanism called prediction sensitivity, which allowed us to look at gradients, and, prediction. So if you have a point that has a particular gradient, and you look at a flip to prediction - let's say you have a binary variable or what we call protected attributes, so something, let's say someone is male in that particular data point, and we were to switch it to female. If we have an algorithm that predicts significantly different from the prior prediction, you might want to see that there's something wrong with the algorithm or you might want to look into the algorithm.
And this is really useful mechanism that could be used for high stakes auditing of algorithms. So that was kind of a project that I worked on in my first two years. Now I shifted well, actually a couple months from around 2021 I shifted to working on cryptography. Cryptography starts off with the premise that in the future, we will have quantum computers and quantum computers, unfortunately, unlike classical computers, are able to kind of break some of our current encryption systems because some of our current encryption systems rely on this thing called the discrete log problem or DLP for short.
So that means that a lot of our authentication systems and maybe things that we use to authenticate browsers, check our bank balances and that sort of thing will be rendered insecure. So, post quantum cryptography, which NIST which is the National Standards Committee for these kinds of protocols, had a call in 2017 to look at protocols that might be quantum safe. And Isogeny-based cryptography is one such protocol. So that particular protocol is based on a specific pairing of elliptic curves called lsogeny. So it's called an amorphous morphism map between two elliptic curves. And that allows you to create this thing called an expander graph. Which, because of its hardness, of pathfinding makes a quantum safe. So a lot of cryptography protocols in general, have some kind of hardness property. Unfortunately, that doesn't necessarily make them quantum safe. But in this particular case, isogeny-based cryptography should be quantum safe. So that's something that I'm working on right now for my dissertation.
SHANKARA: Wow, that's quite interesting. Alright. I want to talk about bitcoin today, of course, since it's the Summer of Bitcoin experience. Before we get into your project on bitcoin last year, maybe, I'm curious to know, when was sort of the first time you heard about bitcoin.
MAUGHAN: So, interestingly, the first time I heard about bitcoin was.. so I lived in Los Angeles before I moved to grad school in Vermont. And I attended this conference, which is kind of a controversial conference, but I was really into functional programming, in particular, this functional programming language called Haskell. And there's a conference called Lambda Conf, which was organized and I received a scholarship to attend in I think, 2016 or 2017 if I recall, and through that, I was able to attend, these workshops on lambda calculus and using Haskell and that sort of thing and in one particular year, every attendee received bitcoin. So as long as you attended, they gifted you with some bitcoin. So that was I think, around 2016.
And what was interesting is that on the way that they gave us bitcoin was from a company, I think called 21.co and that eventually became this recruitment platform where recruiters would contact you and you could specify a rate at which you'd want to be paid for them to contact you in bitcoin. So because I didn't know and I was pretty new to development at that point in time. I just kind of said like, maybe like a dollar’s worth of bitcoin or something. And I was able to make some money from recruiters contacting me in bitcoin so that was my first interaction with bitcoin.
SHANKARA: Well, that's quite interesting. And, so you happen to basically receive bitcoin in this setting for the first time. But what was your impression like, did you think about whether or not it meant anything?
MAUGHAN: Because I was anywhere in the California SoCal-NorCal area. It's very, like a kind of techie scene in general. I was really thrilled, and it wasn't a lot of bitcoin, but I was kind of fascinated by it. And I did have a couple of friends who actually were into bitcoin pretty early on.
One of my friends, interestingly, as more people found out about it, they were able to buy a house, which is interesting, but it's, I think it was more…so, the thing about the functional programming community is that because the language has various properties, those programming languages have things like types or certain constraints. They're the kind of we're a good fit during that time when I was curious about and learning about Haskell and this kind of language, which is the good fit for crypto companies. So more companies like, say, Cardano and that sort of thing were actually at the conference trying to recruit us, I think in the context of that was how, I that was kind of how I understood something about crypto. And well, because bitcoin was most well known, but kind of in the context of like, okay, the things, the languages, and I'm learning I could get a job at one of these companies. If I learned this programming language, even though that wasn't my primary concern.
SHANKARA: Interesting. So what convinced you to pay attention? And when was this?
You happen to come across bitcoin? It's obviously a thing that some of your friends are involved in and, obviously, you come to interact with it in some setting at the conference. But bitcoin has this larger appeal to a lot of people in terms of what it is trying to be. In this society we are in, you know, it's trying to be money and then it's also technology that is solving some really interesting unsolved problems in computer science, in distributed systems and so on. So, around those aspects, when was the time when you sort of finally started to dig in and perhaps read a little bit more about it?
MAUGHAN: So I think it was a mix of a couple things. So one thing of course, is my interest in cryptography. So I think I saw a talk. Oh, so I attended this summer camp at Cornell Tech, it was kind of a summer workshop hackathon. Where presenters talk about cryptocurrencies, I think it's called a cryptocurrency initiative.
And I attended that one, and I helped out on a project. And I think that was the first time because of the projects in particular, we actually it was a hackathon and we were in the top four. They didn't have a first place, but that group is in it. The group that I was in was in the top four. And that particular project I was in I thought it was interesting, because they were looking at, kind of evaluating in the same way that my initial research was focusing on explainability and, and see like algorithmic fairness.
What does fairness mean in a distributed system? So what does it mean in terms of evaluating the freshness in batch transactions or individual transactions? So when someone makes a transaction say a party A, do you process their transaction in a batch or process as an individual in terms of the place it first based on at a specific timestamp? And the other thing that I was interested in was that I took the class during COVID and so I was part of the IEEE information theory Santa Clara Meetup group for 2016. And they were offering during COVID a class online like an opportunity to audit this class with a Stanford professor, David C. David is like really well known for information theory, and he's very into cryptocurrency, and he loves bitcoin.
And so his whole class is about understanding, consensus protocols and scalability within protocols. And he talks about the kind of the triad of security, having the period of time for transactions and that sort of thing and how those things make bitcoin work. And we also went through a number of different protocols. So we went through Prism and, and all sorts of things and I believe at one point we had Chia we had Brett from Chia give a talk.
And that was, I mean, it was just an incredible class. And I think that that kind of ignited my interest in finding out more because I kind of realized I basically I moved beyond kind of understanding bitcoin as this thing that was kind of a mechanism for things like remittances and people using it as a currency and more so in terms of, oh, this is a consensus protocol and these are the things that make it work in a particular way and what will happen kind of asking what will happen as this thing scales what is the future, what is the longevity of bitcoin?
SHANKARA: Let's switch gears to the Summer of Bitcoin. How did the Summer of Bitcoin fall on your radar and what was that whole journey?
MAUGHAN: So again, I was looking for, you know, kind of the intersection of something cryptography related because I was interested in that but also bitcoin related because I was looking into scalability consensus mechanisms. And especially after the Cornell hackathon, and I had a really good experience with that and the software class with David C. And what I had realized too, was that I really missed open source. So I have in the past, I've taken part in Google Summer of Code, I did that in Haskell, and I’d taken part in Mozilla, had an opportunity to learn Rust, and I had just taken part in Microsoft Research with a program called reinforcement learning open-source fest, where you contribute to reinforcement learning, library and machine learning. So I had just done those in 2018 and 2021. And I was kind of itching to get back into, being a part of understanding the open source community again, and I don't know exactly how, but I guess I was just poking around and I saw it and I just thought, wow, this this is an amazing program and it just fits my needs so much. And I just joined the server and, and it's very intimidating because there are a lot of people on the server.
But eventually, I think, kind of finding the project that fits what you are interested in and also realizing that within the channels, you see some people over and over, made it a lot easier to kind of deal with, and a lot of these open-source programs have a lot of full volume and noise. And sometimes it's hard to figure out, should I even apply. You know, there are just like too many people, but I think if you have an interesting question, and you have an excitement to learn. It's definitely worth applying.
SHANKARA: That's beautifully put. So let's dive right into your Summer of Bitcoin project. You applied to work on research on Lightning Network with Rene Pickhardt. Do you want to maybe talk about why you chose that particular project, with Rene?
MAUGHAN: Yes, so I actually didn't initially think that project was not on my radar at all. I was again, I had been looking. So one of the things and I think it's important when you're choosing or looking at an open source contribution, or any of these programs is, is to kind of look at your strengths. So for the first open source program that I had done, I knew that I was pretty connected to the Haskell community. And that it’s just kind of a game right? You're kind of trying to, I'm not saying gaming the system but you want to maximize your odds. So I knew that people in that community, and I knew that not a lot of people would necessarily apply to Haskell because it's such a strange language or not strange, but it's not taught in a lot of schools. So I would have pretty good odds of getting in and the same way I was looking initially at the Merkle tree project, because I thought, well, my strengths are cryptography. And then I came to one of your sessions, actually, Adi, where I had asked the question, I said, is there something that exists that's like this and you had said which is, which I think is a great, a great plug for coming to your info sessions as a student, but you had responded and said, “Oh, no, this is an actual project. This is a thing.” And then I looked at the project and he looked at the channel and saw that it was a research project. And I thought, well, this is it. If there's one project that I want to do, and write a proposal for, I would definitely be interested in this one. And so once you had explained that this is the case, I had checked out the channel, I looked at the projects, I looked at the papers, I thought this, I'm not necessarily an expert in all the parts, but in any case, this will be an opportunity for me to learn.
SHANKARA: Sweet, so I want to maybe start off, before we sort of dive into the weeds of your project, if you could tell your audience at a high level, what is Lightning Network all about? And then you know, we could maybe drill into the specific areas that you worked on.
MAUGHAN: Okay, so Lightning Network on a high level - so I actually had to give a talk on this over in fall, last fall. But it is off chain. So when you think about blockchain as a network, there's these transactions that happen on chain and they take a certain amount of time to process and they’re really middle to large transactions, but maybe we want to be able to do small trips, smaller transactions that don't take as much time so we will do this off chain, not on chain. And so the Lightning Network enables micropayments, which are smaller payments to be processed quickly via these micro transactions off chain. So that's kind of the premise and the way I like to think about it is many, say immigrant cities in New York City, for example, have this kind of pop up shops. And when you buy things, they don't want to pay the transaction fee, the processing transaction fee. And in that case, maybe they're not making large amounts of money, they're not trying to funnel through large transactions. So Lightning Network might be a really great solution to these kinds of transaction fees and minimizing that.
So what it is, is a bi-directional payment system. So we think of a network as nodes and edges and you can if I have a node A, and another node B, A can send satoshis to B and B can send satoshis to A.
SHANKARA: When it comes to some of the scalability concerns around the Lightning Network, what are your thoughts, by itself, it awesomely scales bitcoin to many more transactions, but then there are sort of concerns or limitations or there could be problems later when it's running at scale, and managing channels and liquidity across those channels, is a problem. Could you maybe opine on that a bit?
MAUGHAN: Sure. So I think honestly, what, Rene, Sebastian and myself, what we're working on is important. I think that, for example, in my dissertation work, I spoke about the assertion-based cryptography - there was a huge attack last summer in August 2022. And so, parts of it are broken. In the same way I think about the fact that we are evaluating robustness and there are concerns about Lightning Network, but for anything that is long lasting, it is better to do these kinds of evaluations on a network to look at the potential scalability to look at their robustness.
The worst thing would be, I think, especially coming from a research background, to tell everybody with optimism, oh yeah, this is great, you know, everybody should just join and then there are issues down the road. And I think that you know, yes, you can say that, there are issues, but every technology has kind of gone through some kind of iteration from its initial scale to growing and it's part of, of growing a community in general - look at Twitter and Mastodon when all these people migrated from Twitter to Mastodon on all these different servers, and Mastodon initially had some issues with having timeouts with the number of people joining enmasse.
So I think within any kind of decentralized community or certainly a network, these things have to be evaluated. I don't think it's necessarily negative or like something that you'd say, oh, well, don’t use something. I think it's really important when you have these kinds of technologies to test them thoroughly. To make sure that they're robust to have to actually have lasting technology.
SHANKARA: For sure. So I think that's a perfect segway to the actual project that you did, which was about quantifying how robust Lightning Network is. Tell us how you went about solving it. What did you find and what were the results that maybe you would like to share with the audience?
MAUGHAN: Sure. So I want to say that a lot of this work was guided by Rene. I think Rene was a fantastic mentor. Rene, I think, had the initial intuition, which is why the project came about based on probability theory. So if we look at the probability based on a smaller iteration, which is in mathematics or computer science, what you do is you start with a small case, and then you induct upon it or, you look at iteratively a larger case. So what he was saying is that if you looked at the smaller case, and you scale it up, there's a high probability that the network would fail. And so our primary response was kind of looking at how we could model that. And so some of the issues that came up initially were that when we look at models for these kinds of networks, and these kinds of problems, we found a lot of analogies / comparisons to things like transportation systems.
If you're thinking of a road and you have - let's say you have a small road, and there is a certain flow of traffic in one lane traffic, and all of a sudden people realize that this road has less traffic than another road to get to the same place. Maybe people will decide to use this other road. But what if everybody decides to use this other road? That now that was meant for one lane traffic, and now it's jammed with like six lanes? How does that scale? And so we're looking at those, we're looking at some other things involving some like even the physics properties of Brownian motion. So all kinds of models and the thing that we kind of settled on, which I think was in research, the way Rene saw it was that yes, we could show this directly with probability theory and with a simulation, but let's look to see if there's something in the literature that has a similar mechanism. And it was really challenging because a lot of when you look at things like network but traffic network which I mean traffic, I mean, in terms of internet traffic and network routing, what they usually assume is that the traffic is going in a particular direction, or doesn't assume that in our case that the nodes can be bi-directional.
We also have this added complexity which I think Sebastian is working on called multi part payments, where in order for a payment to go through, it has to go through every single node in the network. So there are all these kinds of ways that we can have what we call flow through the system that is bi-directional. And so that was a very difficult and novel thing to kind of find in the industry. So the closest thing we found was this kind of game theoretic constraints called congestion games, which, interestingly, I've seen used for things like NASA telescopes, NASA satellites, sorry, which is interesting. But eventually, that was kind of the conclusion that we came to as well as starting with an initial, you know, A versus B. So A pays B and B pays A, and we model that as something called payoff, this payoff diagram, or a payoff table, which also comes from like game theory and probability theory, but this is over a graph. So this is an added complexity of okay, these things are connected. And what happens if we lose a connection? And so I had taken a random probabilistic graphs class. And one of the first things I thought about is this - it's like Percolation theory, and something called Galton Watson, where you have this equal probability of a node and an edge or an edge being connected to another node. So we have two nodes, there's a 50% chance that they're connected, which could represent this situation where you're sending a payment from one node to the other. However, that doesn't necessarily account for the bidirectional aspect, which is not just A being connected to B, but B could be connected to A and this is important because when you're thinking about flow in the particular case of the Lightning Network, it is bi-directional. So it's not it's not in typical network flow graphs where you just thinking of directed graphs, which assume one direction. And so those are the kinds of some of the things that we kind of had to dig deep into to find.
SHANKARA: Interesting. Could you talk about how you extended this example of the flow between these two nodes to perhaps the entire Lightning Network and maybe determining the robustness for the entire network, using probability distributions?
MAUGHAN: So the probability distributions started with Rene, I think I will give Rene credit for this. Absolutely. And what that started with is if we have that payoff matrix where we have a, node A and node B, in a network sending, so we don't want to think about the other parts of the network, just A paying B and B pay A, and they each have one Satoshi each. So at any given time, there's a 50% probability that A can pay B or B can pay A, if we graph that over time, then we should expect what we call a normal distribution, because we have an equal likelihood of either A paying B or B paying A. But what happens if we have one that has a higher probability than the other it starts to look like a skew graph? So the skewness, Renee typified it as a drain. And so this drain will increase over time as we had a higher probability of one individual paying or having a higher probability of paying the other more and if we look at that as typifying network where you can have selfish routing, where one particular node is more likely to have flow in its direction, and we send that that idea of this flow in this direction, in the context of that same original row that I was talking about. So we think about that flow and that node as, say, represents congestion on a road and everybody decides okay, let's jump to this road to travel.
We can think about that in terms of a payment system where at any given time to make a payment on a network, maybe the network chooses a particular path for nodes. And, that particular path gets used over and over. What if that's because it has a higher likelihood, and we increase the scale of that, will that mean that the network will fail? Or will there be failure on the network? And how, what does that mean to the robustness of the entire network? So that was kind of what we looked at, which again, is this kind of inductive case. So we start with a smaller case, which is two parties A and B, we scale it and then we kind of grow it to include what might happen for an entire network.
SHANKARA: Nice and so you know by modeling this sort of congestion in the Lightning Network, you can essentially figure out what's the best state for equilibrium, right, where we don't run into these liquidity issues in the Lightning Network. Could you tell us about that equilibrium state? What did we find around it?
MAUGHAN: So the equilibrium in particular was part of that finding of congestion games. And so originally we were thinking of, it was essentially like a Nash equilibrium.
And so we were trying to find something that might give us.. because what we're saying essentially is that for every game when you're modeling a game, in game theory, you need to have - it needs to terminate, and that termination is represented by some state of equilibrium. So we had to find the right game that would give us this particular termination. And so for that, I was looking at a lot of work on Brouwer's fixed-point theorem. So Brouwer's fixed-point theorem is based on Brownian motion in physics, where you have at some point, it's like a fixed point is - it gives, it returns itself. So this is kind of it doesn't, if you think of it as a convex optimization or auto differentiation, maybe that you want it to kind of reach a minima. And so in this case, our minima would be when that game terminates. And so we were looking for the right mechanism, which could explain when in our situation that game would terminate and that turned out to be that Nash equilibrium in that particular congestion that we found.
SHANKARA: In these sort of congestion games that you modeled on the Lightning Network, based on sort of the channels and liquidity among all of the nodes participating in the network, one of the parameters that affects the model, or the graph or the network is obviously the fees that you know, that nodes essentially earn or that is to be paid every time someone makes a payment through the lightning Network.
Tell us about the findings you had around how changing fees affects the network. And if that was the only parameter that makes a difference or the other parameters that you know, affects the congestion game as a whole.
MAUGHAN: Yes, so one of the things that actually pretty early on, Rene wrote a really great article via Bitmex, where it was shown, using that whole that example of the drain is insufficiency and I spoke about earlier, it was discovered that fees, which are usually the parameter of cost function, so that's actually a great point.
So, in a lot of the models that we're looking at originally, it was assumed that cost was what we wanted to optimize and so when you look at a lot of particularly economic models, like mechanism design, you're looking at things like you know, I want to, for example, if you have a number of stores and you want to maximize or certain routes and you want to maximize an optimal route, people usually converge on an answer, or they'd say, use convex optimization on cost, because it's usually assumed that cost is the thing that people want to maximize and in this case, when the different variables or features are plotted, fees were not the only things to optimize liquidity.
So it's interesting because that was another issue I think with kind of modeling the Lightning Network or thinking about the Lightning Network is that the literature that we found a lot of it that was initially kind of similar, focused a lot on optimization based on fees. So that meant that we couldn't necessarily use those direct models to think about Lightning Network.
So in this particular graph, we had looked at like optimization of fees, optimizing uncertainty, and feature engineering of the combined cost. So kind of a mixed mixed model where it's a mix of both features, and to see what that would mean in terms of the expected drain of selfish routing. And so that was also kind of shocking.
SHANKARA: So it sounds like Lightning Network is really unique, as far as the existing research literature is concerned in terms of modeling these networks, and figuring out what's the equilibrium state where we don't have as much congestion, as one would like to avoid.
MAUGHAN: It's also one of those in a lot of models, too, I think, because I can't say for sure that we are the only people who've done work on Lightning Network. There are certainly and we did find, you know, when I was looking I found other people, there’s some mailing list, if you're on the lightning dev mailing list set, Rene kind of suggested that we all join, and there were people who had written this stuff up on Lightning Network, but what Rene was saying is that it's really one of those systems that you need to understand as well, because you could be making false assumptions if you don't understand the way it works. So I want to say again, that just having Rene as a mentor, who really understands lightning, I learned a lot just just from, his saying, you know, my on a path and saying, like, “Oh, isn't this kind of like this?” And they say, “No, no, no, no, it's just not not a correct model. Because if it's not a correct model, then your assumptions about features and parameters and optimization are just wrong.”
SHANKARA: I guess, to wrap it up on your project, you know, how would you summarize the findings of your project for someone like a layman and or maybe even a developer who is now contributing to the Lightning Network? What should they think about when they are building for the Lightning Network?
MAUGHAN: That's an interesting question. I think that for someone who's building, I think, maybe spend some time learning about the Lightning Network, spend some time testing and simulate doing some simulations that Sebastian was incredible and did a lot of work on kind of getting to know the network and simulating, I think that's also part of why he did so well. Like he really knew the system inside out - I think that provides insights. And I think it's like a system. It's like every system you have to learn the ins and outs of it. And also, I think what's important is to get to know the community. A lot of the time people, I would say, are not just researchers, but people who want to build things. It doesn't help if you build things necessarily without understanding what the community needs. So being a part of the community is super helpful. I think that if I were to just have an independent researcher come along and tell me, “Hey, do you want to work on this project?” And they didn't really know about the Lightning Network. I think we would have it would have gone completely off the rails, but having someone who's so core to the community, like he was giving talks, and he has connections with Chaincode and SF Bitcoin Devs and all that sort of thing. To really understand what the community needs is, I think it's kind of the sweet spot of working in a particular bitcoin research, Lightning Network and that sort of thing. So that's the advice I would give you - kind of immerse yourself as much as you can in the community and get to know the problems, the real problems that people are engaged with before just kind of assuming and jumping into a project.
SHANKARA: Awesome. Alright. So I guess, one last question that I probably have about takeaways from your project is, I mean, you spent a couple of months working on bitcoin. You had a fair idea about bitcoin before you even got started with Summer of Bitcoin, but then you were sort of in the weeds, you know, talking not just to Rene, but perhaps reading a lot about how people use Lightning Network and sort of trying to model their behavior trying to understand the robustness of the system. Was there anything that changed, was there anything that was different in your understanding of bitcoin after the summer, than when you first heard about it, when you first started with your project?
MAUGHAN: Definitely, I think one of the things that really kind of affected me, that Rene speaks about, is I thought of it coming in as kind of a distributed system as a network. And I think afterwards, I realized how much things like economic behavior are important in thinking about those systems. And I also, after the summer, I ended up taking a couple graph theory classes and I'm working with a professor and a graph theory project as well. It made me kind of open my eyes to maybe some of the ways that we could be thinking about crypto systems. So there's, I mean, there's a lot more focus now because there's so there's a community called the Economics and Computation Conference, which I've kind of been in at the beginning of of my PhD kind of lingering about but they've only now kind of started to include economics and computation cryptocurrency track in recent years. So at the beginning of my PhD, there was not one. And in particular, Tim Roughgarden, who works on these kinds of problems, had given a keynote over the same summer that I did Summer of Bitcoin. So that kind of intersection of thinking about theoretical computer science questions and behavior in systems is, I think there's a lot of room for that kind of work. There's also a lot of room for understanding cryptosystems itself and, you know, the system and concurrency and that sort of thing. So I think that, after summer, I kind of realized that there's so much room for all kinds of work, and it really changed at the beginning of summer, I thought, okay, well, this is gonna be open source, coding kind of projects. So but I think having Rene opened my eyes to the fact that no, there are all these interesting questions in the community. And we do need different kinds of people with different backgrounds to work on them. That was something that I learned over the summer and through the program. I think that a lot of students who think that they don't necessarily have X background, you'd be surprised by what you might be able to bring to a project, regardless of your background.
SHANKARA: So by now, you've had quite a few experiences with open source, right? You previously participated in the Haskell community and now with bitcoin and Lightning Network, what advice would you give for anyone who is looking to contribute to open source, based on your experience so far?
MAUGHAN: So in contributing to open source, I think it can be intimidating. I mean, in my case, I can see why someone might be hesitant or think that maybe they don't have enough experience. But I think that what helps you overcome that fear is again, learning and being involved in the community like I would have never applied for Summer of Code for Haskell, or any of those things if I hadn't met someone, or a mentor who kind of encouraged me to apply in the same way that if maybe if I hadn't gone to that conference and gotten bitcoin, out of serendipity, and might have never gone down that path, or if I hadn't taken the class with David, and done especially the Cornell Tech hackathon, because the people were just like, that group was just so nice. And even though it was pretty new, they were just, they just said, oh, no, you can, you can work with, we can work together or we can you know, we can solve this and then we ended up getting into the top four groups and presenting our work and that sort of thing. I think that can help overcome any kind of intimidation or hesitation.
And I think that open source in general is a great way to kind of give back and be part of the community. I think that's kind of a big takeaway that that I had, was that you feel like being part of open source, you feel more connected to, to the technology and to the community just because like it is kind of a very personal thing like when you when you contribute to a project when you spend time on it.
And when you especially know people from the community, like, you know, all of a sudden it's like, oh, Rene's giving a talk at SF Bitcoin Devs. And I was like, oh, I know Rene! So I think that's, that's kind of a lovely way to also stay engaged and to last is to be part of a community because a lot of like, Summer of Code people or, or those kinds of people, sometimes they drop out, you know, life happens but the more important thing is like, long term you kind of are part of this community that you feel connected to by taking part in is in open source.
SHANKARA: Alright, Krystal, this was a fantastic conversation. Before we wrap it up, where can people find you and follow your work?
MAUGHAN: They can find me on LinkedIn. You can search for me, blog, you can email me. I'm usually pretty busy. So I'm going to be going off to a mathematics conference in about a week from now on, specifically, elliptic curves stuff, cryptography stuff, but I'm also on discord. So recently, some people have been asking me about my proposal, which I didn't really talk about in this interview, but I think I would also be happy to share my proposal if anybody's interested.
Good advice for proposals - Be specific. Know the projects. Have milestones. I learnt that in Summer of Code. So have your specific milestones of what you want to accomplish - specific goals, timelines, your background, make sure that you as much as you can like the best suited in terms of contributing and show passion and good luck for those applying this year.
SHANKARA: Alright, Krystal. Thank you so much for joining us today.
MAUGHAN: Alright. Have a good day. Thanks, Adi.
JOBS IN BITCOIN
If you are a fresher straight out of college, here are a few exciting job postings we recommend:
Engineering:
Bitcoin Wizard | Spiral | Remote | Apply
Software DataOps Engineer | US Bitcoin Corp | Remote | Apply
(Senior) Backend / Full-Stack Engineer (NodeJS) | 21bitcoin | Salzburg, Austria (Remote) | Apply
Lead Mobile Engineer | Swan Bitcoin | Remote | Apply
Mobile App Developer | Synonym | Remote | Apply
NodeJS Engineer | Synonym | Remote | Apply
Back end / Full stack Engineer | Amber App | Remote | Apply
Full Stack Dev | Atomic | Austin, TX, USA (Remote) | Apply