Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Emin Gün Sirer & Ittay Eyal: Bitcoin-NG – Scientists Versus the Church

Episode Date: November 2, 2015

One of the concerns confronting the Bitcoin community is that of scaling the transaction throughput rate: How do we go from the current rate of approx. 5 transactions per second to a thousand times that? In this episode, we talk to Emin Gun Sirer and Ittay Eyal from Cornell University regarding Bitcoin NG; a next generation Bitcoin blockchain design that addresses some protocol based limitations preventing Bitcoin from increasing transaction throughput. Their proposal also enables fast (initial) transaction confirmations on the order of 10-20 seconds. Topics covered in this episode: Metrics to measure the security and fairness properties of Nakamoto consensus as implemented in Bitcoin. A network emulation of Bitcoin designed by their team to study properties of Bitcoin network. Technical design of Bitcoin NG Concerns with Bitcoin NG Impact of Bitcoin NG on various stakeholders if it is adopted in the main Bitcoin network. Episode links: Bitcoin-NG White Paper Bitcoin-NG: A Secure, Faster, Better Blockchain Bitcoin-NG and the Blockchain Test bed (Scaling Bitcoin Workshop Slides) This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/103

This is Epicenter Bitcoin Episode 103 with guests Imin Gunsir and Itai A.L. This episode of Epicenter Bitcoin is brought to you by Ledger, makers of the unplugged NFC hardware wallet. Half peace of mind in knowing your private keys are protected by industry standard physical security. Go to ledgerWallet.com and use the offer code Epicenter to get 10% off your first order. And by Hyde.Me, protect yourself against hackers and safeguard your identity online with a first-class VPN. Go to hide.me slash epicenter and sign up for a free count today. Hi, welcome to Epicenter Bitcoin. The show it talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sibbessing Kujo.

And I'm Meheroy. Today we are joined by Gunsir and Itai Eyal from Cornell University. They have come up with an very interesting proposal to scale Bitcoin, which is called Bitcoin NG for next generation. It's one of the most interesting. proposals because it can, this has the potential to change the scalability game in Bitcoin. Gentlemen, we are very pleased to have you on the show. Very nice to be here, thank you. So, we already had Goun and Ithai on our show before, but for our viewers that have not seen that show, perhaps it would be best to have an introduction from both of you.

Can we start with you, Gune? Sure, I'm an associate professor at Cornell University. I have been a professor for about 14 years. I've been generally looking at peer-to-peer systems and self-organizing distributed systems for a long time now. I ended up building a peer-to-peer currency in 2002, 2003, that came long before Bitcoin and had a distributed mint. It wasn't as successful.

So I've been very interested, and it's been great to see Bitcoin's success. and we've been looking at some of Bitcoin's issues that it has faced over the years. We've identified some. We've come up with some fixes. And the latest in this line of work is Bitcoin NG. I'm also the director, one of the co-directors for IC3, a new NSF-funded initiative looking at cryptocurrencies and smart contracts. And Itai, can we have your introduction?

I am a post-doctoral associate in Cornell for the last couple. of years started working seriously on Bitcoin in Cornell. We published the selfish mining attack that revealed some disconcerning facts about the security of Bitcoin. And later on, I had some better news with the miners' dilemma. It turns out that there is a gameplayed among open mining pools and that might reduce the insecurity due to centralization. which is something I guess we all lose leave for. And currently we're doing this NG project, which we'll talk about. Okay.

So to begin with, can we just have your opinion on why it is important to scale Bitcoin? And what are the fundamental limitations that prevent vanilla Bitcoin from scaling well? So I think this is a very, very simple. It's a great question to start with. And the motivation to scale up should be self-evident. We want Bitcoin to be, or blockchain technologies, to compete with existing fintech technologies. And at the moment, existing fintech systems like the Visa Transaction Processing Network can handle really large amounts of volume. And blockchain technologies have not been able to do this because of the very nature of the blockchain update protocol.

Essentially, the entire protocol is self-tuning, and it ends up issuing a block with a maximum size every so often. So that every so often is called the block interval, and for Bitcoin, that's about 10 minutes. The protocol is geared to make sure that blocks, on average, come every 10 minutes. And there's a maximum block size. So every 10 minutes, you're going to get a block that's one megabyte or less at the moment. So what that ends up meaning is you end up getting a few transactions per second overall. And that is the sort of the crux of the scalability issue, because we would really like to be able to support more than a few transactions per second

if blockchain technologies are going to support, say, nation states or go global or end up doing tiny microtransactions and enable a completely different kind of commerce. So we'd like to be able to push the envelope with blockchain technologies. and this lock size combined with lock interval ends up limiting us. The scalability debate has been sort of divided against two opinions. One is that Bitcoin should be able to handle probably like an infinite number of transactions. And on the other side is that Bitcoin should only handle high-violent transactions and we should expect other systems to be built on top.

So you're of the opinion that Bitcoin should scale and that we should be able to rely on Bitcoin to, on the protocol to handle as many transactions protectant and that having systems built on top of it is not necessarily desirable? Well, okay, so that's an interesting question. I would say that we're agnostic on that question. That is, we would like to develop technologies for handling large volumes of transactions. We're not necessarily pushing it onto the Bitcoin core. It would be nice, in my opinion, to see high scalability. actually adopted into the protocol as long as it doesn't come with a high cost. That is, it doesn't qualitatively change the Bitcoin sort of landscape. On the other hand, we're completely okay with scalability technologies being implemented on side

