📂BeyondBitcoin Archives with Dan Larimer and Fuzzy | Stephen Reed CPOS | Recorded on May 24, 2014

Welcome to the BeyondBitcoin Archives

Over the coming weeks and months you will be introduced to the history of the BeyondBitcoin Community and the historical influence it had with the development and evolution of the Delegated Proof of Stake (DPOS) blockchain technology pioneered by Dan Larimer starting with Bitshares and STEEM.

You will be able to listen to the initial conversations between @OfficialFuzzy and @Dan (Bytemaster) and learn how the development process progressed over time guided by the weekly feedback from the BeyondBitcoin community members... many of who went on to become important contributors and leaders in the Bitshares and STEEM ecosystems.

I will be tapping into this treasure trove of knowledge and providing edited recordings and full transcripts for the most important and influential hangouts from the BeyondBitcoin Archives.

🔊Episode #6 : Recorded on May 24, 2014

In this episode, Stephen Reed's discusses his concept of updating the Bitcoin Core code from Proof of Work to Cooperative Proof of Stake (CPOS). At the time, CPOS was a fresh solution to the problems Bitcoin faces which maintains what remains of Satoshi's social contract while dramatically improving the efficiency of the ecosystem. Fuzzy, Bytemaster, and members of the early Bitshares community join the discussion to extract the differences and similarities between CPOS and DPOS.

📝Hangout Transcript

Click play on the video above and follow along with the transcript below.

Full Transcript Link:
https://cdn.discordapp.com/attachments/340842443664785408/449324160183828481/E6-2014-05-24-Transcript.txt

Host Introduction
Today is May the 24th 2014 and welcome to the beyond Bitcoin developer voice hangout we start out this session with an update on Bitshares with Dana Larimer. Then we watch Stephen Reed as our guest. Stephen will go over his blueprint on how to turn Bitcoin into a proof of state currents.

Fuzzy
Anybody of course can ask questions during this time.

Dan
All right. Well, I'll give you a high-level overview of what we've done in the past week, which has been a lot.

The Delegated Proof of Stake [DPOS] system has been significantly enhanced. We've introduced a random number generating scheme into the blockchain. We are then using that random number scheme to shuffle the set of delegates once per round where a around is where - every delegate produces one block. The result is that we have resolved several potential attacks based on the prior implementation. We identified that someone with a small percentage of the shares could tweak their ranking in the order and make sure that they always got to produce the next block. So we had to resolve, and that's what we accomplished this week on that front.

On other fronts we have implemented a proposal system where users of the DAC, sorry where delegates can submit proposals for consideration by the other delegates and have them voted on. And the primary reason for this was actually as a way of replacing the developer broadcast alert notification system in Bitcoin where if there's a security vulnerability you can post an alert. Recognizing that we didn't want to have it centralized with one developer, we decided we'd allow any delegate to submit these alerts, and recognizing that one bad delegate could spam people we thought there would be worthwhile for delegates to confirm the alert. So, the process works as a kind like a board of directors. Here's a proposal and everyone else seconds and thirds in after all the delegates approve it it's ratified and then that also helps us to handle forks. So, the way I would envision things working is - some delegate will propose a change, we want to change some fee structure add a new feature, if that all the delegates approve of that change then the developers can go and implement the change. After the developers have implemented the change they can trigger the change to take effect once all of the delegates have ratified a second proposal for activating the change on particular date and time. The use your community, the shareholders, have an opportunity then to vote against any delegate who doesn't vote the way they like. So, it gives us a natural planned way for the DAC to upgrade and manage hard forks, which is something we wanted to have figured out before we could launch a DAC. Otherwise, we have a big debate outside the system without any process in place for handling hard forks in the future.

Fuzzy
So when you're talking about the random number generator in the very beginning of it. Does this random number generation invite any security risks of its own?

Dan
Well it's a source of randomness that states that as long as at least one delegate is honest no delegate can predict the number that will be produced the next round, the numbers that we produce the next round.

