Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Emin Gün Sirer & Ittay Eyal: From Selfish Miners to The Miner’s Dilemma

Episode Date: April 27, 2015

Bitcoin’s approach to solving the double spending problem is to make a collusion and attack on the network prohibitively expensive. One of the main factors that will determine Bitcoin’s chance of survival in the long-term is whether the behavior that maximizes the profits of miners contributes to or sabotages the health of the network. The game theory that determines this is complex and our understanding of it still incomplete. But research is increasing and two people who have been at the forefront of this work are , a professor in computer science at Cornell University, and Ittay Eyal, a post-doc at the same department. They joined us for a fascinating discussion of their work on ‘selfish mining’, the incetive structure that underlies Bitcoin and their recent positive conclusions from the Miner’s Dilemma. Topics covered in this episode: Emin Gün Sirer’s early interest in cryptocurrencies and work on a cryptocurrency to incentivize bittorrent users in 2004 What selfish mining is and how miners could profit from withholding blocks How an attacker would execute a selfish mining attack Why the miner’s dilemma implies that the equilibrium might be small mining pools Why the lack of security of clients and servers is holding back adoption Episode links: Selfish Mining paper (PDF) Miner's Dilemma blog post Miner's Dilemma paper (PDF) Hacking, Distributed Meni Rosenfeld's paper on mining pool reward systems (PDF) This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/076

This episode of Epicenter Bitcoin is brought to you by Shapeshift.I.O. With no account or sign up required, it's the easiest way to buy and sell light coin, doche coin, dark coin, and other leading cryptocurrencies. Go to shapeshift.io to instantly convert all coins and to discover the future of cryptocurrency exchanges. Hello, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sylvastanku, and my name is Brian.

Fabian Kareen. Today we're going to revisit the topic that we've talked about often in the show, which is an issue of mining centralization. And we're joined today by Amin Goon-Sier and Itaïel. They're both at Cornell University and Computer Science Professor and Postdoc. And they've done a lot of important work in this field. So I'm super excited to have and join us for this discussion today. So thanks guys for coming on. Thank you for having us. Thanks for having us. So to get started, can you give a brief introduction about how you got involved in Bitcoin and what made you guys curious about this in the first place?

So for my part, my interest in cryptocurrency started a long time ago. Actually, it predates Bitcoin. Back in the 2000s, my research topic was self-organizing networks. I was looking at peer-to-peer networks. And one of the problems in peer-to-peer networks, especially like, networks like BitTorrent, where people are expected to donate resources, is keeping track of who has donated how much resources to the good of the network, and keeping track of that, and also incentivizing them to actually provide more resources as opposed to free-loading.

So to that end, I developed a cryptocurrency called Karma, and it was one of the first implemented, in fact, I believe it's the first implemented cryptocurrency that had distributed mining in it. This was 2004. And so that was my initial sort of foray into the space. That thing gets cited a lot in academic circles. So when Bitcoin came by, I read the white paper. I was very excited.

I was a little myth, to be honest, that it didn't cite karma. And I was like, oh, okay, well, let's find out if these guys got it right or if Satoshi got it right. And that was the beginning of my interest in cryptocurrencies. Yeah, that's interesting because BitTorrent, of course, there's a big problem there about who's freeloading on the system. And traditionally, sites have used registration and kicking people when they're freeloading or not providing enough resources to support the wealth of the network. Right, they do that. But typically, those sites rely on the actual value reported by your client. And it's almost trivial to hack that.

So you can always say, like, hey, I downloaded, I uploaded 15 petabytes if you want and get on the good side, the good side of the website. So you need something more, well, we needed something more robust, and that's what brought karma along. But most Bitcoiners don't actually know about history before Satoshi. The world begins with the white paper. But there has been a lot of research in cryptocurrencies going back maybe two decades. Ron Revest, of course, is one of the people who played a big role in this.

And Sean, David Shom played a big role in this. So there's a lot of research going back maybe all the way to, you know, I would say early 80s, maybe even late 70s. Wow. And Etai, what about yourself? So, like many others, I heard about Bitcoin first from a friend. He said, yeah, I'll send you a couple of Bitcoins. they were worth sense then. And I told him, no, I'm not going to install yet another app on my phone.

And nevertheless, I went ahead and looked at the white paper, Satoshi's white paper. And I read through it and I said, nah, this is not going to work. And I basically forgot about it. And after a while, I don't know why I came back to it. And I started reading more thoroughly to understand the depth behind it. And first of all I was convinced that it is kind of going to work maybe. And second of all, I started to think about ways where it might not exactly work. And this is what led to the selfish mining research project that we did good in myself.

So how did you guys come together to work on this project? I completed my PhD two years ago and I came to work on. distributed systems here in Cornell. And I had this Bitcoin idea. And I asked around and people told me, go speak to this guy about Bitcoin. And the rest of his history. Well, so, I'm leaving out the part about why he came to Cornell.

He came to Cornell to work on sort of old school distributed systems, which was his main effort at the time. And, well, he started doing this Bitcoin thing, and the name of the tech file that contained the paper that became the selfish mining paper was called BTC Prok for procrastination. So that was his side project that kind of blossomed into a line of research. So how much of your time do you to today spend on Bitcoin or cryptocurrency-related research? Maybe most of it. This is the center of my research. The security of cyber currencies and their scalability and the novel properties that they expose them on distributed systems.

So for me, I spend most of my time actually working on databases and data stores. And Bitcoin is not my main thing at the moment. But nevertheless, I find that there are lots of exciting examples that I can take from the Bitcoin world and then apply to data stores, to data management, data visualization, and so forth. And the thing you brought up before, this idea of karma embedded in BitTorrent, I mean, I've definitely heard this idea before, right, of having cryptocurrency embedded. Did you ever think of revisiting that idea and sort of relaunching it with cryptocurrency, or has someone else done something like that? I haven't actually looked. I've heard it many times, mentioned many times myself.