chains or using some other mechanisms that are off the main Bitcoin blockchain as well. We are really agnostic. The people who've been pushing against making Bitcoin scale are pushing against making Bitcoin scale because they perceive the changes that have been proposed so far to come with a cost. They believe that if we were to adopt, say, larger block sizes, that will cause more centralization, more unfairness for miners. You know, and they are right in having those concerns. So that debate is a real, genuine debate with reasonable opinions on both sides.

And, you know, we don't really... So as long as the costs aren't there, then I think everybody... involved in that debate would jump on and say, yeah, we should adopt whatever technology comes, brings us better, better, better, uh, throughputs and lower latencies. So we, we are not really pushing for either side of that debate. We're bringing something entirely new to the table and we are happy to see it either in the core or on side chains or on some other mechanism. Itai, what are your thoughts on this?

Yeah, I, I agree with what Gunn said. I want to emphasize that the scale that we're talking about really means that we're going to need both things. We want to have highly scalable blockchain or blockchains if you use several of them. And on top of them, you may have services that do transactions outside the chain. But whenever you go outside the chain, there are trade-offs that are suitable in certain cases and unsuitable in others. And you need to go back, you need to go back to the chain every so often. So to really have the system handle high, a very high volume of transactions, you need both of these. You need very efficient blockchains and off-chain mechanisms. So then let's perhaps go right into Bitcoin and G.

Can you give us an overview of what is Bitcoin and G and how is it fundamentally different from Bitcoin core. Yeah, sure. Bitcoin and G allows us to remove the bandwidth and latency limitations

that are caused due to the properties of the standard Bitcoin Protocol. We make a change that allows us to send

transactions as fast as the network propagation time is. This means that you need to wait for as according to the network size.

You don't need to wait 10 minutes. If you think it takes 30 seconds to pass a message from one side of the network to the other, this is what you need to wait roughly for your transaction to be placed on the blockchain. As for bandwidth, we can go as fast as the nodes that run Bitcoin can run. Whereas with Bitcoin today, you have limitations that come from the protocol. If you try to increase the efficiency. Just by tuning the protocol, you're going to hit a point where security starts to drop. Okay. So if I could just rephrase that, what essentially is you remove the limitations of the protocol and you're now limited only by the capacity of a network and the

capacity of networks of nodes to process transactions. So you know, you can look at this and say it basically looks like HTTP, for example. You're limited by the speed of the network and you're limited by a server's ability to push out information to a client. Not in the same architecture, but is this some sort of similar

than regular protocols over TCPIP? That's a great analogy. I think it's very, very similar. I don't know if people would remember the old days of Usenet when you used to download the news articles every so often, you would connect to another UUCP host and fetch everything every so often.

And I think that's akin to the operation of the current blockchain. And the way we change it is entirely onto, just as you said, it's much more similar to the web compared to Usenet. So instead of downloading in batches, we are doing sort of a vetting process online as fast as the nodes can process the vetted transactions. So just for clarification in this talk, when you say bandwidth, you don't really mean bandwidth for information traveling between two nodes, you really mean bandwidth, meaning how many mbs of data can the blockchain come to consensus at per unit of time, right?

Exactly. Okay. And you say that with Bitcoin NG, when a user does a transaction, then the amount of time that the transaction needs to enter into a block is limited only by the diameter of the network, meaning if the network can broadcast this transaction to all the nodes, create the block and broadcast the block to all the nodes, and if that takes only 30 seconds,

then the user will have his transaction in a block in 30. seconds itself instead of 10 minutes. So whatever is, however fast the network can run at, that is the speed at which the user will perceive the transaction to be included in a block. Is that right? Yes, that's exactly right now. Okay. So with these two clarifications, perhaps we could go into the most interesting thing in

my opinion about Bitcoin NG. Like Bitcoin NG, unlike some of the other scalability approaches, actually different finds a set of metrics to measure the health and the fairness of Bitcoin at different block sizes. And then the proposal improves on how you can achieve scale without sacrificing any of these metrics. So Ithai, could you explain what some of these metrics for measuring the health of Bitcoin are and give us plain explanations of what they are trying to measure? So we should start, I guess, with the fairness metrics. Sorry, with the security metrics.

I'll start with fairness. We want the system to be fair. So if you're mining in the system, you should get revenue that's proportional to the mining power that you own. And the reason is that if fairness is broken, then miners will tend to form big pools. because big pools have an advantage, an unfair advantage. And if miners tend to form large pools,

they might tend towards a majority and break the basic premise of the decentralization. And so fairness is a big issue. The second security metric we introduce is mining power utilization, which means how much of the mining power in the system is actually used. system is actually used to secure the system. And specifically for Bitcoin, this means the amount, the ratio of blocks that end up in the main chain. If you create a block and it ends up outside the main chain in a proved branch, then this

block did not contribute to security and attacker and needs less power in order to compete with the main network. And whatever changes we want to make in Bitcoin, we need to make sure. that these two metrics remain where they should be. So we should have fairness, and we should be utilizing as much mining power as we can. So there are also some performance measures at Ty. Do you want to talk a little bit about the consensus delay and some of the other performance metrics? Yeah, so for performance, I think there are a few of these.

I'll explain them very roughly. One is what we call consensus delay. And this is somehow a funny term for distributed systems people, such as myself, because consensus is something that's supposed to be absolute in the classic literature. And in Bitcoin, it's not absolute. It's always with high probability. You try to reach a point where everybody agree on history. but blockchains are probabilistic

protocols and so nodes may change their mind and so what we ask ourselves is how long back do we need to look in order to probably have everyone agree on history so if we look 10 minutes ago then 90% of the nodes agree on what happened before that and so we want the consensus delay to be short we want to all agree on what happens

