Participants: JZ – Host – https://twitter.com/jz_bz Jake Yocom-Piatt (jy-p) – Organizer of Decred, CEO of Company 0 – https://twitter.com/behindtext

JZ

And we are live! Hey everybody, I’m JZ sitting in for Tyler today and this is Decred assembly. We’ve got a great guest: Jake Yocom-Piatt (jy-p), Decred project organizer, head honcho at Company 0 and we’re going to be talking about all sorts of stuff today: proposal system, the call for contractors, and a bunch of questions from some of our Redditors. Jake, welcome! [00:00:31]

jy-p

It’s a pleasure to meet up with you Jonathan. I think this is the first one of these you’ve done and it seems like you’re delivering right on point. It’s always a pleasure to be back, even with different hosts. [00:00:47]

JZ

Matt’s been grooming me, I guest-hosted on one of them. Hopefully this won’t be a regular thing because he’s on hiatus, but I’m trying to walk a fine line here between doing a good job and making him proud and bombing hard enough so that he comes back. [00:01:05]

jy-p

Yeah I know, I’ve run in that same situation myself in the past with certain people. Once you set the safety net too high for some people they just don’t want to fix it. [00:01:15]

JZ

Okay so let’s get started, I want to start off with some Dered news before we get into some of the bigger topics. Recently Decred has been added to Uquid debit card, so we’re on two debit cards now: Uquid and Wirex. We recently launched the Decred website in like ten languages, so that was pretty cool, and we’ve got about another ten going. So anyone out there who’s got language skills and wants to come help us translate the website, the documentation: we’re looking for people. Let’s dive into some of this stuff now. First I want to pick your brain on something though, because everyone’s talking about the Bitcoin Cash stuff. [00:02:01]

jy-p

*laughing* Okay. [00:02:04]

JZ

It dovetails nicely with Decred, because this type of stuff is not supposed to happen, right. Everyone seems to be really excited about it though, like “hey they’re sending of new bitcoins, I’m getting free money!”, when this is actually kind of a disaster. So I wanted to pick your brain on that. Any general thoughts? I mean going from having one type of Bitcoin to two, to maybe three in November. It’s not exactly confidence-inspiring, honestly. The market seems to like it but what are your thoughts? [00:02:35]

jy-p

My thought is that Bitcoin or the Bitcoin domain really has so much branding and a sufficiently large network of its own, even when there are these spin-offs that are basically occurring. It’s like the number of people who watch Cop Drama X, you wonder: does do the number of people who watch Cop Drama X go up when there’s the Special Victims Unit in Miami and the Special Victims Unit in San Francisco. And it’s a hard question to answer because in some cases it’s just going to basically fracture the community and be a really destructive thing, but for Bitcoin maybe it could be a good thing. My sense of it is that Bitcoin Cash and the coming SegWit2x fork and all of this demonstrates is that it’s very easy for conflicts to arise in the context of consensus changes. [00:03:33]

JZ

Yes. [00:03:34]

jy-p

So like we’ve seen in Decred, right, the engineering we put in was basically to make sure what is happening to Bitcoin right now does not happen to Decred. If somebody really wanted to they could fork Decred of and change all the consensus rules and so on, but by doing that you basically kill the network effect in a way that with a proof of work currency you don’t. [00:03:57]

So I see the [Bitcoin] community kind of breaking up but because of Bitcoin’s network effects this leads to a whole bunch of extra attention in the media which then brings in new investors at the same time the community is splintering. In terms of a value proposition I think that if everyone keeps paying attention to the drama it could be a good thing, in the sense that it draws more people in, but it’s bad in the sense that it’s inevitable that consensus rules are going to change over time. People are going to find optimizations, they’re gonna find improvements, and then they’re going to want to get them implemented. If you don’t have a reasonable way for people to reach a consensus on what the consensus rules should be, then you might end up with a system that has no value in it at the end of the day. [00:04:42]

It’s sort of like they’re treading water right now, but the long story arc here is is that this is bad. Because this could keep happening, and if it keeps happening then the whole thing could break up. [00:04:58]

JZ

They’re basically diluting Bitcoin’s brand essentially, once you have three, four types of Bitcoin. I mean that first mover advantage and brand recognition is one of the greatest assets. And while people are happily dancing while Rome is burning, because hey they wanted to dance and traders wanna trade and speculators wanna speculate, eventually the music’s gonna stop and you know everything’s on fire. [00:05:22]