So we ended up actually doing a startup for some time around 2007 that did use something like a currency, tokens, unforgeable tokens, actually, to keep track of people's sort of resource contributions, and then to award them resources proportionately to their contributions. But it's been a tough space, the whole peer-to-peer file-sharing space is a very, very tough space. Most of the companies that were operating in that world have gone bankrupt, at least at the time I was looking into it.

Video bandwidth is so cheap now that maybe there aren't that many use cases. Also, in the U.S., at least, residential internet speeds have stalled. So we don't really see that many opportunities to win big by taking advantage of peer resources. Now, meanwhile, it has proved. proven to be very efficient, in my opinion, and often the fastest way to have access to files. Absolutely. I did a startup in this space. I was convinced it was going to take off. But timing is everything. You know, 2007 and 2009, you know, whatever it is the three years that we did that startup, there was a stall. And when we watched all of our competitors mostly go bankrupt,

one of them got acquired by Akamai. Akamai uses peer-to-peer for, for distributing game updates, for example. It's a very scalable way of getting to your users. Technically, it's a very, very solid idea. Market-wise, I don't know, it wasn't the right time for us back then. It might once again be the right time. Well, we just recorded a podcast with Paul Brody, who was doing the Internet of Things for IBM.

And, you know, they did this Internet of Things prototype, and there one of the components is BitTorrent, right? So they propose using BitTorrent for a device, in the future to send data around. So maybe it will have its comeback. Oh, undoubtedly, undoubtedly. These technologies never go away. And the core technical base is super exciting.

And you have access to a set of functionality that's otherwise very expensive to deploy. So yeah, no, it's not going anywhere. So talk about the selfish mining paper. Has that been sort of the main part of your work, of your work or maybe the main result of your work? So it was the start of our work, I would say. So we've gone beyond selfish mining to look at a bunch of other issues.

So I think maybe to give this some historical context, we started by looking at what made the blockchain secure and whether those protocols were indeed as good as claimed, whether the sort of the folk theorems around Bitcoin really held. And they mostly hold, except some of the most fundamental ones where we found with selfish mining were not right, that the protocol as devised by Satoshi could be gained. That was the big sort of surprising result with selfish mining. Following that, we started looking into other issues related to mining,

especially centralization. So two-face proofs of work, for example, to avoid centralization to make sure that people don't go too big. Then Itai looked at mining pool. And mining pool strategies, what their best options are and when they can attack each other and under what circumstances they would do so, which is its own fascinating line of work. And these days we're looking at how to address two issues that I think are the burning big issues with Bitcoin at the moment, which are scalability of the network and security of the network. I think security affects adoption quite a bit. And so those are the two things that sort of drive us.

So with the work and research that you've done and distributed database systems, I suppose that you have quite a, I mean, you have a different view perhaps on scalability than someone who's solely involved in Bitcoin, right? Perhaps I think the goals are the same. Everybody wants the network to scale out and to scale up, right? So Bitcoin is very good at scaling out and incorporating new players. That's wonderful. In scaling up, there may well be some limitations. And at the moment, the block size, etc., limit the network to a number of transactions that serves the network well, but will likely not allow it to compete with Visa and the like.

And so we want to make sure that the network is competitive. Well, let's revisit the topic of scalability later. For selfish mining, can you give a summary of what your finding was in that area? Yeah, yeah, of course. So the main results, perhaps, to start with the bottom line, is that you need at least two-thirds of the network to be honest miners. So we're talking about the miners that generate the blocks. It was commonly believed that as long as a majority,

more than half of them are honestly working, then the network is fine. And what we found out is that you actually need at least two-thirds of the miners to be honest. And actually, this is an optimistic bound. If you don't make any assumptions, then the bound may be even worse. So you'll need more than two-thirds for the network to be safe. The attack is not terribly complicated. The analysis is not trivial, but the attack is pretty elegant and straightforward.

You know that blocks are generated one after the other, and when a miner generates a block, is supposed to publish it to the network, and then everybody works and try to create a block that will follow this original block. And with selfish mining, the attacker keeps the block to itself, and mines on top of it without exposing it to the network. and it only exposes this secret chain, the local secret chain, when it has to, in order to maximize its revenue. So it turns out that by doing that, a miner can actually increase its revenue and earn more than he should,

more than his fair share of the mining power. And this is the essence of the attack. So, I mean, I presume if a miner holds back the block, right? So you, of course, run a risk then that someone else, finds a block and and sort of the valid block you found now, you know, the blocker was lost and you lose the money. What, in what situation, is it still better for the miner to hold back and not publish it? It's, it's kind of like a winning strategy at Blackjack. So you're not going to always win. It's, it's not, there are cases where you take a risk by holding the block

the one that you identify is the first block that you have discovered, and you're keeping it secret. If the network finds a block at the same time, well, then now you're at a bit of a risk, and you might indeed lose that one block. But as I said, it's just like a strategy in blackjack. On average, you are expected to win, because sometimes you will end up winning in the network,

and you will end up progressing more than the network itself, the honest people who came up with the community. competing block. Sometimes you'll end up building two blocks on your own that you're keeping secret. So when the network comes up with one block, well, you then plunk down your two blocks and kill off and orphan off that other one. So there are a number of scenarios where you win, and it's either the analysis on this, and it's very clear that on average, you're expected to win, and in some cases you're expected to win big with selfish men. So is the basic idea of this that a minor

in this scenario can kind of waste work for other miners so that then his work is sort of a larger proportion of the total work of the network and thus he can yeah you got it that is the core idea you can't

with the hashing power you have now that's the hashing power you've got right so so now the trick here is getting other people to work on solving what are essentially stale puzzles and therefore wasting their effort and thus allowing whatever percentage of the hashing power you've got to actually reap more rewards than spare share. Okay, so let me just rephrase this the way I understood and see if I understand it's right.