happened one second ago. That may not be possible because it takes time to propagate information across the internet, but let's all agree on what happened 20 seconds ago. That's already great. In Bitcoin, it's closer to 10 minutes because that's the interval between blocks. The second thing is a bit more practical, I guess, if you're trying to deal with Bitcoin as a user. this is how long it will take you to realize that you're in a branch. So say you're in a branch, how long it would usually take you, or with 90% probability, take you until you realize that you were actually on a branch and you should switch to the main chain. And again, here we want to have a short time.

So we want to realize very fast that we're on a branch and we are actually switching to the main chain. Let's take a short break so we can go to Paris. I stopped into La Maison of Bitcoin, situated in the heart of Paris's startup scene, and I met with Eric Larchaveg, Ledger CEO, to talk about the Lager Nano. The Lager Nano is a Bitcoin hardware wallet based on a secure element. It is on a USB form factor that you plug directly inside your computer, and it will manage all your private keys. The signature of transactions will be done inside the secure element,

elements, thus never revealing the private keys to the host computer. It is compatible with our own ledger wallet Chrome app, which you can also use for multi-signature with Copay or Coen-Kite, and a large range of third-party applications such as mycelium, electron, green bits, green address, and so on. The Nano also exists as a cool bracelet wearable, so you can always wear proudly your Bitcoins on your wrist. The Ledger Nano is an easy-to-use hardware storage option, which doesn't compromise on security. If you want to get a secure setup for storing your Bitcoins, go to ledgerwalt.com and use the

offer code Epicenter to get 10% off your order. We'd like to thank Ledger for the support of Epicenter Bitcoin. So perhaps I can recollect all of these. So you have proposed what are the security metrics, which is fairness, which means as a mining pool grows bigger and bigger in size, it should not get more and more blocks disproportionate to what the mining power it has. If it has 20% mining power, it should only get 20% blocks. The protocol should not be such that it ends up getting 25% of the blocks when it only

has 20% of the power. The other ones were utilization that mining power should not be wasted, that most of the mining that is done should enter the main chain. And then you have the practical metrics like consensus delay which measures like what do all of the nodes agree on in history. So if I run a node and if Goun is running a node in Cornell and if we agree that 10 minutes before this point or these certain set of transactions were in the blockchain and both of us agree on the same set of transactions and all of the nodes in the world agree on that same set of transactions.

Then the consensus delay is like 10 minutes. So 10 minutes before this point, whatever happened in the network is agreed on by all of the nodes in the network. And then you had metrics which were how much time does it take for me running a node to realize that I am on a branch not on the main chain of the node. and the main chain has already diverged from me. That's precisely right. And so these are in addition to traditional distributed systems metrics

like throughput and latency. Those are very well established. Everybody understands what throughput means. That's the number of transactions you can clear per second. Everybody knows what latency means. That's the time from submission of a transaction to the time at which you can consider it committed for some degree of assurance that you need.

So I think I want to context I'm actually the work here a little bit, so we kind of delved into the metrics very, very quickly. But the debate about scalability and sort of changes to the Bitcoin Protocol has been marked by sort of vague, qualitative concerns. And, you know, I have a lot of vague qualitative concerns about a lot of things in life, right?

And I can get worried about them to no end. So what we tried to do here was actually attach some quantitative measurements to these vague qualitative concerns. People talk about centralization fears, well, what's the proper way to measure this? And I think what we came up with in this paper are concrete, sort of absolute, and I think universally agreed upon ways of actually quantifying a number that says, well, this is the level of concern we should have. This is the impact that's going to have on this concern.

So that, I think, alone, when we started doing this work, where that was our first instinct was, let's try to move this. from sort of qualitative problems and sort of arm-waving to a scientific basis. And the way to do this is to start with an actual measurable set of metrics that we could use to evaluate protocols. So that's what you saw there. We skipped the basic ones that everybody agrees on, like throughput and latency. We talked about the new ones that we introduced just so we can evaluate new proposals.

And you've built a system with which you can actually emulate and measure these factors. Can you talk about the experimentation platform that you've developed? Yeah, so I'm really excited about this. This is work done by Itai, another student, Adam F.E. Genjar, my colleague Robert Van Unessy and myself, and what we did was to build a platform. for emulating large-scale distributed systems, in particular, tailored towards emulating the Bitcoin network. So, as you know, the Bitcoin overlay network consists of about 6,500 publicly reachable nodes.

And people ask questions about this, and people have a lot of concerns about proposed changes to the protocol. And we need to be able to, I think, evaluate them in some experimental setting and say, look, you know, this new proposal will actually behave in this particular fashion in the wild. So we built this simulation framework to answer questions like this. So how does this work? In essence, we have a large number of machines at Cornell. We have about, in fact, well, so we have about 500 machines with eight cores each,

so that's 4,000 cores. We weren't able to use all of them. Until now, we used about 1,000 cores to run virtual machines corresponding to the actual full nodes at large in the Bitcoin network. Our vision is that we're going to have a one-to-one emulation platform. I don't know if you guys have seen these miniature cities that people build, you know, miniature Berlin, miniature Istanbul, miniature London, and so forth.

So think of the emulation platform as something like a miniature city, right? So you have the actual network at large on the internet. What we've built in the lab is a copy of that internet with latencies between, So, for example, there will be a node in Nova Scotia, there'll be a node at Cornell, et cetera. And we have in the lab emulated the delays and the bandwidth limitations between those nodes. So what we can do is we can actually run everything inside the lab environment and send messages from the virtual Nova Scotia node to the virtual Cornell node and have it take as much time as it would take in the real internet, in the real world. and therefore simulate and therefore not emulate and see how the protocol would behave if we were to deploy it in the world at large.