But yeah, maybe we should talk a little bit about Decred and how the the ticket system specifically prevents stuff like this from happening. Because I just noticed that we hit a new milestone. We’re at about 41% of coins locked in PoS (proof-of-stake) which Dave Collins has been talking about for a while. He expects it to keep inching up there towards probably around 50 or maybe even more. I think it’s a great vote of confidence for the network and it’s securing the network as well. A lot of people don’t know this, so can you talk a little bit about the proof-of-stake system and how this specifically prevents the kind of stuff we’re seeing now in Bitcoin with Bitcoin Cash and SegWit2x? [00:06:01]

jy-p

Sure, so the way we engineered the hybrid proof-of-work / proof-of-stake was such that the cost of… *changes thought* so let’s say there’s a hard fork change and it’s proposed, let’s say it was something like add or don’t add SegWit. In the case that this happens Decred has a system where basically you need 75% or more of the votes during a voting period to be YES in order to confirm a change. [00:06:32]

So let’s say we were in Bitcoin shoes and we didn’t have SegWit and we were talking about adding the SegWit soft fork. Instead of making a soft fork where the proof-of-work miners amongst themselves settle it or don’t settle it as the case may be, what we do is is that everyone votes and if enough of the votes that are tallied are YES in a voting period, which is roughly four weeks, then the rule will activate another four weeks after the vote ends. And what this does is, this combined with a couple other consensus rules that we have in Decred make it so that it is prohibitively expensive from a proof-of-work mining perspective to continue a minority chain. [00:07:12]

Let’s say that we had a similar thing as to what’s going on with Bitcoin. Let’s say eighty percent of the people voted YES for SegWit and twenty percent voted NO. What can happen, right, is these twenty percent who voted NO could be very upset and go “ARGH, I want it the other way, I wish everything was the way it used to be” and so on. And those people can be upset, but the upshot is: if they want to fork of of the Decred chain they would basically, if they’re only trying to change that consensus rule, they are in a very messy situation. Because what ends up happening is that to validate new blocks not only do you need the proof-of-work to actually mine the block, which you know could be a problem depending on how the proof-of-work stuff splits across one of these votes, but you also need the tickets to make these votes. So what can happen is that chain one continues this way and then the other chain starts to go and what will happen is that you need at least three votes on a block in order for it to be considered valid, so three out of five. [00:08:18]

JZ

It’s basically two-factor authentication for your blockchain. [00:08:21]

jy-p

Exactly, and so without that second factor of authentication the cost of mining fresh blocks that have a second authentication factor stamp on them becomes prohibitively expensive. So in the case where we have this seventy five percent threshold, the reason we chose that is because it creates a roughly 10x multiplier on the cost of maintaining a minority chain. So basically rather than try to rule out minority chains entirely, what we’ve done is we’ve taken the Bitcoin approach. We said we’re gonna try to make it prohibitively expensive to do something that we don’t think should be done. [00:08:55]

JZ

And these are people with skin in the game, I mean ticket holders or people who have put out money and locked it up specifically to participate in your governance model. So you know you’re not gonna have someone just trying to rock the boat for kicks or making noise just to see what happens. You know there’s significant money invested in making sure that this works. [00:09:16]

jy-p

Exactly. And the problem that you encounter with Bitcoin or proof-of-work currencies is that a proof-of-work miner may have an enormous capital investment or capital expenditure to get their computer or their specialized mining hardware up, so they may be dumping hundreds of millions of dollars into their mining operations but those people are by no means obligated to hold any bitcoins. [00:09:38]

JZ

A lot of them highly just care about short-term ROI (return on investment), right. There’s one ROI with hardware as fast as possible and to hell with the long-term. [00:09:46]

jy-p

Exactly, and as anyone who’s been in the computer industry – especially in the hardware game – realizes, it’s extremely capital intensive. So you don’t even really have the luxury of kicking back and going like “Oh, I’m gonna relish in my profits”. It’s like “well you gotta reinvest now you gotta buy the faster ASIC to compete with the other guy who’s building that ASIC that’s faster than yours” and so it becomes an arms race. And I think that if you’re engaged in that arms race and you don’t hold any coins, I don’t think you really should have that huge of say in what the future of the currency really is. [00:10:19]

JZ

Now there’s a lot of that, people with no skin in the game or a very short term view and they’re on reddit, they’re on social media being the loudest and you think “Hey you guys have a huge following, listen to all the noise they’re making”. But in reality there’s really no way of gauging how much they are actually invested into their ideas because there’s no mechanism for that in Bitcoin, right? [00:10:43]