So you have one pool that is conducting the attack and the rest of the miners. The miners that are not participating in the attack will mine blocks and then your attacking pool, so for example the rest of the network may mine two blocks and then your attack hacking pool may have three. And at that point, you've held onto those three and then you publish them, um, essentially being one block ahead of the rest of the network. Yeah. Okay. And then so if then the bitcoins, the subsidy, um, has been issued to those other,

to the rest of the network for those two blocks that they mined. Um, what happens to those bitcoins? Has they been issued already or? So the subsidy, the, the, The way the subsidy works is that you only get your cash if your block ends up in the main chain. I mean, how is the subsidy implemented really? It's just a transaction, a coin-based transaction at the head of the block. So if you mine the block and you ended up outside the main chain, then...

Okay, right. So indeed, you cannot exercise the block subsidy for 100 blocks after it has been mined. So the selfish miner will end up being able to, if the selfish minor is able to open your blocks off, your blocks don't appear in the record, they disappear, and the selfish guy will collect those words. Okay, of course. But yeah, so the basic idea, right, is that a miner basically tries to make other miners waste their hashing power. Right, so, because let's say you are ahead of everyone else and like two blocks. Now, if you keep mining on that, everybody else is mining on chain that's two blocks behind.

You're basically sure that all these other miners are wasting all that energy. And as soon as you publish, it's just all wasted work. Notice, of course, that you also waste some work like you noted before. So some of the blocks you generate are going to be pruned as well because someone else is generating the blocks and your block is pruned. So you also lose some of your own mining power. and the point is that the others lose more than you do and because the mining rate is adaptive then over time you will earn more than they do and I guess one of the consequences now as an attacker you really would care a lot about being really well connected with the network

I mean I guess if you if you found the block know and if you have nodes all over over the world and then maybe you could send a block already that was found to all those notes so that if another block comes in you can propagate it extremely fast. That's a very good point because the network is not prepared for that kind of attack. So Bitcoin is incredibly robust to partitioning and denial of service type of attacks. In practice, it has been proven that it has been demonstrated that it's impossible to deny service or partition the network. But Bitcoin doesn't try to propagate blocks very fast. And so if you as the attacker build up the infrastructure to propagate blocks very fast, then you're ahead.

And Brian, you outlined exactly what a good attacker would do. So I'm a little afraid of you right now. So indeed, you'd end up building a network of sensors and you'd pre-place your block next to other people. And that way, as soon as you find out that there's a competing block, you can push your own block out. And notice that full nodes, they have a bit of a delay between accepting a block and forwarding it on.

So you can take advantage of that. and your nodes don't have to have that delay, especially if you've pre-placed your block across the globe, you can really push yours out faster than other people. Right, yeah. This is solely for the one case. You don't have to necessarily win these battles every single time to win overall.

So if you're an attacker with more than 33% of the network, then it doesn't matter if you lose these head-to-head battles inside the network. You have so much hashing power if you're above 33%. that nobody can stop you because you'll be able to build on your own block with enough frequency that you'll be able to get more than your fair share. That's why it's really dangerous to have people to have mining pools above a third of the network. Those last more to talk about, but before we do that, let's take a short break to talk about Shapeshift. Shapeshift is the fast and easy way to buy and sell alt coins. If you've ever tried to buy and sell

all coins, you know how complicated that can be. You have to find a reputable exchange, create an account there, place an order. the order to be fulfilled, that can take a long time. Not with Shapeshift. Shapeshift allows you to convert about 25 different alt coins, and they're adding new coins all the time. So you just go to their website, Shapeshift.io, and use their currency conversion tool,

which looks a lot like Google Translate for cryptocurrencies. You choose the currency you want to convert. So for instance, Dogecoin, and also the currency you want to receive. So Bitcoin, for instance. And hit start. Once you do that, you'll be presented with a Dogecoin address and QR code which you would send dogecoin to and those

would be converted and sent to the Bitcoin address with no confirmation is needed so it's really fast takes anywhere between 30 seconds to a minute to for that transaction to go through and you don't even need to create account they don't even want your email address so your privacy stays protected and did I mention it was fast because it is fast it takes no time at all. So ShapeShift is the fast and easy way to buy and sell all coins. And we'd like to thank them for the support. Go to ShapeShift.io to give it a try. And so can you explain then how would this play out? If someone had the idea to play out this attack and implement it, what would he do? So that's a great question. So there are a bunch of interesting dynamics. So here,

we would start, or an attacker would start by creating a selfish mining pool controller. That pool controller, like it I explained before, would not immediately publish the blocks he finds and instead would sit on them and would get its miners to build up on its secret block. So let me just say that, does the pool, does only the pool controller have to be aware of this attack or do the miners also need to be aware?

The miners are working for the pool controller and they will know what hash or on which hash they are mining. And if they correlate that with the publicly known tail of the blockchain, then they will be able to tell that they are indeed currently being used to mine selfishly. So that's one way to detect if your pool controller is a selfish mine. Okay. Which is I think where your question is going. Right. So then the pool controller you were saying?

Ah, so the pool controller then has its own private chain. So the thing that I was pointing out before is if the pool has more than 33% of the hash power, it doesn't have to engage in any of these head-to-head battles. It just doesn't care. If it wins them, it's nice. But even if it doesn't win them, it will still on average come out ahead because he'll be able to build chains of, you know, he'll be able to get ahead by two blocks on occasion and with enough frequency

that he'll be able to kill off the competing blocks. And that alone will give him enough of a boost to get more than 33% of the revenue. And after 33% he gets more and more and more. And a funny dynamic develops. This is, this was part of the selfish mining work that was kind of interesting, is if a selfish miner emerges and he's making money, then suppose a new person comes along. Now, you might imagine, okay, well, what's this person going to do?