So we can answer questions without experimenting on real money, without experimenting on real things of value and without having to disrupt the world, but simply run closed, well-controlled experiments. Okay. So what's important here to realize is that this is an emulation platform and not simulation. So we talked about this before the show a bit, and the important distinction there is that with emulation, you're not making assumptions about how the network will react and only testing certain parts of the protocol,

but you're actually testing the entire protocol and simply simulating the network propagation time. Is that right? That's right. So in a simulation environment, what people typically do is they take the protocol, they write a simplified version of it within a simulation framework, typically on a single machine, running on one machine, and they need to fit the code and so forth into that sim environment. In an emulation world like ours, we are not doing that. We're running the actual code. We run Bitcoin Core, or we can run Bitcoin XT, or we can run Bitcoin NGO, or any other protocol that people might come up with. And we simply let it run at its natural speed.

We can skip some of the bits, like we can skip mining. We don't have to actually spend the cycles to mine. We can sort of create the events where the nodes find the blocks as we control them from a centralized controller. And we can then perform repeatable measurements across the network using the actual code as it would run. And because we're running the actual code with warts and all, If there is a bug in an implementation, an emulation platform will exercise that bug.

It will look at emergent behaviors in the actual code. It will not just test your understanding of it. It will not just test a simplified, paired-down version of it in a simulated environment, but it will actually run the entire code itself. Now, this is really interesting because it actually brings real scientific quantitative data to Bitcoin, which, as you mentioned, is missing now because a lot of the debate is arm-waving, some quantitative information, but that perhaps isn't necessarily of good quality and a lot of ideological and just subjectivism that frankly doesn't really serve the cause.

So let's get into the technical details of NG because those are, a lot to talk about here. Can you explain what are the fundamental differences between Bitcoin Core and Bitcoin NG? So I can give you the high-level view and maybe a tie can go into more detail. The biggest change, the big difference in sort of the 10 seconds takeaway from the NG versus core is simply that in core, what you have is a set of miners who are codifying what happened in the preceding 10 minutes or so. They issue a block and that's a lot. And that's block records what happened in the past. So it's a retrospective protocol. And so that leaves you in a bit of a lurch because suppose a block was issued, then we're in some kind of a strange state

where we don't know what happened. We're all sort of every, all of the miners are going at it, trying to come up with the next block. But nothing is really set. We're not really making progress until the next block is issued. And as soon as it's issued, we're back in that funny state again. where there are a bunch of transactions in the MAM pool, but we don't know which ones are going to make it into the next block. So that's why Bitcoin Core is retrospective, and it's sort of fundamental to every retrospective protocol. Bitcoin NG is forward-looking.

So the simplest difference is every 10 minutes, there is still mining going on. There is still blocks being issued. But every 10 minutes, what the block that's being issued is doing is it's electing, think of it as a source. soft leader election. It's not absolute in some sense. It's easy to usurp leadership from someone else by finding another block. But every 10 minutes, we designate a leader who from that point on vets the transactions coming in very, very quickly, signs them and says, hey guys,

I want this new incoming transaction to be part of the new blockchain. So that takes away that delay between the submission of a transaction until the point you can consider it done, and that also changes the throughput with which transactions can be vetted. So that's sort of the high-level intuition. If people take nothing away from this episode, I hope they will take away the central operation and the big difference, which is retrospective versus forward-looking. But, I Thai, do you want to describe the sort of the operating? of the protocol that's a finer detail between key blocks and microblocks and so forth.

Yeah, I do want to say something more about the general overview. The basic insight is that Bitcoin today does exactly the same thing only in the wrong order. So still every 10 minutes you have a leader election. And this chosen leader gets the right to serialize, to order all transactions up to that point. So leader election already occurs And once we realized that We were able to separate the leader election From the serialization

And so we put the leader election In the beginning of the epoch And for the next 10 minutes This leader creates Serializes the transactions And he can do this fast Because there is no other leader Until the next one is chosen

There is no competition here Like you had if you created If you Tune the standard Bitcoin to create very frequent blocks. So only the leader can order the transaction and he can do so fast with no contention or confusion about what the order is. Technically this is done by introducing two types of blocks instead of one. We have key blocks as in key frames for leader election and micro blocks that contain the actual transactional data.

they're all put in the same chain, so the same blockchain structure as in Bitcoin's blockchain. The key blocks are generated with proof of work every 10 minutes or so. So really think Bitcoin, the same Bitcoin mechanism. So if you don't have an issue with the security properties today, to suffer from too many forks, then with 10-minute key blocks, you're still fine. and between these key blocks the miner gets to create these microblocks very frequently think 10 seconds it can be smaller than the time it takes for messages to propagate through the network which is a really tunable tunable parameter and the microblocks can be whatever size you want

according to how much processing you think the individual nodes can the individual nodes can do And you tune these parameters and you set them in the protocol and you let it go. And so roughly every 10 minutes a new leader is chosen. And that leader serializes transactions frequently to create the ledger. And so as a user, you don't need to wait for 10 minutes until your transaction gets its first confirmation. You only need to wait for your transaction to be placed in the microblocks, say 10 seconds, plus the propagation time in the network just to make sure there is no key block

you haven't heard of. So that's certainly a very interesting idea. So that fundamentally means that suppose I am a minor in Switzerland, which I never would be, but suppose I'm a minor in Switzerland and I managed to find the next suppose I managed to find the proof-of-work puzzle.

So 10 minutes ago, somebody else had solved the proof-of-work puzzle and from his puzzle I kept on finding the kept on plugging random numbers and I found the solution then what will happen to me is for the next 10 minutes I will get the power to listen to transactions happening in the network and generate as many microblocks as I want to and put these transactions in those microblocks for the next 10 minutes right absolutely I think it ties explanation is was exactly right on in Bitcoin the core