jy-p

Exactly and it’s the same problem with the user activated soft fork. Which is that people were like “Oh, we’ll count the number of full nodes that people are signaling for the user activated soft fork”. And it’s like: you can simple attack that all day. That was the whole point of making Bitcoin require one CPU one vote. [00:11:02]

JZ

I remember there were scripts for that, that you could spin up like a thousand AWS nodes and “Oh look, look at that now we’re all for XT or Classic or Core”. [00:11:12]

jy-p

It’s arbitrary. I mean who knew bossing people in on the internet would be so much more efficient. [00:11:17]

JZ

Yeah, sad but true. But you guys at Company 0 are originally Bitcoin devs, right. You guys created the Golang implementation of Bitcoin, Btcsuite, so you guys have a lot of experience with how that works and essentially some of the pitfalls that come from that. I mean I follow Btcsuite for a long time and I always figured “Hey, eventually maybe we’ll move away from the reference implementation and start with a solid base and add things like privacy to Bitcoin, some kind of governance” but no it hasn’t been the case. Bitcoin essentially has stagnated for half a decade, right? [00:11:58]

jy-p

Yeah, and I think that if you look at other ecosystems like Ethereum, even though I have my own misgivings about Ethereum, I feel like their ecosystem is much healthier in the sense that you know there’s at least a couple implementations of the core network. So that it’s not just a question of “Well, we have a monoculture and the mono people who run the monoculture say A, B or C should happen”, you know there’s a diversity of opinions and then you know at least to some extent people can meet in the middle, as opposed to one person just saying this is how it is and it’ll be this way forever. [00:12:33]

JZ

I know that’s something you and the devs have talked about a lot: having other implementations. That kind of dovetails into our next topic, the proposal system and the call for contractors. A lot of people don’t know, and especially when you talk to them for the first time, even if they’re a little familiar with cryptocurrency, Decred has something pretty special: the dev subsidy. Some people have misgivings for it because they don’t understand it, they think it’s kind of like a genius tax as with some other coins whereby you know that dev subsidy is going to your bank account every month. We actually have a fund that will eventually be controlled by a DAO (decentralized autonomous organisation), that the coin holders will decide what to fund, correct? [00:13:18]

jy-p

That is right, and in the interim we have Decred Holdings Group LLC. It’s a centralized conventional corporate entity acting as the steward for these funds until the DAO is ready. When we launched we were like “It’ll be great if we could make this thing all headless and amazing from zero” but anyone who spent any time really working on this stuff [knows] it’s complex and it’s non-trivial to make a headless organization, as even the people who invented Bitcoin can see. [00:13:53]

JZ

Well, and it’s a lot of money, right? I think there’s something like three hundred and fifty nine thousand Decred, which are about twenty six and half dollars now. It’s like nine half, let’s say ten million bucks, so you don’t want to make mistakes with something like that. I think we learned that from The DAO, right? [00:14:06]

jy-p

Yes exactly. The stakes are high here and you know we don’t treat this like a casino, we treat this like basically mission critical hardware. It has to be built right. If it’s poorly built or hastily built: sure we might be able to pump quicker, hype quicker. But the reality is that just like we saw with The DAO, an exploit in any of this infrastructure can have serious consequences. People having to hard fork changes out or rewrite the past, or whatever you want to call it. It’s very important to do it correctly and the proposal system is a key part of that. It will allow people to, in an as censorship proof a way as possible, make their ideas known to the community in a formal way [so] that we can’t go backwards in a race. Let’s say somebody proposes an idea we don’t like, we can’t go back in time and then just wipe it out and they’ll like “What?!”. [00:15:11]

JZ

Okay let’s talk a bit about that because I think that’s a really interesting feature. Now, the proposal system, I know the back end is close to complete, correct? [00:15:21]

jy-p

That is right. Actually as of today, I would say today or in the next couple days the back end will be complete and what’s going on right now is we’re finishing up some test coverage. Marco is writing negative test coverage to make sure that when you tickle it or you break the system it actually does break, as opposed to you break it and then it’s like “no everything is hunky-dory”, so that’s where it’s at in terms of progress wise. The system is almost ready to be shared. [00:15:56]

JZ