Well, he has two strategies available to him at the moment. You could follow the honest protocol, and then you'll make less money than he should because the selfish mine is operating in the network. He could selfishly mine for himself, and that's fine too, except he's not going to make all that much money with that because he's small, or he could join forces with the existing selfish miner. And that's where we found a very interesting dynamic, where by combining forces,

they actually make more money than they would individually. So the network has an incentive mechanism for selfish miners to coalesce together and get bigger and bigger and bigger, which is really dangerous for the network, because that would tend to the network or tend to selfish miner force 50%. So yeah, so where would this end up, right? Because obviously, I mean at the extreme when the selfish miner controls the whole network and there's no point of selfish mining anymore. That's exactly right.

So the analysis we use is actually only relevant while the selfish mining pool is a strict minority. Once it gets close to 50% you don't need selfish mine. to earn more than you should, you can do much more devastating attacks. And the analysis here is different. You have to ask yourself how far would an attacker want to go. But I think the point here is that we don't want to test that. We don't want the network to get there. you don't want to trust on people's good intentions or make assumptions on their game theoretical incentives.

You want the network to be strongly robust against this kind of attack. Specifically, you don't want to guess what the threshold exactly is. So how large an attacker has to be, we show that it's somewhere between a very small miner 33%, but we don't really know what the minimum size of an attacker is. And some of the pools, even today, are dangerously large to the extent that if two or three pools decide to go malicious and join forces, they can start a selfish mining attack. And this is something that the network should be able to provably prevent. So, so the 50, I was going to point out that the 50% threshold is like the apocalypse.

We should never, never get there and reasoning about the ever after, what happens after the apocalypse when, you know, the network is under the control of a single, single entity. For a decentralized currency, it's very hard to reason about what's going to happen at that point. And as I pointed out, then you have to figure out, well, what were the motivations of the miners? Are they trying to, for example, maliciously take down the network, in which case they're really, they're just super happy when they reach that state. Or are they rational actors that want to make money? Well, in that case, maybe they'll back off slightly from 50%, but hover at that boundary.

Or maybe they have a time bound. They're a bunch of miners whose machinery is getting out of date, and they don't care if they eke out the last cent from the network within six months, or whenever it is that their machinery is timing out. So there are a bunch of different considerations. It's really hard to know what happens. And so these sort of counter arguments about, oh, a selfish miner would never do that because you wouldn't want to hurt the network. They don't really make sense.

They all rely on assuming a whole lot of things about what the selfish minor wants in the long term and post-apocalypse. So as I pointed out, what we want to do is make sure the network is robust against such attacks. And in fact, we developed a fix for selfish mining.

So that was the positive side of this whole line of research, not only did we identify the attack, but also identify a very simple fix that if a selfish miner were to emerge, we could just deploy it. So what kind of fix is then? So the fix adds some randomization into the network that currently people took for granted

that the selfish miner takes advantage of. So essentially what we do is we make sure that whenever, there are certain battles inside the network, sort of blocks race inside the network, we randomize who wins. That is, somebody who pre-places his blocks, somebody who gets rid of the delay from his node loops and so forth, he doesn't have an advantage over the regular honest nodes. And so that ensures that a selfish miner has to be at least 25% big before you can succeed.

At the moment, as I pointed out, we don't know, maybe a 5% could actually end up mining selfishly and making 7% of the money. Or a 10% or could end up making a few extra percent. We just don't know. But with this fix, we know that if you're below 25%, selfish mining is not a sane strategy for you. It's a net money losing strategy.

That's what the fix ensures. But, you know, there is an impossibility on the other side of this. So if somebody is bigger than 33%, nothing, absolutely nothing in the protocol, can actually do anything about that selfish miners. So we have to have to have a threshold with our fix is 25%. And we have to sort of put social pressures on people to make sure they don't exceed the threshold. Now this fix, you mentioned that if we get to this point, we would implement the fix.

Is this something that needs to be deployed when there is a selfish money that occurring? or can we implement this before that would happen? That's a good question. It can be implemented. We've implemented it. TIE's got the code. And the core developers know about the fix, but there have been other issues that are more pressing on the Bitcoin horizon.

So it could be pre-deployed. It could be deployed on demand. It's ready to go. Everybody knows about the problem and the fix. So, but this is still only, I mean, as you mentioned, right, it only it only would protect from an attacker that's

not too big, so sort of, I guess there also means if we assume that an attacker would grow during the attack because others would join the pool to make more money, then there would be a very narrow time window perhaps

only during which one could deploy such a fix. Plus, I guess there's always the situation. right? I mean, if I'm, if I were doing the selfish mining attack as an attacker, you know, even if that fix is deployed and now I'm not profiting anymore from the attack, I might be willing to pay more to people

to just come along until I'm above that 33% threshold. Those are fascinating concerns and that's what actually led Itai to his next batch of work, which is what keeps the pools from growing with without bound. And we started out just essentially being very worried that these pools, once they get big, there really is no force opposing them. And with selfish mining, they tend to get bigger and bigger, and it's actually very dangerous for everyone. So, I did some work on the miners' dilemma. And he looked at sort of modeling what happens to big pools. And he has a very surprising result, and I'll let him explain it. But it's...

completely blew at least my mind away that pools, that there is a force that keeps pools from growing without found, that pools could actually attack each other. And in doing so, make more money than they should. That is, they use some of their hash power to attack another miner, a competitor, and end up wasting effort, or seemingly waste effort, but actually make more revenue. Ty, why don't you explain the forces at play that keep the miners in check? Yeah, thanks, good. That was a perfect intro, really. I'll start with some background maybe, so the basis for this analysis

is something called block withholding. This is an old attack from perhaps even from Adam Beck's hash-cash work in 2002, and more recently it was mentioned by many Rosenfeld in 2011. So block withholding is a different kind of attack than selfish mining. It's an attack that a minor with which a minor attacks the pool he's working for. And the way it works is very simple. The miner works for the pool. It reports partial proofs of work.