core, what you were doing was you were getting elected as a leader and at that time you were committing to the shape of the block for the last 10 minutes. And now, when you do the proof of work puzzle, it gives you the right, so it gives you a deferred ability to construct the block as you go along. So once you find the proof of work, you are then able to craft the exact set of transactions that you want. Today's magic word is scaling. S-C-A-L-I-N-G. Head over to let's-stock bitcoin.com to sign in,

enter the magic word and claim your part of the listener award. So, for example, let's consider this scenario where 10 minutes ago, some miner in Xinjiang province had won a block, and he was creating these small, time micro-block, and putting the transactions in those blocks. And now, right at this moment, I end up winning the next block. So I become the leader. So why should I include the other guy's blocks, the Chinese miners blocks in the blockchain that I will build on?

Why wouldn't I be incentivized to just skip his blocks that are putting the transactions in and not put his blocks in because I can earn transaction fees from those transactions which the Chinese mine minor was trying to earn fees. For example, let's say there was a, let's say the Chinese guy won the block 10 minutes ago and there was Sebastian transferring some bitcoins to Brian five minutes ago and he paid a transaction fee of one Bitcoin. Now, ideally, like the Chinese guy would win that one Bitcoin because he put the transaction in his microblock. But then when I am the miner, am I not incentivized to try to put Sebastian's transaction in my own microblock so that I earn the transaction fee instead of the Chinese guy? That's a very good question.

That was the main challenge in devising this. So what you're basically saying is... incentive compatibility. The incentives for playing the way we want the participants to play have to be aligned. And the way we do this is that we split the transaction fees in a somewhat non-intuitive way. So when you place a transaction in a microblock, if you're a leader, you only get 40% of the revenue and the subsequent leader get 60%. And the reason is that Now the subsequent leader is better off following your transaction, getting the 60% fee, than putting it in his own epoch and getting only 40%.

So the current leader gets 40% of the fee, the transaction fee, and the subsequent minor will get 60% of the transaction fees that were paid on that transaction. Yeah. Okay. Okay. So I had a question regarding confirmations. Does this mean then, since we have these very short blocks, these very short blocked confirmation intervals, that a transaction can get to six confirmations within, for instance, 60 seconds. Is that about right? I wouldn't match the microblock confirmations to Bitcoin confirmations because they don't require proof of work. So being placed in a microblock, absolutely. Okay. Can you explain the distinction there? So what would be a good measure by which we could

say, okay, this confirmation is, this transaction is valid and we can assume that it's not a does all spend or some of that. So to get six proof of work confirmations like in Bitcoin, you will need to wait for six key blocks just as in Bitcoin. But your first confirmation is going to come very quickly, just as we said before. So being placed in a microblock means is your first confirmation. The subsequent microblocks are not significant.

they don't add to your security. If you want to have more proof of work securing your transaction, then you need to wait for more proof of work to come into the network in the form of key blocks. I think the way to look at this is at the moment, so there's this whole example about buying coffee with Bitcoin. And so the elephant in the room is it doesn't really work unless the merchant is willing to take a huge risk. I go up to to buy something. I issue my transaction.

It's in the mempool. Nobody knows what's going to happen to it. It's just sitting there. I could easily issue a double spend. There is now double spend as a service, so it's become a lot easier to even do this. And what you really want to do is, you know, I mean, the merchant can always take a zero confirmation transaction,

but he's taking a risk. So with NG, I will issue my transaction. the moment that transaction is signed by the current leader, it's as if it's equivalent to having been mined in a single block. So whereas there was the retrospective blocks in the past before, now we have the miner saying, hey, I am the miner who was authorized to issue and vet transactions. I'm vetting this new transaction to be in the next block.

So think of those as one confirmation transactions, and they carry approximately the same weight as a Bitcoin single confirmation. And suddenly you can do in a few seconds what you couldn't do before in Bitcoin until 10 minutes had passed away. So that's a very interesting idea that I do a transaction and I actually get the confirmation maybe in 5 or 10 seconds as long as it takes my message to propagate and the miner to sign. and for his block to propagate in the network. But the question then becomes, what holds back the miner from creating two blocks at the same height

and putting conflicting transactions in those two blocks? So, for example, let's say I want to double spend and I am in a coffee shop wanting to double spend. And I create two transactions, one to the coffee shop, one back to me, propagate both of those in the network. And let's say it's a miner in Taiwan that won the block. What prevents the miner in Taiwan from creating two different blocks at the same height? In block number one, he puts my transaction going to the coffee person, coffee seller.

And in the block number two at the same height, he puts the transaction going back to me. So these two transactions are in conflict. But they are in the blockchain at the same height. So the one confirmation, the immediate confirmation I get from that, is of less value for the person who's selling the coffee. Right. So you are putting your finger, that's a great question. We're putting your finger on the second biggest challenge when designing the NG protocol.

And we do not want miners doing this. Miners who essentially assist in other people's double spends should not be incentivized by the protocol. In fact, they should be punished. And in this case, we have a notion of a, poison transaction, and any minor caught doing a double spend like this will end up forfeiting their blocker reward plus all of the transaction fees that they vetted. So there's a very easy way for other people to recognize and say, hey, I caught this minor

doing something really odd and provide proof of it, and you will notice that for you to actually, for not to you, but in the example you gave, for the miner to assist with that double spend, he has to leave behind incontroversible proof of his malfeasance. So somebody else can come by and say, look, I caught this minor issuing these two kinds of blocks up to microblocks at the same height, and that is not good. And therefore, you should take away the block reward from him. So this is similar to what Ethereum has proposed, which is the slasher algorithm? Slasher is a proof of stake algorithm.