Fuzzy
Wow Okay, so it's kind of distributing that as well.

Dan
The way the system works is, every delegate picks a secret and then they commit to their secret by including the hash, of whatever their secret was, into a block they produce. When they produce their next block they have to reveal their previous secret and if they don't reveal their previous secret they can't produce the block. So, this results in every time a block is produced a new secret is going to be revealed and they can't change what their secret is after the fact is they committed to it in advance, and all the secrets are then hashed a one-way function together with each other. So, that the only way to know what the numbers are going to be in the future is to know all the secrets of all the other delegates.

Now in theory, if all the delegates colluded they could know all the secrets going into the future and it's not really random in that sense. But, it is a fair way of distributing the trust and as long there is at least one delegate that you trust you can use the system and if I'm a file in one percent I'm going to let myself delegate and produce a secret number and then I can know for sure the system is fair for me.

Fuzzy
So out of curiousity, this kind of goes along with another session that we had. So for those who aren't here, or who haven't been paying attention to all of them necessarily, you were talking last time about snapshots being made in the case of something, you know something happening that would otherwise hurt the network. You can actually have these snapshots in place as well. How would that fit as far as the resiliency and security of the network?

Dan
Well the snapshot is sort of the worst case scenario. Someone hacks the network, execute some transaction that grants them all the coins. At that point we can freeze the network, at whatever point right before the attack occurred, fix the bug relaunch the network from that point forward.

Fuzzy
Both of these have, sorry for interrupting, both of these have major consequences for the Bitshares Lotto DAC?

Dan
Yes, so the Lotto DAC requires the source of randomness that can't be cheated.

Fuzzy
And it also gains the benefit of the current implementations for security last week. Is that fair to say?

Dan
Yes, Yes. So the challenge with eliminating proof of work is that eliminates a major source of randomness. They are, it's very difficult for minors to actually choose which block they submit because it's already difficult for them to find the block in the first place.

So that makes proof-of-work a natural source of randomness. But, if you eliminate that you need a new source of randomness that is more efficient for the purposes of betting and gaming and the goal here is really to make things provably fair. We've got a system in place that will work well for people that want to buy a lottery ticket. You have to buy the lottery ticket at least one round before the random number is generated, so that you can't, none of the delegates have the opportunity to buy a ticket after they know they're going to win. The system is fair.

Now in theory the delegates could collude, but that would imply that all the delegates are working to undermine the entire system and that they were selected because the community trusted them in the first place and they're also extremely varied in different continents, countries and so on so forth.

Fuzzy
So you're saying would be pretty easy to do?

Dan
It'd be pretty hard to collude.

It's sort of the ripple approach. What you're really trusting is that the Road Runner and Wile E Coyote are not going to collude against you.

Fuzzy
Sounds good.

Well we're about at the eighth minute, eight minute and thirty second mark. Does anybody have any questions from the community?

We have quite a few extra people in here today because Stephen Reed, who is working on Cooperative Proof of Stake [CPOS] whitepaper, from the BitsharesTalk forum is here to participate in the discussion as one of the community members and a highlighted individual for his own work.

Dan
Welcome Stephen, I look forward to talking with you.

Stephen
It's a pleasure and a great thing to be part of this forum, thank you.

Fuzzy
You're very welcome. I will invite you to come over and school everybody any time you want to do let us know where, where we need to learn man.

...

Full Transcript Link
There is a 65K limit to post size, so the entire transcript will not fit into a single post, so I have provided a link to the TXT file with the full transcript which includes Stephen's interview.
https://cdn.discordapp.com/attachments/340842443664785408/449324160183828481/E6-2014-05-24-Transcript.txt

⭐ My favorite Bytemaster quote from this episode:

At some point you have to have human-value judgment. You can't have a software algorithm determine which version of the software to go to, software internally will have to take inputs from users.

Let me know what you think, please leave your comments below.

As always, please upvote this post and follow me
if you like my work and want to see more.