So it demonstrates to the pool that it is actually working for it. But when the miner finds a full solution, so a full block that the pool can use, it just deletes this block and does not contribute it to the pool. Now because of the way Bitcoin works, this block cannot be used for anything. It's not like selfish mining. The block is discarded. So the miner harms the pool because it denies it from profit, but it also harms itself because it gets less revenue from the pool.

that it works with. And this was for a long time considered an attack that can only harm the pool and it costs you something. It's a sabotage attack. You decide that you want to harm some pool due to whatever personal or non-personal reasons. And you harm it and you pay something for the harm you cause. But just recently last year,

Gavin and Riesen, ask the small question on Twitter. He asked, do we know whether block withholding is actually a better strategy in some cases? And following this tweet, it turned out that there were at least three works in progress, mine included, that were actually investigating what happened when someone wanted to use block. withholding to increase the revenue and the simple fact is that you can do that just as Gune explained so one pool could decide to do block withholding against another pool as if it was a minor and so reduce the other pool revenue and

increase the first pool revenue and so sorry so block withholding is sometimes not just not just a sabotage attack but it can only increase the attacker's revenue. And what was interesting for me, what I started investigating is what happens when the two pools attack one another. So pool A attacks pool B and the revenue of pool B decreases and the revenue of pool A increases, but then pull B decides to attack back. And so it turns out that pool B can increase its revenue a little bit, so it won't earn as much,

but it would own more than it was just being attacked. And then the surprise came. It turns out that when both pools attack each other, both of their revenue becomes lower than what it would have been if they just honestly mined. So what happens? Each pool has a motivation to attack the other pool. Whether or not it is being attacked, it should attack the other pool. So both of them attack each other, and then the revenues of both pool decreases.

is the prisoner's dilemma or in this case called it the miners dilemma both of them should attack and then both of them make less money we once had to talk about this actually at the brilliant meetup here and one one thing that sort of came up was the idea that a pool could maybe pay a bonus if a for a minor who submits a fool proof of work so who actually actually finds a block. Of course, the downside of this, right, would be that then the variance would increase for small miners, right? So you're compromising some of the actual benefit of a pool, but would this prevent this attack? Well, you have to run the numbers with exactly what kind of

bonus you're going to give. In the most extreme case, you just give the entire block to the miner and you're actually not doing pooled mining. But the answer is what? you just said, there are some solutions like seniority and bonus for miners that find full proofs of work, they all reduce the attractiveness of a pool. And they could push miners to go to pools that do not have this limitation. My hope is that this discovery will lead miners to join forces in smaller pools where they really trust one another. not to cheat. And this could be a very good step for the for the Bitcoin ecosystem where miners work in smaller pools. They are still pulled enough for

them to have a steady revenue but the risk of decentralization. Oh sorry of centralization it will be reduced. So how would you get the miners in these smaller pools to trust one another? Because you would still have the same incentives, right? I mean, if you can do this sort of withholding attack, you still would, right, even in a private pool. Yeah, that's exactly right. So really only with out-of-band mechanisms.

They have to know each other, know their identities, or anything that would disincentivize a minor from attacking. But, Brian, this is a good development, right? So it's much better to have lots and lots of small pools than to have a few or just a couple of really, really large, anonymous entities that nobody knows who's behind,

how it's being operated, and so forth. So we would like Bitcoin to actually be really decentralized. We would like the pools to be as small as possible. Yeah, yeah, absolutely, right? But the question would be maybe if it's actually really difficult to get those kind of agreements in the small pools, then maybe that would mean for small miner, I'm not going to mine at all.

And then what's left could be, you know, larger miners who just mine on their own and not with a pool. Yeah, that's a valid concern. I think the people underestimate the benefits of even small pools, right? So if I have just the 1% of the passion power of Bitcoin, that's already low enough variance. That is, it doesn't really, if you go from 5% to 45%, you know, all you're doing is hurting the network really.

the reduction in variance is really not that big of a game. So I would much rather see, you know, 50 sum of 1% of 101% than just a couple of, you know, as we saw with G-Hash, for example, 1-55% of that was terrible. So is there anything we can do to sort of hasten our progress to this world except for buying a lot of mining hardware and starting to, you know, mine on pools and withhold blocks to frustrate him into downsizing? That's a good question. I think the nice thing is that the larger pools that are professionally operated might actually attack each other and keep each other in check. That is, I was really relieved to really hear of Italian discovery there.

It was essentially just like, oh my God, thank God there is something that's going to actually keep these guys in check. because without this, all we had was angry posts on forums and people trying to put just social pressure and making noise, whereas now we have a technical measure. So if somebody gets really big, then you might start eyeing them, you know, as a potential attack target and take them down a notch. Has somebody not, correct me if I'm wrong, is it not Manny Rosenfeld who had proposed a system by which, miners would be disincentivized from joining large pools? Many has a very nice paper on

different ways of paying out mining pools that I happen to like a lot. I think that in Rosenfeld's paper on reward system he suggested a mechanism to defend for a pool to defend against block withholding but by making a change to the way the proof of work works so not something that's

directly applicable for Bitcoin but rather a different currency or a different method to solve it in a different currency and but as as we said we do not believe that this is this is contributing to the health of the of the system we actually want a pools to have this threat So they do not become too large. Today's magic word is selfish. S-E-L-F-I-S-H. Go to let's-talk bitcoin.com to sign in,

enter the magic word, and claim your part of the listener reward. Do you guys think this is sufficient? Because there are probably other ways, right, than the larger pools can benefit. Do you think this will be sufficient to sort of, you know, keep Bitcoin at least reasonably decentralized and thus prevent some of these apocalyptic scenarios from happening? That's a good question. It's hard to tell. I think so far so good. And Bitcoin