The relation I know is the proof of fraud. They also use proof of fraud like other examples. and it's a good technique to avoid, to prevent an attacker by retrospectively preventing the revenue. In NG what we achieve with this is that really a malicious miner that forks the microclop chains he's in charge of, he gets punished just the same way that the standard Bitcoin miner is punished if, If it tries to fork the network, I mean, you're spending resources and you might lose them. In Engines, even worse, you're definitely going to lose them because you will be proved as a fraudster. Let's take a short break and talk about hide.me.

You know, setting up a VPN on multiple devices can be complicated. Say you want to do like three devices and you have 10 different exit nodes that you want to configure. Well, that's 30 different configurations that you have to do manually in each of those devices OS. and that can take a long time. Hyde.me makes this super easy with their apps. So they have apps for Windows, MacOS, Android, iOS, and Windows phone. So you just install the app, log in, and boom, you're ready to use VPN with hide. So this is perfect if you're traveling.

You just install the app on your devices. And say you're using public Wi-Fi, you turn on the app, you connect, and you're completely protected against hacking, men-in-the-middle attacks, or any type of malicious activity. And of course, the apps work with third-fleet plan. The try out of the free plan, head to hide.me slash epicenter. It includes two gigabytes of data, which is more than enough to keep you protected when you go traveling. It also includes three exit notes in Singapore, Amsterdam, and Montreal.

And if you use RURL, so at high top me slash epicenter, it's going to give you 35% off if you ever decide to sign up for a premium account. And their premium account includes unlimited data. It includes up to five devices connected simultaneously. So you can put your grandmother using a VPN, even your docs tablet you can put on a VPN. And you can use any of their exit notes, and they've got 30 exit notes all over the world. And of course, you can pay with Bitcoin.

So give it a try, and we would like to thank High Top Me for their support of Webcent of Bitcoin. So the other question then is, your research group spent a lot of effort to outline selfish mining as a strategy where a miner can mine a block and keep it secret and try to mine on that block for some time and when he gets two blocks in a row then publish both of those blocks at the same time. And this has the advantage that once a miner keeps a block he created secret, he gets He knows what block to build on but the other guys don't.

So how does Bitcoin NG link to selfish mining? Does it improve on Vanilla Bitcoin in its existence to selfish mining? Or is it or does it make a difference at all? Bitcoin NG shares much of the same trust assumptions as Bitcoin core. In fact, in many ways, this is one of the big selling points. of Bitcoin NG is you don't, we're not coming up with any changes to the core, trustworthiness of the protocol. So, so in this regard, our exposure to selfish mining is no worse than Bitcoin core.

We do not improve on it either. The selfish mining work provided a patch for selfish miners. We had a fix where we ruled out the possibility of selfish mining by miners who had to own less than 25% of the hash and power. So that was the selfish mining work. Bitcoin NG has no bearing on selfish mining at all. If I can just interject here, it is not trivial that it doesn't have any bearing. Our initial design made it very vulnerable.

So it's by careful crafting that it is not more vulnerable to selfish mining. The incentives have to be carefully tuned. Thanks, Satai. Let's not overlook your hard work. So one of the concerns that comes to me is if I'm a minor on Bitcoin NG, suddenly I need to take care of my private, I need to sign microblocks for 10 minutes, and I need to handle my private key for those 10 minutes,

have it in my hot wallet or so, and keep on signing these microblocks. and this kind of creates new kinds of things that I need to do and doesn't it also create the risk that in those 10 minutes somebody is going to partition me off the network or create a denial of service attack against me and prevent me from you can't prevent me from signing the blocks but at least publishing the blocks and propagating the to the network correctly so you're right that there is a there is a tiny

bit of a concern there, but let's be careful about one critical fact. We are not electing an IP address as the leader. What's happening with key blocks is we're picking a key that's going to serve as the next leader. So there are gazillion techniques for how to get that key out to remote locations, multiple different locations. And there are lots and lots of well-understood techniques for protecting websites and other services from denial of service attacks. It's not just you meher who needs to be protected. You just have to get the ability to sign to a bunch of clones of yours, and any one of them can serve this function.

And so what prevents, is there any way to prevent this, or is this just a concern that we're ready to live with? I think it's just essentially the way I think of this is, if you were to layer Bitcoin NG on top of the Bitcoin network, you have all of the same features of Bitcoin. So you could, if you wanted to, you could make the key blocks big and therefore end up having every 10 minutes a big block just like you do in Bitcoin.

But plus, have the ability to fill that time between the blocks with microblocks being issued. And on occasion, let's say there are miners that get dedost. well then they do and we're no worse off than we've been in the past. And that is the worst worst case scenario. So I don't really, this is not something that I lose sleepover. It seems to me like we're strictly giving you an ability that you did not have before. So in terms of the metrics that we introduced before,

what does Bitcoin NG improve on over XT as we try to put more and more transactions? into the blockchain per minute or per 10 minutes? Then XT's blockchain is similar to Bitcoin's blockchain, and so it would reach the same scalability limits that it does. For short term, I think that there can be improvement done on the Bitcoin blockchain by parameter tune-up. There's no reason to think that the one megabyte limit that we have now is the limit that after which everything suddenly breaks.

Eventually, if the system grows enough, then we will hit these limits. And before we reach this point, the scalability limits have to be removed. This is what the Bitcoin-NG protocol is aimed to do. So if you look at our emulations on the experimental platform, and what you can see is there are a bunch of things that people can do to a standard blockchain protocol. Let's say take core and make the kinds of changes that XT is proposing, which is make the blocks bigger.