Okay, so let’s walk through a theoretical example. I’m a dev, I have some coding skills as opposed to being some guy who can’t code his way out of a wet paper bag, and I want to write a Rust implementation of Decred. Okay, now let’s say I’m a small holder, I don’t have a ton of coins, I make a proposal. What does the process look like and how does it get to an on-chain vote finally? [00:16:21]

jy-p

Okay let’s see how succinctly I can describe this. I don’t have any talking points here, so this is a little ad lib. Okay so the way this process will work is as follows: anyone who’s a member of the community who has an idea that they think is good, whether it’s dev related or not, can submit through the system. What we’re going to do is we’re going to have a small denial of service meter that we’re going to integrate into this. *JZ responds* Exactly, so we’re going to have a fee that’s attached to proposal submissions. This way you can’t just have somebody drive up and cram the suggestion box full. [00:16:57]

JZ

Is it refundable if it gets accepted? [00:16:59]

jy-p

That is in the cards. If you have a good proposal you attach a fee to it to sort of get past the bouncer and to make sure that you’re not just cramming the box full of junk. Then, if we like the proposal, and by we I mean the stakeholders, we will end up refunding this. So basically we don’t need these funds, these funds are just for essentially denial of service prevention and spam prevention. [00:17:28]

So let’s say you have your great idea, you write it down. We would restrict it so that only simple proposals can be submitted. You can submit things like markdown files and and PNG image files. Then you submit those into the system, it’ll say “make a payment here to make sure that you’re not spamming us”, you make your payment, then your proposal would have to be reviewed. Now the reason that your proposal has to be reviewed is… Oh, I’m sorry I forgot one other step. Before the review commences there is a token given to the user who submitted. [00:18:06]

JZ

The censorship token. [00:18:07]

jy-p

Exactly and so what the idea what this token is, is that on a lot of subreddits, especially say the Bitcoin subreddit and /r/BTC on the other side of the coin, we see an enormous amount of censorship. There’s certain things you’re not allowed to type in there. People will get a shadow banned and I just think it’s overall a very bad thing. And what I find so insidious about censorship is that censorship is one thing when it’s transparent, right, to be like “I’m censoring you because you’re saying something super racist, or super offensive, or it makes religious people upset”. There’s some motivation and people can see why you did it. It’s like “Okay yeah I see why you did that”. But the way it happens online is censorship is silent. “Oh, I don’t like that post: delete or hide or shadow ban”. We don’t want to go that route where we have this sort of silent censorship. What we’re gonna do is we’re gonna give a token to everybody who submits a proposal. And let’s say you submit a proposal, it’s full of just a bunch of super racist nonsense, just to give you a hyperbolic example of something that we probably don’t want to have publicly as part of a proposal system. So we received this proposal, we give you a censorship token. Then the proposal gets reviewed and what we’re going to have to do is, as a community, we’re going to have to build a set of rules of what goes into a reasonable proposal. If it’s super religiously charged, super racially charged, there’s these other buckets you know sort of if it’s just meant to troll people. There’s a lot of these buckets where it’s just not gonna be a constructive part of the proposal system. However, even in those cases I think it’s important to give the people who submit it a token so that they can demonstrate that we censor their proposals. So that’s sort of the first step, right, you submit your proposal, you get your token. If we censor, you can hold up your token to go aha these guys censored. [00:20:02]

JZ

It’s a badge of honour, I expect there to be a liquid aftermarket for these tokens. [00:20:07]

jy-p

Oh you mean the rare pepe censorship token? [00:20:09]

JZ

Yeah. [00:20:10]

jy-p

*Laughing* Okay, so then it gets it gets submitted and what we’re going to have to do is we’re going to have to develop a system for doing sort of a first pass review of these proposals. And by first pass I mean just the basics: is it full of nonsense, does it have a request for funds, what kind of request for funds does it have, does it explain what the funds are being used for, sort of just the basics. To the point where it’s not even a question of rendering a judgement on it, it’s a question of is this a well-formed proposal. So that’s the first step and we’ll develop a set of rules over the next several months for these things. Then after that, assuming it passes muster, then it shows up in the public proposal system. [00:20:53]

The public proposal system would basically be a git repository that’s made public. And I’ll add the details, the extra bits that we’ve added to it, later on just because I’m focusing on the workflow right now. So you know you passed the first approval, then what would happen is that, it would look roughly speaking from a user experience standpoint like a pull request or PR. That is, you’ve submitted your proposal and said “Hey guys, here’s my proposal”, then everyone who’s on the proposal system site or page can then comment on it to be like “I think this, I think that, what about this” and then basically give you feedback. And then at the same time what would happen is that this proposal would get active review by someone who works in the domain that the proposal is relevant to. [00:21:42]