has probably benefited immensely from having many of its participants be basically honest. In fact, in many cases, altruistic participants. People run full nodes just to run full nodes. People do not engage in these kinds of attacks, in selfish mining attacks, for example. We've seen miners attack each other. There have been cases of that, which is a good development, because it breaks apart the really large open pools. So it seems like this is sort of keeping the community going at the moment. We might need additional mechanisms, and we need a community of researchers to sort of think up what the different attack scenarios might be and what the defenses might be. So I and I are trying to do our part. There are many others like us actually looking

into Bitcoin now that it's gained so much traction and it's become such an interesting sort of fertile ground for ideas. Actually, this is a great maybe segue to bring up one of my concerns. So I brought up with a few people and once I did an episode on this as well. But it's just a sort of and I think this is maybe a little bit of a larger, bigger picture and more longer term concern about security of proof of work. But, right, so if we assume that an attacker actually, you know, has to go out and then purchase the majority of the hashing power to, you know, do all these evil things, right, then, you know, maybe today would cost, I don't know, $100 million, so who knows how much, maybe less.

But, so, you know, does this make sense to do that? Well, depends, right? depends on how much you can benefit from an attack. So one of the things that worry me a little bit, right, is that with decreasing transaction fees, well, transaction fees we'll see, I guess, but increasing block reward, you know, that's sort of as a proportion if Bitcoin gains in value.

You know, the mining reward, total mining reward, will be fairly small, and thus the total value of the hardware will be fairly small. So it will be actually, quite cheap and become even cheaper in the future to attack Bitcoin. So this is something that worries me quite a lot. And I guess the most pressing point for that will be at the block halving, right, when a lot of mining hardware becomes sort of worthless.

Yeah, I've seen a bunch of people actually worry quite a bit about the block having. And you're right, it's going to have an effect. But I don't know that it's going to be a, you know, a devastating thing. as it is, mining hardware becomes stale, or becomes outdated, fairly fast anyway. So the miners are continually churning their hardware, and they don't have an infinite time horizon. They actually have typically a six-month time horizon. So I think a lot of the worry there with the halving is probably a little misplaced. Sure, we're going to have a drop in hash rate, maybe.

but I don't think it's going to make it there have been a bunch of alternative currencies that went through the halving and they did okay so I don't see next July and not this one the next July as being a big potential problem point but you know that's just my opinion on this I would like to add that

I don't think that the halving is a singular point when people buy their equipment and when people exchange Bitcoin they know when having is going to happen and this is incorporated in the exchange rate in the price of mining equipment in everything it's not going to come as a surprise for the really long range when when the subsidies is going to drop to zero that's a bigger question and really hard to tell yeah I mean I mean actually when I started starting to be concerned about that I actually

talked about this with Channel 11 at one point. And I didn't even, I was concerned about this thing before the block caffeine. He was like, oh, the block cafe is when this is going to be most dangerous. And I think this is true, perhaps. But I think actually what makes me more concern is the

possibility of shorting Bitcoin, right? Let's say there's a Bitcoin ETF for like Coinbase and maybe you can get derivatives from Wall Street banks and stuff. You know, if you can take a big short position on Bitcoin, uh, well, you then it may let's say we can take a very large short position so that if you gain you can make

five billion dollars or something well would you lose a hundred million or two hundred million on an attack well perhaps right and then an attack could even be you know it doesn't have to destroy bitcoin it just has to disrupt it enough to the price of collapse right no that's a that's a real concern. You know, it's, yeah, being able to benefit from the short side opens us up to a larger number of players who could actually launch attacks. But I have faith in the, sort of the, I have faith in two things. One is the technology, the core technology itself. It really resists sort of the large classes of class of attacks, civil attacks and DOS attacks. And, and DOS attacks, denial of service attacks, really, really well.

It's designed to do so. And the second thing I have paid in, which was borne out by what happened when the unintentional fork happened, which was the community came together and managed to patch its way through what would have been a devastating event. And the fact that it was able to assemble itself and react to it in such a fast manner is actually a very, very good sign that should we face some unanticipated thing, we could potentially come together and develop a patch for it and then go from there. So moving on to our next topic, which is topic of scalability, which is also one of those

topics we keep coming back to and is quite discussing the ecosystem. And in fact, we had Vitalik on a few months ago, I believe, and he just published a paper on scalability, which I personally have not read yet, but getting the courage to do so soon. Can you perhaps address some of the challenges that you think are most pressing to Bitcoin with regards to scalability and some solutions that might remedy those problems? So the thing that prohibits immediate and simple scalability is that it takes time for blocks to propagate throughout the network. and if you make blocks larger or if you try to reduce the interval between blocks,

then you're going to get more forks. And forks are terrible for Bitcoin, not in a catastrophic sense, but if you have a lot of forks, then it means that users have to wait for a longer time until they're sure that their transaction was in place. So you're trading off bandwidth for latency. On the one hand, you want to see transactions go out very fast, and on the other hand, you want a lot of transactions per second. And this trade-off is the big challenge for Bitcoin scalability.

So on one hand, what you're talking about is increasing the block size to say 20 megabytes. So on one hand, you're including more transactions in those blocks, but those blocks are taking potentially more time to get validated? I don't think that we'll see that for 20 megabytes, but if you reduce the, I mean, if you eliminate the limit completely and allow for 100, half a gig transactions, then suddenly you will have problems. So I think it's illustrative to sort of think in just as thought experiments, to think about what would happen in the way extremes.

Imagine that's what Italy was mentioning. Imagine that your blocks are a terabyte big. Obviously, it's going to take so long to transmit that block that by the time it reaches, you know, propagates throughout the network. Other people will have come up with their own block and there will be forks and so forth. Also imagine that you shorten the time between blocks to, let's say, a minute, or maybe even less, say, to a few seconds, and instead of waiting for six confirmations, now you wait for 6,000 confirmations, the same amount of time, same amount of passion power. It seems like it's an equivalent transformation to what we have now, but it actually isn't. It actually creates, again, the opportunity for lots and lots of porks to arise.