Or you could make the block interval smaller. The two are essentially isomorphic in some sense. And we looked at doing both of these things. And when you do that, as you get the blocks bigger and bigger, or as you get the block interval smaller and smaller, at some point the network breaks down. And that breakdown occurs because the information isn't propagating fast enough. Lots of forks are being produced. And in terms of the metrics we mentioned before, when the fork rate is going up,

then blocks are being wasted. So minor utilization or total utilized mining power is dropping because some poor, is coming up with blocks that are in forks and are not really making their way into the main blockchain. Fairness often goes down because big miners are at an advantage, and the small miners who are coming up with blocks are typically at these regimes with the typical traditional protocols. They are the ones at risk. They are the ones losing blocks due to forks. And if in contrast, you look at what's happening with Bitcoin and G, the response is typically flat, where you see regular Bitcoin Core or XT type approaches, sort of doing this non-linear phase transition

from operating more or less okay to just breaking down. And that's because Bitcoin NG can sort of very smoothly handle these high rates due to its slightly different protocol. So let's talk about what would be required and the sort of change is required to stakeholders in Bitcoin in order for NG to be implemented. Presumably, since the headers are different, this would affect wallets. It would affect also miners

because they would need to change your software. Can you talk about the changes needed in order for this to take place? And do you think that's likely that they would happen? So let me start with the most important stakeholder, and I'll hand off to Etai for the rest. The most important stakeholder are the clients, right, so your wallets, and SPV clients would not have to know anything at all. So they have to be changed, none at all. And that is a huge win for the realizability of this protocol.

your regular old client software that is SPV connected, your monceliums and so forth, they can just continue to operate. They issue transactions oblivious of what's happening behind the scenes. They do queries to full nodes, not having to know anything about this protocol change. So I see that as a huge win. That is a pretty impressive win, I guess. If most wallets don't have to make any changes, that's a huge advantage. Yeah, no significant changes at least. I mean, you need to acknowledge the different structure of the key blocks and the microblocks, because microblocks don't carry proof of work, so their validation is a little different. But these are really technical changes. There is no fundamental difference. As for the miners, there is really no difference at all because they're mining on a...

on a block header. So if the block is structured correctly and this can be done in a backward compatible way, then the mining hard work can continue to work without change. So I think the changes really are, I guess, to two fronts. Righty Thai. So one is on the merchant side, merchant seeking confirmation, depending on the level of confirmation they need, they will want to understand the form,

the structure of a microblock and wait for a single confirmation. And full nodes, of course, have to be, have to change to deal with the new structure. But miners themselves don't have to, regular old miners don't have to change. Mining pool operators, they are the ones affected the most. they need to understand that they now are tasked with a slightly different way of codifying a block. Instead of making it all at once, they essentially buy the right to make a block,

and then piecemeal create the block on the fly. So that's, I think, the biggest change is to the mining pool operators. So then SPV wallets don't have to change anything. Individual miners, mining for mining pools, don't have to change. what are we left with? We're left with payment providers, people running full node clients and mining pools having to change the way that they operate? I think broadly this is correct. Okay. And are we talking about a, so we're talking about a hard fork then for those stakeholders? Yes, probably. There is a hard fork for the

for the network itself. So if you wanted to make this change to the Bitcoin, then you're changing the consensus protocol. And so you're looking at a hard fork. Yeah, probably a hard fork. I'm not sure this can be done in any way with a soft fork. But this is a challenge, let's say. Yeah, so this sort of brings us to the question

of this whole skillability debate and the question of governments, which we've talked about on the show before, what is your, what are your general thoughts on this whole debate and how it's played out? And what types of governments do you think that we would need in order for Bitcoin to go forth and be able to implement changes like this, which are, I think we can all agree, important for the health of the network. So I think that the community is really maturing due to this scalability debate, which was kind of rough at times. But it's good.

It should be rough. It's the scalability question and the hard-for questions are bored. both deserve a rough discussion and the tones got kind of high. The big task, I think, is to be able to make decisions, even if there is no unanimity and to be able to move the protocol forward. I think that, I mean, Bitcoin already has some competitors and there will be more. And I think that if Bitcoin wants to keep its lead, then it needs to have some level of safe and conservative agility and power to change due to need. So I agree.

I think the discussion so far has been, I would say actually it's been far harsher than it needed to be and far less scientific. than it needed to be and far less scientific than it needed to be. I would have liked to see a discussion with a bit more hard numbers and less sort of vague concerns and more actual demonstrated issues. So I think we're slowly making our way towards that. But I think it's still an open question. I mean, it might really be that the entire network is paralyzed, that we are unable to make any changes at all to the core protocol.

And if that's the case, it's really a pity, because that would have marked, if that were true, and I would like to believe it's not true. If it were true, it would mark the end of evolution, end of lifetime for Bitcoin. If we really cannot make any changes whatsoever, then our only option is to make the technology better, is to move on to a new coin to a new blockchain.

chain. And that might well, you know, that might well be what's in our future. And I hope not. I would really like us to see a coherent, cohesive single community. I would like us to be able to roll out new changes. I would like us to be able to discuss them in a civilized fashion without censorship, without, you know, feathers getting ruffled and people going out there to ruffle other people's feathers and so forth. So I would like to see that. that discussion happens scientifically and in an orderly fashion. So, yeah, so I'm not sure that we are there, really. I'm not as optimistic as Itai seems to be.

I have faith in the people, I guess, but I haven't really seen that faith demonstrated and sort of take actual shape in at least the discussions I've seen so far. I completely agree. I think, as you pointed out, one of the, reasons why this debate got sort of, I don't want to use, or out of hand, but people did sort of go outside of, well, it's a lack of scientific data, like you said, you know, a lot of the arguments are either based on, on some qualitative data or simply just pure subjectivity. And the lack of scientific data and the lack of, of, of, of, of quality data.