For example you were talking about a Rust implementation. The sort of thing that would have to happen is that before we would agree to fund the work being done to make the Rust implementation, the people who work in our development group would need to look at your proposal from a technical standpoint. To go “Are they being reasonable about the lead times here? What about how much work is this going to take? How many devs are you gonna have?” and all of these sort of more technical domain specific questions that come up. And I mean the same thing might happen in the context of marketing. Like someone says “Ah we should run this paid campaign to do A, B, or C”, well you know the developer group isn’t really in a very good position to judge whether or not that is a great idea or not, but the people in the marketing group, specifically in the advertising group, would be in a good position to judge that and get feedback. [00:22:32]

JZ

So there’s a sort panel of experts, right, and I assume we might even pull some from outside the community, people who are in the industry and could these things. A scientific journal might have a panel pulled from all sorts of places. [00:22:48]

jy-p

Exactly it’s sort of like a standards committee but more from a sort of a practical nuts and bolts standpoint. Rather than it being very ethereal and “No I don’t like your proposal”. It would be like: who’s gonna do this, how much money is it gonna cost, is that reasonable, are we already doing something just like this, and so on. We’d welcome outside members to these panels. [00:23:16]

But there’s those two steps of the reviews. So basically assuming that eventually there’s feedback going on and then you get passed your first review. Then your technical review comes back and they’re like “Oh you need to change some things or you need to fill in some blanks”, there’s some spots in your proposal that are missing. So you update your proposal. Then after the technical review is done and then the proposal has been revised, at a certain point then it would be ready to be voted on. [00:23:45]

Now, in terms of how these votes would happen is: we’re going to implement a thing called snap voting. If you take a snapshot of the ticket pool, as of the block that this vote starts, and then you freeze that that copy of the ticket pool for one week. Or it could be longer, it depends. I think one week is a rough number, it gives people seven days to vote on proposals. And then what would happen is that you vote up and down. Maybe not everybody is going to vote, in I would be surprised if everyone votes, but let’s say 80% of the people vote, so 80% of the stakeholders vote on this snap vote. Then all of those votes would be recorded in the proposal system. [00:24:29]

So that basically we have the original submission, the comments, the technical review, the comments from the technical review, the updates to the proposal. Then we would have an actual off-chain vote on the proposal, So the way this would work is that the proposal system will only accept votes that fit into this snapshot vote. Then assuming all that passes then what we would do is that, now this is the part that that we really haven’t gotten to yet, ultimately a positive vote would have an effect on on-chain funds. So basically at the end of all this voting process, like a lot of it occurs off-chain, then there’s a final on-chain transaction to release the funds from the development organization. [00:25:17]

JZ

And this could be done in portions, I assume. For a big project that might take six months. [00:25:22]

jy-p

Exactly, so basically the details of how the funds are released is going to dictate what we can and can’t do. Just like you pointed out. Let’s say we budget a million dollars for project X, and then month by month people keep billing, they build 50,000 60,000 70,000 50,000, they keep billing variable amounts of money over, let’s say, a year period to get a project done. They might end under budget or they might go over budget. So basically the process for unlocking these funds is going to have to be flexible enough to accommodate these potential budget under- and overruns. It’s one of these things where we don’t have the process worked out yet, for the on-chain release of funds, but that’s really where the whole thing is going. [00:26:08]

So from soup to nuts that’s really how it works. And then in the special case that we’re talking about a consensus change proposal, what would happen is that it would be voted on via a snap vote. Or we might not even have a snap vote for something that’s as big as a consensus change. But then once it sort of passes muster and gets up to a certain point, then it becomes an on-chain vote. So it gets essentially promoted to an on-chain vote. And we’re gonna be selective about what we do on-chain votes with because it’s a lot of data to record on-chain. So not every change is gonna go to an on-chain vote. Typically it’ll be restricted to consensus changes. But everything else would go through this off-chain system and then there’d be an on chain release of funds component to it. That’s the big picture of the proposal system and how it would work. [00:26:57]

JZ

I think it’s very interesting and the whole idea of not having to actually have the overhead of the on-chain vote, while still being tethered to it, is pretty cool. And I know that ties in with the work you guys have done on dcrtime, Marco was talking a bit about that last time. [00:27:11]