So you can see that these two solution strategies, at least in the limit, are not very good. So now there's a different debate being had among the core developers about expanding the block size from its current limit to its next up, you know, to going one notch. That's a separate issue. I think that's essentially parameter selection. And It's I and I have been thinking sort of more broadly about what fundamental things are at stake here. And what are the bigger mechanisms that we could sort of play with to improve scalability? So we are in a preliminary stage at the moment, and the scalability issue will play itself out among the core developers.

They're going to pick a set of block size parameters that makes sense for the current network as it is and current network bandwidth as they are. And we'll see. And our work will hopefully come in at a point that's not suitable for immediate deployment right now, but will perhaps come in when those kinds of changes, the parameter selection is no longer sufficient to really scale the network up. So is there anything you can, because right, I mean, if you do those kind of, yeah, changes, you go to 20 megabytes or whatever or 50 megabytes or something, I mean, that, of course can work well as long as Bitcoin stays as like small niche thing. But then if you talk about the sort of aspirations, many have in the space,

then that's completely insufficient, right? Then you need to go up by much, much more. And, you know, we did the Internet of Things episode. You know, if you imagine like now machine to machine payments with Bitcoin and stuff, then, you know, maybe actually you need to go orders of magnitude above something that even Visa does today. So do you think that will ever be possible with Bitcoin? I hope so.

I hope so. We are banking on making itself. So we're working very much on changing or adding things to the protocol, not changing the base idea, but adding things to the protocol that allows us to reach out to maybe four or five orders of magnitude improvement to the scalability rate. Cool. That's great that someone's working on this. When you say four or five orders of magnitude improvement,

on the current, like basically on what is currently possible now in terms of volume, right? Yes, yes, exactly. Okay, but, you know, with regards to what Brian just mentioned, if we want to get to some orders of magnitude like Visa or potentially handling the transactions of several billion internet-connected devices. Well, five orders of magnitude would be, that would be, so what is today, maybe the limit, maybe like five transactions, per second or something now yeah three three to seven somewhere between three to seven yeah if we go

up to if we go up to 30 000 transactions per second we're already better than visa territory which is 20 000 to 40 000 i mean about visa territory i think we can take a breather there and think about the next next thing after that yeah yeah that's true maybe we should be uh yeah we won't complain if we're there but but can you say anything about like how because it seems like would that still have one central blockchain that holds all the transactions

that would you have some sort of separate blockchains maybe or do you think side chains are part of that solution side chain so the like we're keeping the

the essence of of of the of the blockchain to technology still there. It's not a completely different algorithm. But perhaps it's a bit too early to talk about the exact details. Side chains, I think, are a different kind of story because they're offering a different level of security. Yeah. In some sense, each side chain takes care of its own security. and it can go different ways.

Okay, well, perhaps we'll have to come back and have you guys back on at some point when we can talk more about the scalability and when the issue comes, how we now can make all the visa people very angry that Bitcoin has more capacity. So when we're talking about the future of Bitcoin, where do you guys see this going?

I mean, I guess we sort of alluded to it now by bringing up this visa comparison, is, do you see this becoming the sort of currency or payment system universally used of the future? What's your vision for Bitcoin?

I would love to see that happen. I'm not sure if it will. So it's as a scientist, first and foremost, we have to be open-minded. There have been many other payment systems in the past, and they succeed based on a whole bunch of reasons,

and now all of the stars have to line up for success, I think. And then they fail and they get replaced by something else. But I think the technology that Bitcoin brought to the table is so new and so, so revolutionizing, that that core technology, the idea of a global ledger, for example, the idea of a self-organizing network that propagates these unforgeable transactions.

These core ideas, I think, are here to stay with us for a while. And there will be probably successors to Bitcoin, or perhaps Bitcoin will be its own successor if it's good enough to evolve, if the community around it doesn't get stagnant, doesn't get mired in technical sort of impasses and so forth. So if it can actually evolve and change, then yes, a lot of these, the future is wide open. I really don't see the value of holding and exchanging shiny metals. And I can imagine that the digital world needs a digital store of value. But it takes a lot to really be a trustworthy store of value.

So on that topic, I think there are real challenges. So scalability was one big challenge. I think we talked about it a little bit. The second thing that makes me uneasy at night is related to security. It's in particular related to security of clients and security of servers. That is the exchanges and so forth that implement Bitcoin-based services or value-added things on top of the blockchain. So the client security story is, as you know, not so great. It's okay for a techno-savvy person to navigate.

you know, there are these 37-step sort of write-ups about what you're supposed to do to secure your bitcoins. And at some point, they involve actually building a pyramid, hiding your paper wallet, killing everybody involved in its construction and so forth. You know, that's what it takes these days. And it's just not really acceptable to go mainstream, right? You know, your non-computer savvy relatives will find it difficult to actually keep their stuff safe. And we've had some attempts to improve the situation. I love multi-sig work, but I find them hard to use myself, so I can't imagine that that's actually good.

So there has to be something better there. And sadly, I think we are dependent on our computing infrastructure, on the security of cell phones, on the security of laptops and so forth. So we need better technology, just fundamental infrastructure that's better, more secure, more trustworthy for clients. security. I think so my view on security is that it's gotten a lot better in the last year and we are getting there. I personally think that there's a lot of technology that can allow for security. So you mentioned multi-sig. We could we could also mention some hardware solutions like