of quantitative data, I think played a lot in how this debate sort of got out of hand. And the fact that now you, you know, that you've developed this emulation system with which you can actually test and see how these protocols, proposals would actually play out in sort of a real world scenario is great for Bitcoin as a whole. Yeah, we think so. You know, indeed. So anytime you propose a change, somebody will come up with, you know, umpteen different concerns. There are so many things I am concerned about in real life, right?

And if I wanted to be really deathly scared of something, I really could make myself deathly scared of vague, hand-wavy concerns of all kinds. At the end of the day, we deal with a lot of risks and sort of disruption due to change and so forth. And the way we deal with it is we just look at the numbers and say, you know, yeah, I could be worried about an asteroid hitting me. I could be worried about some change I make having all sorts of cascade effects down the line, or having all sorts of tertiary, you know, sort of trickle-down effect. But really, to a first order of approximation, a lot of these concerns are overblown. Also, I think a lot of the debate has been turned into ideal.

or political discussions, even though at its core, it's a technical discussion. So I would very much like to see us discuss it as if it's a scientific issue with numbers, with proper measurements, and not just convert everything to an ideological discussion. That is not to say that there aren't political ramifications. They will always be some when you talk about something like a monetary system. But we can compartmentalize those and discuss them separate. I'm afraid that a lot of the technical discussion has derailed itself and there may or may not be a way to actually roll out new changes. I worry that if Bitcoin might have gotten too stale and I hope it hasn't.

I hope that we can enact meaningful change. In order to push like Bitcoin NG forward, do you have some kind of ballpark numbers on how better, how more scalable, NG could be over plain vanilla Bitcoin like two orders of magnitude or do you have like rough figures on what what is possible today with a proposal like Bitcoin NG and what may be possible in the future while adopting some other sharding mechanisms that that you or other people are working on so so yeah so I think at the high level there are multiple different approaches to achieving scalability so we I think put our stake down and sort of paved the way to one particular approach, which is this forward-looking

protocols that vet after the fact. There are other techniques, like you mentioned, like sharding, which is something we also are looking into. And there are also other techniques like the Lightning Network and Sidechains and so forth that each bring something new. We see all of these techniques as being complementary. So I think I'm a little wary of doing a comparison. You know, essentially, it's sort of, I don't want to get into a, you know, a 2.5 versus 2.7 kind of an argument here.

Qualitatively speaking, we go from having a single confirmation in every 10 minutes to having a confirmation on a transaction in a matter of seconds, where that seconds is proportional to the diameter of the network in Bitcoin. and the current network diameter seems to be on the order of maybe 10 to 20 seconds or so. So to reach a few of them. I have to quantify and qualify a lot of these statements to be really precise. But because we're not talking about reaching every single host, we're talking about reaching a fairly large number and so forth. But I think that alone is a few orders of magnitude improvement over Bitcoin. Okay. So that certainly is a very important improvement over Bitcoin and would be very practical because it is better than a zero confirmation transaction for a merchant, for example.

So what are the kind of next steps that you are thinking about regarding two things regarding your proposal and be your emulation network because that is very interesting in itself? So what are the things that your group is looking to tackle in the next year or so? So for the Emulation Network we're looking at learning more about the properties of blockchain and alternative chain

behaviors we want to have larger and realistic measurements for Angie itself we just published the idea and we're curious to see

who will who will who will pick it up and what will be done with it. Our contribution here is the protocol we're not working on commercializing it at this point. Yeah, this is a pure research contribution. We're happy to see it rolled into A-coin.

We're happy to see it rolled into core. We're happy to see it used in side chains. Essentially, it's just a new idea out there to improve the state-of-the-art in blockchain technologies. And as I said, we do not have a commercial conflict of interest on this front. It's just pure regular old scientific research. Well, it's definitely an interesting proposal. And I mean, I think that it does address a lot of these scalability issues in a way that

obviously hasn't been proposed before. And hopefully, you know, this will sort of get picked up and brought into the debate and confronted with some of these other proposals like XTE and the BIP 100s and so forth. And hopefully we can come to some sort of consensus around these skillability issues and take Bitcoin forward and moving into the new, you know, moving into the new financial revolution so that it can replace all of these things that we would like it to replace. So thanks very much, guys, for joining us today. It was a little short notice and it's a little early there.

Thank you for joining us so early in the morning. Thanks, Sebastian. Thanks, maher. Yeah, thanks, guys. Our pleasure to be here. So to our listeners, thanks so much for joining us. EpiCenter Bitcoin is part of the LTV Network. You can find all of the LTV network shows as let's talk Bitcoin.com.

We release new episodes of Epicenter Bitcoin every Monday. You can watch the video version of the show on YouTube.com slash Epicenter Bitcoin. And you can also listen to the audio version on iTunes, SoundCloud. or wherever you get your podcast, it could be a podcaster app on Android or Windows phone. We're available pretty much anywhere as well as Stitcher. If you'd like to follow us on Twitter. We're at Epicenter. Sorry, Twitter.com slash Epicenter BTC.

And you can always leave us a tip, and the tipping address will be in the show description. By the way, if you're interested in getting an Epicenter Bitcoin t-shirt, you can do that by just going to iTunes and living in a review. Or it could be any other platform, like if you listen to us on Stitcher or anywhere else, and you can leave us in a review. there, just leave a review and then send us an email at show at epicenterbitcoin.com to let us know that you've done so. It will send you one of these cool episode of Bitcoin t-shirts. So thanks again for listening and we'll be back next week.