ledger for instance. Then it's just a matter of figuring out what the right user experience is that technology to be, for that technology to be used by, you know, just about, you know, anyone. But I do think that in terms of technology, I mean, we're pretty much there. It's just developing the right UI. Actually, that's absolutely true. In a very funny way, for example, the treasors and so forth, the hardware wallets are fantastic, right? except we can't expect to output the whole world with treasors. It turns out, though, that many laptops actually have hardware in them

called the Trusted Platform Module. It's just a few dollars worth of hardware. It's a secure co-processor, and it can serve the function of a tracer. That's right, yeah. But it is a matter of changing our infrastructure, right? It's hard to tap into it if you use, you know, whatever it is. Like your typical Windows installation is going to have bit locker in it, but it's not going to be able to use the secure hardware processor

for storing your bit, your bitcoins. Yeah, and similarly, mobile phones are now, I think, in two or three years, now we're expecting to see mobile phones. Now I'll have a secure environment on which we can expect, you know, I'll come back to Ledger, but, you know, they're also developing a secure OS to be able to, so people can actually have these on their mobile phone. So, I mean, I think we'll get there. Absolutely.

I think the client-side security, I have sort of faith in that within maybe two years, we'll be at a point where it's significantly much better and definitely usable for a large majority of people. I mean, just in one year, we've made leaps and bounds. it's a server-side security that I think we need to be more worried about and I think there there needs to be some real improvements in terms of standards I dare I say legislation but no I don't but definitely in terms of industry standards

there's lots of room to grow. So I agree so with my researcher hat on you're absolutely right so we know what it takes for example to create secure execution environments We know what it takes to attest to properties of an operating system. So we know how to take advantage of trusted platform modules, for example. So I am also more hopeful on the client side than I am on the server side. On the server side, the problem really stems from the way people construct these services. So if you're in the valley, you're hearing this sort of narrative about how to create web services.

And, you know, that narrative is always illustrated with personal blogs or, low-value services that, you know, I want to put up a little dynamic web page here and there. Oh, sure, you know, deploy MongoDB, you know, use this cache or that or whatever. And voila, you've got a webpage that sort of does something cutesy. But when you're dealing with actual things of high value like Bitcoins, that kind of technique is no longer good enough. In particular, people end up using these NoSQL databases to store their data. And the first generation NoSQL databases that people go to, like Mongo, typically have incredibly weak guarantees. They do not guarantee consistency. They do not guarantee fault tolerance.

And people have been building websites based on these technologies. So if you do do that, well, then you'll find yourself in a terrible, terrible situation where you're using some database to store something really valuable. And that database doesn't guarantee anything. What's good for a blog isn't good for a bank. So that's really the main concern on the service everything. Well, I think that's where standards need to come into play, right? Absolutely. Either standards or better education, perhaps. Yes, yes, also better education.

But as the client side security becomes better and better, I don't think we'll need to rely so much on the server-side solutions. No, I disagree with you on that one. I disagree with you on that one. I think we'll always need centralized brokers to find each other. Imagine local bitcoins, for example. It's, yeah, you can do it in a peer-to-peer fashion, but it's hard. Imagine any kind of an exchange.

Yes, you can have a decentralized exchange, but it's actually not going to perform as well. It's going to be hard to audit. It's going to be open to all sorts of attacks. So there are a bunch of unsolved problems on the decentralization side when it comes to these services. I don't think they're going away for the next five to ten years. I was specifically talking more about holding of coins, So rather than everyone flocking to Coinbase or some other Coinbase competitor, as client-side security gets better, then I would assume people would have, and also with education, people would hold their coins.

But I may be wrong on that. No, no, I agree on the wallet services front. Absolutely. So, indeed, people should be holding their own coins on their local security devices as opposed to trusting something like Coinbase Avery. I would like to agree with that but also to note that there is an inherent problem here and another trade-off. So on one side you want security, on the other side you want robustness. So how much are you going to trust your phone to hold your coins? I mean, it can just be, I don't know, fall into the river or something and then you lost your coins. So you need replication.

and when you have replication, the attacker has more surface to get your secrets away. And this is a problem that starts with client side and goes on all the way up to the largest services out there that need to replicate their their cold wallets in a way that's... both robust and secure. And it's a challenge. There is, I don't think there are many similar scenarios anywhere for any kind of data.

Yeah, I mean, I think one of the key things too is, I mean, I think Sebastian, you totally right, right? Like, I'm sure it will become much, much easier to hold coins securely with hardware, et cetera. But that being said, of course, things will still go wrong, right? Sometimes people won't do it properly. Probably very often they won't do it properly and they will lose their coin. And I think that is a very difficult thing, right? Because when people, just like random people who like now get excited about this Bitcoin thing and then they

lose their coin and there's no one to turn to it, like there's no one they can call and say and they get it back or something. I think that's a big challenge to somehow deal with that. And, yeah, I think that's because that's just not what people are used to right people are used to something goes wrong they can call the credit card company say like hey it was stolen like something happened and and i think that's also one of the reasons i guess why people will like hosted wallets right they will regardless of the security regardless of what you know someone says oh insurance on that and stuff i think that that's very attractive no i know i agree that there i think there's still some some space for some centralized service but uh

I mean, I would like to see it moving to a direction where we don't have reliance on that so much anymore. No, absolutely, of course. And I think it's fantastic that, yeah, with hardware and multisic, et cetera, you know, it gets much better. But, yeah, I think, yeah, I mean, the server side, I agree, I agree with that concern. I think that's a big challenge. So then I shouldn't use MongoDB for my exchange startup idea. That's what you said. Not so.

Yeah, no, not if you care for your bit, but. cool well thanks so much for coming on today guys it was really great talking with you super interesting and thanks it was a pleasure and i think maybe maybe we can do another episode at some point when it comes to the topic of scaling to 30,000 transactions we're working towards it thank you very much for having us yes okay well thanks so much and yeah thanks for listening for listening if you want to you can follow us on twitter at epicenter btc and you know we'll be back next week with another episode.