Study & contribute to bitcoin and lightning open source
Interactive AI chat to learn about bitcoin technology and its history
Technical bitcoin search engine
Daily summary of key bitcoin tech development discussions and updates
Engaging bitcoin dev intro for coders using technical texts and code challenges
Review technical bitcoin transcripts and earn sats
Date
14 December, 2016
Speakers
Transcript by
Bryan Bishop
https://twitter.com/kanzure/status/809174512105295872
Host: Mr. Ver, can you hear this?
RV: Yes, I can.
Host: Welcome to Whalepool.
Gavin: Hey Roger, it's Gavin. I heard about this.
RV: Hey Eric. I see lots of familiar names in here.
RV: Who was that? I don't know whose voice that was.
Hodl: Mr. Hodl
RV: Thanks for organizing this. Hello Mr. Hodl.
Host: Okay, ready to go. Here we have Eric Lombrozo who is a developer who has committed code to Bitcoin Core. We also have Roger Ver. Eric, could you introduce yourself?
EL: I am founder and CEO of Cyphrex Corp and I've also been a long time contributor to Bitcoin Core. I've been in Bitcoin since 2011. I'm looking to build really cool stuff with bitcoin.
Host: Thank you Eric. And Roger, could you give a short bit on you?
RV: Sure, uh. I am the first person in the world to start investing in bitcoin startups. I've also been involved in bitcoin for 6 years now. I'm also currently the CEO of bitcoin.com.
Host: I want to start with some grammar. Eric, could you tell us what a hard-fork is, exactly?
EL: Yes. So, a hard-fork is a change in consensus rules. The consensus rules are the rules that all the different nodes on the bitcoin network validate blocks have to check to make sure that it conforms to the protocol. A hard-fork changes those rules in a way where blocks that used to be invalid become valid. What this means is that some nodes are going to not agree with other blocks as to whether a particular block is valid. And unless everyone follows that, it means that most likely it will result in multiple blockchains splitting from the original blockchain. With hard-forks, you don't get the guarantee of convergence that you get with Satoshi consensus as it's designed.
2m 10s
Host: Also just to mention, we also have Alex Petrov in the chat. Alex are you there? While he's working on his mic, we'll keep going. Eric, could you please describe a soft-fork for us?
EL: A soft-fork is a change in consensus rules that only makes the rules more strict. What this means is that old nodes are still going to consider the blocks valids. New nodes can consider new blocks invalid that old nodes would have accepted. However, this does not lead to the same problem as a hard-fork because now as long as a sufficient hashpower-- and this is osmething that miners can enforce unlike hard-forks.
Host: Roger, could you please describe what you mean by "economic code" when you describe that development trends are not moving along the same trends that were started?
3m 5s
RV: Sure. So, when I first heard about bitcoin, I started reading about it. And before that my hobby was studying economics. In order for something to become useful and to become money, it has to have certain characteristics. Bitcoin had those characteristics better than any kind of money that had ever come along ever before. I knew for sure that people would start to use bitcoin and it would become really really popular to be used as money. This is what inspired me to buy bitcoins and invest in startups. I knew that people would start to use it as money. It was incredibly clear. Not to get sidetracked, I think I had a unique opportunity to really be able to see that more clearly than other people. As a hobby, I studied economics. There is something called mises' regression theorem which describes how something becomes money. It first has to become a medium of exchange, then store of value, and it first has to be a commodity. I read all these theories in books. It seemed convincing. I believed it. For those who don't know it, I spent some time in a federal prison for a victimless crime. While I was in federal prison, I was able to see before my eyes the prison economy forming and seeing how people made their own money in prison and I was able to see how in the prison economy the theories I had read about in the books were exactly right and they matched up to what people were doing in the real world. I realized tha twith bitcoin it lined up with the theory of where money comes from and what characteristics it needed. I saw in the prison economy that it was true and I saw that it was true in bitcoin. Whta has me concerned in bitcoin at the moment is that the underlying economic code and the characteristics that make it popular are being undermined and altered and damaged by the current network congestion. If that damage becomes too severe, people are going to stop using bitcoin as money and it will stop gaining market share for being used as money. We have an 8 year track record for knowing exactly what the characteristics are and what makes it popular. We don't want to change those characteristics. We know they work for sure. Don't change those. Don't break those. Don't damage those. Otherwise we risk damaging and breaking the whole bitcoin ecosystem and losing momentum and losing out to some other currency, it's not just competing against dollar and euro and yen but everything else. We want itcoin to be the fastest cheapest most secure most censorship-resistant money. We need bitcoin to be the absolute best bitcoin we possibly can. Sorry for a slighlty long winded answer. That's what I mean when I say underlying economic code of bitcoin. Host: Okay. Alex, are you there?
6m 34s
Host: Phil, pgp, are you there?
pgp: I am here.
Host: Can you introduce yourself?
pgp: I am Phil Potter. Hi Roger, Hi Alex.
EL: Hi phil.
RV: Hey phil. Thanks for joining us.
7m 10s
pgp: I am CSO at Bitfinex. You know. We've been having a rough go of it. We're in recovery mode. That's on the topic of bitcoin's future as well. I think the other co-participants here have heard me speaking about this, or I have talked with them individually at length. So, was there a particular question you wanted to ask me, or would you like me to respond?
Host: I do indeed. When Mr. Ver talks about congestion, what is your view of congestion?
pgp: Well, I mean, I think blocks are full. I think that's undeniable. I think there's people that question well what are blocks full of? You know, what maybe one's man's spam is someone else's legitimate transaction. It's hard to analyze that in too much depth except to say that there's a few characteristics of these backups that we have on the network and amongst those are a great deal of long-chain transactions with you know tons of unconfirmed inputs and lots of activity that might be characterized as on-chain gambling or on-chain or mixing or other kinds of applications that require a lot of block space to do what they're doing. And you know, they're getting crowded out. There's transactions in the mempool because people are maybe they're... let's assume it's a completely legitimate purpose, they're not getting confirmed because their business model doesn't alllow them to pay the fees the netowrk currently requires. Do I wish we had bigger blocks right now? I do. Do I see a way there safely at this pooint at this stage? Outside of what we have right in front of us with segwit, no I don't. I am frankly very concerned about any kind of contentious hard-fork, although I do want to see bitcoin scale. And I do think that part of scaling would be great if the default block size was bigger. I mean I, I'm just not sure, how to get there outside of what's in front of us right now.
Host: Eric, are the blocks full?
EL: I fully agree with what's been said. I even agree with Roger as to that I would like blocks to be much bigger. There's a couple problems though. One of them is that resources are not free. Even bigger than this is what Phil mentioned, which is the contentious hard-fork issue. It turns out to be-- hard to change these things. It looks simple in the code to change just a single number, but when you look at the incentive structure in the network and the way that consensus protocols works, what that means is that unless all the nodes are going to update and update at the same time -- and that means updating every single merchant and every single merchant and every single user. Everyone has to upgrade otherwise they wont be able to transact, or they will be forked, and they risk losing money. A lot of precautions must be taken to deal with the contingencies of that. You must have contingencies for multiple blockchains coming out of that. Which chain is going to be considered as moving away from algorithmic satoshi consensus? In this consensus system, there is an algorithm for deciding which chain is valid. As soon as you start talking about hard-forks, that consensus algorithm for picking a chain goes out the window. It's about which is the one that is actually valid. Once you do this, you've removed the algorithmic aspect of bitcoin consensus and it becomes political money decided politically. Unless you have a very fairly uncontroversial thing, for instance if there was a security issue that needs an urgent fix, that would be in everyone's interest and i think it would be easy to get everyone to agree. I have never taken a side on the "block size debate" so to speak. From the very beginning, I thought it would be great to be able to increase block size. One of the reasons I worked on segwit is that we actually found a way to increase block size without requiring a contentious hard-fork. As soon as segwit activates, we can double the on-chain capacity basically right away. We have ways of doing this, it seems a little more complex if you don't undnerstand the system, but it's not that I disagree with Roger's idea that we should have more capacity so that we don't have crowding out of transactions. I think it would be great if we could stuff an infinite number of transactions in each block, but unfortunately resources are finite and there's only so many ways that we have available to upgrade the network without breaking everything. Soft-forks have been done before, they have been done repeatedly, it's not up to developers to decide whether a hard-fork is deployed, it's not up to users, it's not up to miners. Everyone has to agree. Unless everyone agrees, it's not going to work and it's going to split the network. And also, if someone could push a hard-fork, if that was possible, that would be really dangerous. Now that person becomes a target. There would be a single point of failure where people could get coerced by state actors or other malevolent actors that could pressure the network to modify rules to their particular liking. It's frustrating that the rules are hard to change in bitcoin, but that's also a feature. It's what provides guarantees and strong system guarantees that there's not going to be a third party that can override a contract.
Host: Alex, are you here?
AP: Yeah, I'm still here.
Host: Okay, thank you. Can you go ahead and introduce yourself and tell us what you do?
AP: My name is Alex Petrov. I am working for Bitfury. My previous experience is over 20 years in computer programming, performing IT. I know many programming languages. I have worked on many different projects such as huge commercial projects having millions of users. I was also a penetration tester doing review of source code. I know how to search for risk places and vulnerabilities. I also have an economics degree, in short the basic.
Host: What is your view on the block issue and whether they are full right now?
AP: The blocks is like a small train cars. If you would like to send some transactions, you're paying a small fee to get to the place. It doesn't matter how much dollars you're sending, it could be 1 cent or 1 big box, you're just paying to send an amount of money to use an electronical form of transferring that amount. You're sending transactions in confinement of the transactions. But right now, the blocks they are taking just from a pool of unconfirmed transactions the transactions and trying to send them through. Normally you could see these trains almost slowly. The biggest issue right now is that network is not one single place. It's divided for a small different layout for a different couple layers. They are all software. Normally software doesn't allow a lot of transactions. Bitcoin Unlimited and Bitcoin XT are ... and additional layer of protocol. And then they are talking about different clients implementation, practically creating an addditional protocol implementation and these create network inconsistencies. This is not single place, but multiple layers. Right now it's creating problems, not a big one, but it's already existing.
Host: Roger, what is your understanding of Bitcoin Core's development process and how it is not implementing the changes you think are necessary to remove some of these bottlenecks?
16m 50s
RV: I think all of the business community, including Coinbase, Blockchain.info, Xapo and Circle, have been saying hey we need more capacity we need more capacity we need more capacity. There was a Satoshi Roundtable event in Florida almost a year ago. Maybe 11 months ago now. Where CEOs from these companies were there. A good chunk of the Core development team was there, including some people on this call, Alex and Eric were there and I was there. The business community was begging and pleading and saying hey we're about to hit a scaling wall, we need this now, please please do this. And the reply basically from the Core development team was no absolutely not no compromise we're going to take our time and we're going to do it this way and we don't care what the actual users who are using bitcoin for commerce are. Maybe I am mischaracterizing the response a bit, but that's certainly the way all the people in the business community felt the response was. So it left a lot of frustration in the business community side of things, especially because I think a lot of the people in the business community, intiially there was bip101 which went to 8 GB over how many years, and then they stopped asking for 8 GB, and then they asked for BitcoinXT which was 20 MB, and then they started asking for 8 MB there was an 8MB proposal, and then there was a 2-4-8 proposal, and then a 2 MB request from Bitcoin Classic. The reply at every step of the way from the Core team was 1 MB with no compromise whatsoever. I think this left a lot of people in the business community feeling like Core does not listen to businesses and that Core is not willing to compromise any way whatsoever to provide additional capacity. I had a lengthy conversation with Adam Back in Flrodia and he asked me how much scaling do we need. W edon't need to scale infinitley over night, we just need to keep up with consumer demand so that we don't start causing problems for the users of bitcoin. So we need to scale somewhere between 1.5x to 2x per year was the history and if we can keep up with that then I think we're on the right pace. Doubling the block size from 1 MB to 2 MB would have doubled capacity of bitocin and bought us another 1 year or 2 year of time to keep customers happy and keep the network moving smoothly. The other day, Circle left bitcoin. They are now busy integrating altcoins. Other businesses are now busy integrating altcoins. A year ago or two, everyone knew Bitcoin was the chosen one and now that the user experience has become so horrible with high fees, long confirmation times and high risk of double spends for unconfirmed transactions, people are looking at altcoins. I feel like the Core team, I think a lot of them think that nothing other than Bitcoin could win. I went to the Core slack channel -- and it doesn't represent Bitcoin Core -- I was talking with them a month ago hey don't you feel concerned that Coinbase is busy integrating altcoins and their reply was eff them they suck. And I asked hey what about blockchain.info, responsible for more bitcoin transactions than any other centralized web wallet, ... and again their response was eff them I hope they leave their wallet sucks. To me that just seemed crazy, these were the biggest bussinesses in bitcoin that brought more people to bitcoin and the people sitting in the Core slakc channel are saying hey we hope those businesses leave bitcoin. To me, this just seems, I feel like I'm taking crazy pills. Bitcoin is amazing we should want as many people to use it as possible. But a bunch of bitcoin supporters don't like centralized we bwallets? That's crazy talk.
Host: Go ahead.
21min
pgp: Going to Bitcoin Core slack and having a few people in there talking shit about BC.i or Coinbase... does not... that's just a few people voicing their opinion. I wouldn't conflate that to say that's what Core believes. The other thing too is that I would like to recharacterize some of those conversations in Florida. I think it's unfair to say that Core is saying 1 MB forever and no compromise. In fact, I think that segwit itself represented a compromise of sorts. And more over, I think that there's-- there's a lot of people in Core who would like to see bigger base blocks and raising sort of that fixed variable. But I think that's a question of order of operations. The first thing that has been clear with lots of experiments at 20 MB and 8 MB or what have you, is that the network needs to be upgraded and optimized to be able to handle the additional flow because it's very lumpy in nature and it can be difficult for low-bandwidth nodes to keep up. Block propagation can be very slow if you have bigger blocks. I think that Core, rightly in my estimation, is focused on upgrading the network before we address the question of increasing bigger block sizes. There are people in Core in favor of doing that. Except that-- there's a new fear of hard-forks given the Ethereum/Ethereum Classic example that we have. I would go a step further about altcoins. I've heard this a few times already. I guess you could call me a bitcoin maximalist at some level, but the reality is that I also see a role for other cryptocurrencies for a way for people to innovate on lower-value blockchains where if things go wrong, you're not disturbing the inner sanctum of bitcoin so to speak. There could be altcoins with higher bandwidth requirements, you could do things with near real-time confirmations, we see lots of these experiments. I don't think there's anything wrong with that. I think for exchanges to embrace those is part of naturla competition that has to eist in this space. I would like to see Bitcoin to be king. But I think it's unrealistic to see Bitcoin as king forever unless there's competition to keep it on top. That's just some of my thoughts on that.
RV: I agree with what you were saying Phil, and in fact almost everything from Eric and Alex on this call. I think we agree on 99% of things and maybe the question is just order of operations and maybe that would be a good next topic.
???: I want to jump in here because Roger you were talking about willingness of Core to compromise. I agree with pgp that you can't use people in r/bitcoin or Core slack people and say that's Core. There's trolls everywhere. Let's talk about the hong kong roundtable consensus where a number of core developers signed on and maybe it was a semi-formal agreement to work on segwit and then work on a hard-fork 3 months after, to expand the block size. Doesn't this show a willingness to compromise from Core developers?
EL: I really feel like I need to respond to this. I need to cover it. Regarding what Roger said in particular and I think Phil made a lot of great points. But I want to clear up some points. Bitcoin Core is an open-source software development project. Anyone can participate. All the meetings are fully public. We have a mailing list that anyone can join. At any time, someone can submit a pull request. Anyone can fork the code base and add their own features and maintain whatever they want. I think everyone encourages this as part of the open-source ethos. Most of us work as volunteers. I have never received a pyament from any of the companies that Roger mentions. I think there's a sense of entitlement where these companies want us to do something and we're not getting paid anything by these people to d oit, I think that might not be morally correct. If anyone wants to build whatever they want to this, everything is out in the open. All the source code is there. You can take it, run with it and do whatever the hell you want with it. We're giving this to the world for free. Lastly, I think the main issue here is that what's being asked for here are not just changes in the open-source software itself, but consensus rule changes. We have other implementations of bitcoin, like btcd, that support the same consensus rules. Nobody has a problem with this in Core. The problem is when you start to change consensus rules in ways that are incompatible. And this results in a serious problem on the network. Nobody has the power to get everyone on the network to agree with hard-forks. It's not up to developers, not up to miners, not up to merchants, not up to businesses. Everyone has to agree, everyone has to move. It's not that-- it's not in our power to increase the block size wit ha hard-fork. Once again, I've never taken a position myself on the block size, I would like to see it increase as better technology allows it, but given the fact that it is contentious and controversial it means that if we were to push for that, the network would split. We have seen that in Ethereum. And some people argue hey total market cap hasn't changed significantly, even though it has gone down in the past few weeks... in bitcoin I think the results would be far more serious. All cryptos trade against bitcoin. We're talking about hugely disruptive events to the entire ecosystem. And even though I totally sympathize with the idea that we want more transactions and more users and low fees, I think this overrides all those concerns. This could really crash the entire network and reduce confidence in the system and reduce fungibility, it creates more tokens and thus causes inflations, it splits the economy. There's so many issues here and even if an open-source development project could have the power to change this stuff, they immediately make themselves a target so that malicious actors know who to go after. You can't blame the Core devs for not wanting a gun pointed at their head.
???: Core was against the increasing the block size? I think this was wrong. Their discussions were about how to increase the block size in Core. In Florida, the talks were more about the Classic and Core and it was also about the trust for Core or for Classic what version we should choose how should developers work and so on. It wasn't that against a block size increase, it was about the different ways how to increase the block size. What they have right now to-- the practically, the consensus roundtable consensus in Hong Kong, it was my initiative to create the place for different parties just to find consensus. Bitcoin is all about the consensus. The consensus is always has a place if you're talking, if you're... agree to listen to the other side and find the better way. The Core right now is already build this segwit. The segregated witness is exactly the compromise. I think it's a great and solid platform how to increase the block size in a smart way and provide .. growth of transaction... and increasing the amount of transactions. It also provides a lot of extensions for future expansions, building the solid base, just increasing the block size by itself, physically, like Bitcoin Unlimited was trying to do and like was suggested from Bitcoin Classic, I think is quite risky. We have talked multiple times before about the network performance level inside the software. These performance issues should be resolved before trying to build more massive scale transaction network. It should be done, and if it doesn't solve the performance issue in the Bitcoin client, it will just lead to crash. It is very simple. Bitcoin is like a huge land, a huge community, if oyu just make one single critical mistake, then everything will be crushed. If you're trying to do that, without consensus, running your own version, you will just have small kingdoms and there will be no more consensus and the market cap will be much much smaller compared to if we were all single place.
Host: Roger, do you support segwit now? Why do you think a hard-fork wouldn't be contentious?
RV: I am a bit agnostic on the segwit issue. I think it's interesting that for the vast majority of time that segwit was being promoted, it was being promoted as fixing transaction malleability and only much more recently have people been saying it's an on-chain scaling solution. That seems like a change in the dialogue there. I am not as concerned about a software hard-fork is because we're undergoing an economic code hard-folk fork right now, and that's enough to make people fork away from the bitcoin ecosystem. I think we're heading towards a hard-fork regardless, either a software hard-fork or an economic hard-fork and I think they both pose similar danger. The upside of software hard-fork is really really good, and the downside is that there's some danger there no doubt but I think if we hard-fork the economic code of bitcoin, that's the end of the future for bitcoin. I see a hard-fork to the economic code as even more dangerous than a software hard-fork. This is why I have a difference of opinion with some of the others on this call.
???: Can you describe what you mean in more detail by an economic hard-fork?
35min 20s
RV: For the last 8 years of bitcoin, bitcoin transactions were close to free. As soon sa you saw them broadcast on the network, there was a high chance of them being confirmed. Low chance of double spending. In recent time, those things have been changing. Fees have become fee. I am sure Phil and others can tell you-- anyone running a business that has payments from multiple customers going in and out, often for a transaction with multiple inputs and outputs you're talking about tens of dollars. I tried this, and on a single transaction I had to pay $50 dollars in fees... we will start seeing people using things other than bitcoin. If you change the things that make bitcoin successful, they are going to break. Circle is quitting on bitcoin. Other businesses are going to scramble to integrate things other than bitcoin. I agree with Phil that it's good that we have these things to experiment with . It doesn't mean that we should experiment on the economic code of bitcoin. Someone made a really good point, I think it was Jeff Garzik, that in order to keep bitcoin's economic code the same, we have to change the software code. In the entire history, blocks went from 10 kb to 50 kb to 100 kb and now 1000 kb, and now it should be allowed to go to 1100 kb and that hasn't been allowed to happen and that's a fundamental change to how bitcoin works and I think that's a really dangerous change to bitcoin to allow this to stop.
Host: Alex, does this economic code that Roger is talking about, does it exist?
37m 40s
AP: So... when Roger was talking about economical hard-forks, it's not about the economics. You can have a different economical opinion or you can have a different economical theory, but it's all about the software. This soft-fork and hard-fork.. it's the only way you are trying to offer the new solution for the whole community. In a soft-fork, it's a restriction on allowed behavior. And then if people agree, they can activate the feature. If you are creating a hard-fork, it's more complex. You are updating the software in millions of computers. You should also define the precise time when they switch from the old version to the new software version. If it doesn't do that, without proper testing, if it doesn't do it without proper coordination, and this proper coordination also requires a lot of time-- so a lot of time, it's just a couple of months, so I'm thinking, it's at least like 5 or 6 months because all the businesses should test the new version and update their software and they should update their cold wallets, the hardware wallets and for hardware wallets they should also write new firmware for hardware wallets and also they provide a way how to .. end user can update their wallets. And then, once in a single moment at an agreed time, everyone should switch to the new software. It's really complicated when you have an economy like bitcoin running 24/7 just to agree on the time and do it simultaneously. If it doesn't do it simultaneously, and if not all tests are done properly, this can create a lot of problesm, like double spending -- which is something I heard you mention couple times. Bitcoin is about solving double spending. It's compensating the real economy mistake but-- just writing the blaances on the balance sheets, it's preventing the double spending. And in a hard-fork, you're switching from old version of software to new one, it's creating very dangerous moment or area or time moment when people can use the moment to double spend coins to manipulate which coins where you can stop the whole economy for .... (audio problem )...
Host: Alright, Eric, is a hard-fork even possible?
EL: I think if everyone were to agree, and I think that would require a security issue that everyone would have an interest in fixing. If there was a big security issue discovered, I think it would be in everyone's interest to fix it. I think it could be coordinated possibly, but I think the logistics are difficult just by having to have everyone install it. Right now it might be possible to have a big chunk of the network if everyone was willing to do it; I think as the network grows, it will become even more difficult to coordinate this. If it's controversial or contentious at all, then some people are going to refuse to do it, and if you get different nodes refusing on this, it breaks the network. I also wanted to point out something else-- Roger said no compromise, and that's categorically false. We have a mailing list, and most of last year was on that mailing list discussing the issues of how to increase the block size and how to do this safely and whether it was possible. We tried to find many ways to compromise. Pieter Wuille wrote a BIP to increase the block size by 17% every year and other things like that. There were a lot of people open to looking for how to do this, there was the 2-4-8 idea that was thrown around-- but none of these ideas could achieve sufficient consensus to give us the confidence that these other issues wouldn't appear. Segwit was the culmination of these discussions where it was realized we could double on-chain capacity without a hard-fork and also allow for a lot of off-chain applications. I want to point out to Roger that these things are not mutually exclusive and they don't compete with each other. We want on-chain capacity. Lightning is a separate use case, it solves a lot of problems that I think Roger wants solved. It solves zero-confirmation problem-- you can send transactions securely very quickly for low fees. I don't see how anyone would say they don't want that use case to be solved. Right now, you can't send tiny amounts and be economically viable. This is useful for content distribution and service applications. It would be great to have these other use cases that don't compete for on-chain capacity. We could get all developers behind segwit, and a hue chunk of the industry behind this, including some of the companies that Roger mentions. If you go to the bitcoincore.org site, you can see the segwit support, and a huge chunk of the industry is behind this and wants to see it activate. After a lot of work and issues, this is the best we could do -- it doubles capacity, it allows for additional use cases that we couldn't do before.
Host: Phil?
pgp: Okay, so.. One, this is a great discussion and I want to thank Whalepool for putting this together. I just want to say one thing. I have heard this mentioned a couple of times, Roger, and I just want to say that Circle has not left bitcoin. What has happened is that Circle has got out of the "on ramp" business of fiat to bitcoin, not because of bitcoin... it's really just about, that's a huge headache. I deal with the Circle guys every day. They are not out of bitcoin. I can promise you that. The retail on-ramp off-ramp for fiat is a problem. There's still a bitcoin wallet. I just want to make sure we're clear about that. One of the problems I see with the hard-fork is that, hard-forks in the past, as Eric has pointed out, there has been emergency hard-forks where there was a chain split or a bug or a security issue... but the community was much smaller. March of 2013 or something like that? That was a long time ago. It was much smaller. Market cap was much smaller. There was less at risk. It was a more defined community, you knew who to reach out to to get things done. Now the question is that if we do a hard-fork, how do we do it? What's the safest way to do that? We have Luke-Jr's idea for how to do an evil hard-fork, that's a really interesting process that I think is important to this discussion. The idea of having a hard-fork where there's potentially a sizable minority that wants to be on the old chain, well the majority chain could merge-mine the minority chain into oblivion, and hwy would you want to do this? Well, to prevent the problems that Eric is talking about-- defrauding people on the old chain, double spending, getting double spent, there are-- I think there are evolving ideas about how to handle hard-forks so that if we're going to do a hard-fork we need to figure that out. There's a whole kitchen sink full of stuff that Core would like to ptoentially address in a hard-fork, not just how to manage the block size cap, there's a lot of other things-- there's a wish list of things that people in Core have that they would like to address in a hard-fork. If we do a hard-fork and the community gets behind it, we need to develop the mechanics to make it as safe as possible, and we need to put everything in there so that we don't have to do hard-forks again because this is clearly contentious and it's taking a lot of time and energy. I want to make one more comment. This is a criticism of the segwit marketing. This gets under my skin. To say that the moment it activates that the capacity of the network doubles, that's just not accurate. The potential capcaity of the network goes up 4x, but people actually have to migrate to new address spaces in wallets in order to generate transactions that take advantage of segwit. That migration will take some time after segwit is complete. We will start to see that happening, but right now it's estimated that if all transactions were segwit transactions using the new address space, yes it would double the -- 2x the capacity right now based on how much people are using multisig and whatever and what have you, but it's not going ot happen over night. I don't like that characterization.
???: Roger,... Alex, you're back?
AP: Yep. The great thing what Phil was mentioning about the segwit too-- it's increasing the capacity if people are using these multisign, and it's also optimizing the input and output if we have transaction with multiple input and output, it's optimizing the signatures. And normally, the more we are using coins the more we are splitting them. And if you just take a look at the statistics from 2 and 1 years ago, the number of inputs from splitted coins is growing and it will grow in the future even more. Instead of using the single fraction of a bitcoin, they are splitting into smaller parts of the coins. It's meaning they are using small inputs. Segwit is the smart way how to optimize it starting from now and the future. And segwit also combines the additional extensions, so lightning for instance. I think providing a solid base for future extensions like lightning and MAST and providing additional flexibility how you can scale bitcoin and use it for multiple purposes, hugely increasing and exponentially increasing for the future. Lightning-like solution can provide a huge amount of transactions and easily competing with Visa and Mastercard and Paypal. And it's very fast transactions, you could use it to pay for coffee. It's very optimal.
Host: Do you think we should activate segwit now?
RV: As I said earlier, I am a bit agnostic on the whole thing. I guess one of my biggest complaints or things that I'm upset about is the censorship that goes on in r/bitcoin. I'm glad that Whalepool here is giving an opportunity for both sides to be heard. A lot of people in the general bitcoin dabblers or people who are just mildly interested in bitcoin go to reddit and get their news, I think the fact that people getting only one side of the opinion there, I think that's done a big disservice to both sides of my scaling debate. I think a lot of segwit supporters thought that it would have 95% support overnight, and it turned out to not be the case. I think that's a problem for both sides of the issue. One of the things that I would like to see from the Core side and the Core supporters, and I agree that you guys are not theymos and not his mom, but I think people should speak out against theymos and speak out in favor of people posting whatever they want on r/bitcoin. One of the things that concerns me the most is that I want bitcoin to be a free and open transaction platform where you don't need permission or money to authorize transactions. If people working on bitcoin aren't willing to step up and say r/bitcoin should operate a certain way, then it makes me hesistant to trust them to maintain bitcoin the way I want them to, without having to get authorization from someone. So if we want to start healing my divide and ending the animosity on both sides, then I think the very very very first step for that would be for people to speak out against theymos on r/bitcoin and until that happens I'm going to continue to see animosity and the vitriol online. In the early days of bitcoin, it was just one giant lovefest and everyone knew we were going to change the entire world for the better. There's not as much of that lovefest online, and I would like to see that again. I would like to see more people speaking out against theymos on r/bitcoin moderation. I am agnostic on the segwit question. I don't have enough hashpower to block it. I won't be the lone hold-out if I have 6% at the end.
???: You're an influential voice, Roger. It's here right now. It has undeniable benefits. We can list them. I think that segwit would dramatically benefit at the chance of activation whic hI think is a good idea, it's well tested and it might not be what you want, it's just one step towards more solutions down the road, but your endorsement would go a long way towards convincing miners to start signalling for it. Would you be willing to endorse segwit, and if not, why not?
RV: I'm willing to consider endorsing segwit. I suppose the reason why I'm not going to endorse segwit today is mainly because I feel like the current Core team didn't listen at all to the actual business community using Bitcoin.
pgp: that has nothing to do with the code that's there and ready right now. I understand your points about theymos. I think there's moderation in r/bitcoin. Theymos is not a Core developer. The core devs... you can't say Core didn't listen. There was an ongoing attempt at discussion on the mailing list-- they were working on this problem. It's here now. It doesn't matter how we got here. We have to think about the future. It's a product here, now, it's well tested. It seems to me that it would be a real shame for it to not activate or to delay activation. Why?
RV: I suppose at this point because I feel that the current Core team hasn't listened enough. I feel like they didn't listen to the Coinbase, Blockchain.info and the businesses that are bringing bitcoin to the masses. It takes both sides of the equation here, the business side and the technical side to make the protocol robust. I think they pushed out Gavin Andresen who has been treated horribly. I think that's a shame. This is the guy that Satoshi allegedly handed control of the project to. At this point I wouldn't feel bad if additional competing development teams started to rival Core's position.
???: Roger, that's like saying nash equilibrium is bullshit because Nash was a schizophrenic despite the fact that he got a Nobel prize. You have to look at the code we have right now. We're at this point where-- I almost feel like, and maybe I'm mischaracterizing, it feels like you're leading a filibuster, just because you're trying to force something that is otherwise has a -- I think-- ground support and should get activated. It's here, well tested, we can debate the next steps. To block it, or to not endorse it for political reasons, just seems like standing in the way of progress.
RV: I agree with everything you said Phil, but I also feel like it applies equally to Bitcoin XT and Bitcoin Classic and now Bitcoin Unlimited. I think ther'es a lot of political...
pgp: But those are hard-forks. Those are hard-forks. We can have those debates and we can discuss it. But as we've discussed here tonight, a contentious hard-fork without overwhelming support is a really scary proposition, unless we really do the science and the engineering and research about how to do hard-forks safely. If we're going to do a hard-fork, let's think about more than just a block size increase. We can have those discussions. But segwit is here today. It's a careful piece of engineering, it solves lots of problems besides just scaling. I don't know. One way to really destroy bitcoin, I think, is to for this to not activate because of politics, and completely discourage all the volunteers that volunteer their time to work on bitcoin-- which are dozens of people who are not just at Blockstream. I just feel like it would be a real shame for this to happen at this stage.
RV: I am open to those arguments, Phil. I will give that some more thoughts over the coming days. One plug point I would like to disagree on is that I don't thik it's fair to say that segwit has overwhelming support. It has 25% of the hashrate.
pgp: Of miners that are relatively centralized and mostly in China. There has been a big political effort to delay or block it. It's a pain in the ass technically for miners to upgrade to this anyway. I think we're seeing a delay in miners being able to signal. Maybe Alex can speak to that more frankly. But, okay, I think that overwhelming support-- I don't know, I think there's lots of users that would rather see it than not see it. I think there's a minority of people that say they don't want segwit and block it. It seems counterproductive. It may not be the best thing, but it's what we have now. "Democracy is the worst form of government, except for all the others"-- and maybe segwit is that. It's the compromise solution. More importantly, it's the tested solution before us right now, and it's a soft-fork. I respect that you have your opinions on you, and I don't mean to ride you too hard on this.
RV: You're making a strong case. I'll give it some more consideration. I would also like to hear your thoughts-- one concern I have heard is that yes segwit is a soft-fork, but it's a soft-fork that cannot be undone. If the hashrate switches, then suddenly all these segwit transactions become spendable by everyone.
pgp: Eric should answer this. But I think it's inaccurate.
EL: It's the same as other soft-forks. Once the threshold is reached, the miner incentive is there to enforce the rules becaus eotherwise their blocks get orphaned. It's a strong stable equilibrium for miners to want to do that. Reversing a soft-fork is equivalent to a hard-fork. The incentives for that are not present. That's why there's a 95% activation. We want to cross a significantly high threshold so that there's really little incentive to try to mine blocks that are not going to be accepted by the other miners. Once this activates, and this is how we have done other soft-forks so far, and bip16 which was Gavin's idea, uses the exact same mechanism of anyonecanspend to support p2sh which was used for multisig transactions. This has been done before, it's well studied, and it's safe. I don't buy those arguments, in other words.
AP: .. changing the base rules of bitcoin and increasing the block size, they are absolutely similar and they are not reversible without applying an additional hard-fork. If you would like to change the rules backwards, you need another one hard-fork just to compensate them. To go forward, we should also improve the bitcoin protocol. And some of them definitely will be little bit change the previous rules, it's just necessary to move forward. Once again, the one word you would say, it's just touch mace, the big difference what they XT Classic was offering it was just huge block size and that was dangerous. This is exactly why a lot of people was saying this is a dangerous way and it's create very risky very high-risk felt just to crash all the bitcoin and the community. It's complete just to even worse fungibility of the bitcoin, and then they aren't able to send their transactions and then the full nodes amount of full nodes will just be decreasing because they will not be able to function normally. All the talks during the last 1.5 years, it was only about how to increase it safely, how to increase the performance and make a solid base for bitcoin expansion. All these "holy wars" trying to push only one single solution just is a waste of time. Right now we have segregated witness which is tested, all we need is for it to be activated. Later we can discuss and try to improve, or maybe roll it back by hard-fork and provide another solution. If it doesn't get any capacity increase in the next 1 year, it could be dangerous and we will start to lose our community and businesses.
pgp: There are a lot of people working on layer 2 solutions that are waiting for segwit. If segwit doesn't happen, think of the downstream projects. There are 8 or 9 different Lightning projects being sponsored out there, which will be completely handstrung without this -- sure, we have some ways to do payment channels without segwit, but we don't have a trustless lightning network and the malleability fix is really helpful for that. Fixing malleability has been a holy grail for a long time. The fact that we can do it through a soft-fork... we should be activating segwit just for that alone.
AP: It's great remarks. Thinking the lightning... I was pretty skeptical about the different solutions similar to lightning, and I dislike how they were trying to implement zero-confirmation payment channels. Zero-confirmation is the grounds for double spending and it's ruining the basic idea of a bitcoin that bitcoin is solving (the double spending problem). Lightning is a brilliant idea and I like it, because it provides instant payment using the same bitcoin in a very safe manner. If you get deeper into the technical solution, you will realize it's opening a new word for micropayments. It's providing the instant payment, that you can send the money in just milliseconds in huge volumes using different channels. There's almost no way how you can manipulate or steal money or lose money and you're sending transaction, you're locking it for just a second, and if it doesn't release the transaction you will just get the money back. The solution which is working on top of the blockchain, and you still need the blockchain to provide the temporal fixes of all the balances, but it's exchanging the money, basolutely the same idea as bitcoi nworking here, just exchanging the balances of different people... You will be just pushed out from market and you wont be able to provide any services.
???: Do you think it would be good for bitcoin if Roger would endorse segwit?
AP: I think bitcoin could take number 2 or 3 position, because we're losing time. Bitcoin is right now number one. It's created biggest community and it still continues to develop at fast speed. If we are losing this speed and losing this time in "holy wars" and in aggressive discussion, we're practically losing our resources. The most major resource we have is time. Other competitors can beat bitcoin and push segwit out to market. Like bitcoin, like a great solution, like the community of bitcoin. Because the businesses create the solid ground and they fulfill the bitcoin by cost. Bitcoin still has great brilliant community pushed by different brilliant and bright ideas how to make the bitcoin more efficient and more safe and more better place.
???: Eric do you think it would be good for Roger to endorse segwit?
EL: I would love for Roger to endorse segwit. It's something I worked on myself, so I'm personally connected to it. It's a no-brainer. There might be political reasons that people are resisting it, but it's the best of all worlds, giving something to everyone that they want. We understand the theory behind it really well. We have reduced the risks to very very low levels. I would like to see Roger endorse it. If segwit doesn't activate on bitcoin, most likely it will get activated on some other blockchain. I would like to see it activated on bitcoin first, but it might happen on another blockchain.
???: Same question to you Phil?
pgp: In deference to Roger, he's been one of the most influential people in bitcoin. His support of commercial projects was crucial in the early days of bitcoin. I think that, you know, there's an opportunity to show leadership and help close ranks around the idea that we may continue to disagree and we can fight the fight in the spring or whatever, but endorsing segwit now would definitely help us move bitcoin forward. It doesn't take us backwards, that's for sure. I think we would definitely benefit from Roger's endorsement.
???: Okay Mr. Ver, if you endorse segwit, will it be good for bitcoin? A bit existential.
RV: If I thought it would be good for bitcoin, then I would endorse it. I am agnostic at the moment. This is why I haven't endorsed it. Another interesting round of questions for everyone is that if you think Phil and Alex and others here would endorse Bitcoin Unlimited, would that be good for bitcoin? We don't need to go around and have everyone answer that.
???: One is a soft-fork and the other is a hard-fork. We have discussed the externalities of hard-forks. Segwit is a soft-fork. Do you want to fix malleability? I think, why not? And you're getting a capacity increase while you're at it. I think, yeah, I don't know, I think bitcoin would greatly benefit from your endorsement to segwit. That's yours to give, Roger.
???: Mr. Ver, we often hear there is some political reason why some figures in the bitcoin community do not endorse segwit.
RV: There's lots of conspiracy theories. I've heard that I am a CIA or NSA plant.
???: Fess up, come on. Joking.
???: Who are the figures that benefit from segwit not being activated? Open question.
RV: I think there's genuine concern from a number of parties whether segwit is the best path forward to allow bitcoin to scale. I think this is what's holding myself and a number of others back. Maybe Bitcoin Unlimited is better. This ties back into the censorship. The more free and open debate, the more they will be convinced. Maybe people on the fence becoming aware of the censorship and the suppression of my dissenting opinions, maybe that makes them more likely to support the side being suppressed, because maybe they think that moderation is an indictment on the quality of the moderator's opinions. Allow free and open discussion and debate about my topics.
EL: Do you understand that people who worked on segwit never had anything to do with those subreddit issues? They never participated in those discussions. They have nothing to do with those moderation policies. It's a separate issue. Two separate issues. They are getting conflated. I understand that you're upset because your reddit post was deleted, but let's look at the facts here. You own a media company. You own the bitcoin.com domain. You've been able to speak out on media and get your voice heard everywhere. You've been on documentaries. You've been on TV. What do you mean getting censored? You're one of the most heard voices in the entire space. So I don't think you're being honest when you say you're being censored and your opinion is unheard. Your opinion is very well known in this space. I don't see how this connects to segwit activating. I don't think it has anything to do with segwit activating.
RV: So I'm fortunate enough to be in a position that if I say something, I can get my own message out, you're absolutely right about that Eric. But there's thousands of other people who might be interested in discussing my issues on those forums, and because they don't have the same background in bitcoin as I do, their posts get deleted and they don't have any say in the discussions. It's not jus ta problem for myself, it's a problem for them as well.
pgp: The stand against the activation of segwit for that-- I agree with Eric. You're conflating two separate issues. I agree they are issues.
RV: Let me jump in and clarify. Number one, I'm not advocating to block segwit. And even if I was, it wouldn't be because of censorship. That's not why I would block segwit.
AP: You mentioned censorship. Looking at this conversation... from right now, it's more talks about how you're trepdating them, the technical community definitely all the conversation like we are talking right now..
RV: Sorry, what, I couldn't understand one word there.
AP: They are talking about the moderation. Reddit has moderators. They are trying to delete non-constructional talks. And they have a separate person who made all this moderation. It's not censorship. The technical guys have separate discussions off of reddit. And sometimes people are talking about more political topics, and yeah those are deleted definitely. And then people start to create political arenas instead of technical improvements. This is just a waste of time. Development discussion should be concentrated together. Technical people should talk about how to solve technical problems. Businessmen should talk about business. Political poeple should stay away from technical things and business facts. This is just increasing efficiency. Once again we are talking about the efficiency. If they are not using the time so that bitcoin can become number 2 or 3 and lose position totally, this would also mean, as the very strict time right now to improve it, or just to lose time. If you're trying to push any hard-fork, it also requires time. People should test it properly, and a couple of vulnerabilities were found in some of your porposals. This shows that the software is not ready.
???: And in Bitcoin Unlimited was also found to have vulnerabilities.
AP: it's very risk.y They try to increase even a simple block size increase, and they introduce lots of mistakes. We can talk about this. You still continue to protect a-- you're trying to protect the Bitcoin XT-- you were supporting the Classic. One moment, I also liked the Classic ideas like one of the possible ways of implementation, but lately I realize there is no future plan and it's very risk.y Right now, Bitcoin Unlimited is risky. Just to implement it, we need 5-6 months. They don't have that time. We should go with the solution we have right now, just to expand and survive. Or, we will be dead. It's a very easy choice. We can continue this discussion later, but right now we should just make the decision.
Host: Phil?
1h 20m 28s
pgp: I don't know. I think that, look. I think that some of theymos's heavy-handed moderation is definitely an issue. I happen to believe that we should be able to discuss these topics. We should be able to discuss this on theymos's subreddit. There's a slippery slope-- once you allow a certain set of discussion topics, it becomes more difficult to manage. I don't know if I agree with that, but maybe r/bitcoin is a default place that lots of people go, but it's ultimately a privately managed forum. Just like bitcoin.com is a privately managed website.
EL: And bitcoin.com and r/bitcoin is totally unaffiliated with the Bitcoin Core software project.
pgp: That's right. I think there's a lot of conflation between sort of, theymos, and Bitcoin Core, and I think that's been decried many many times by now. I understand, Roger, that it's still a problem in your eyes. I get that. I think conflating those two things is the wrong thing to do. And to use segwit as political football, when a lot of work has gone into this by a lot of dedicated people who only have the best interest of Bitcoin at heart, just like you do, Rog, I know you do. You live and breath bitcoin. We have something right now. I'm really worried that politics is going to get the better of this and highlight another problem with bitcoin, which is mining centralization. This is another reason why we have to be careful about a block size increase. The centralization pressures are really big. I think that at the end of the day, Bitcoin Core is interested in finding ways of more capacity. I think segwit gets us temporary breathing room. I think we'll look for other solutions. I don't think that layer 2 solutions are the only way out. I think bitcoin will have to come to terms with this. Bitcoin will have to find an on-chain scaling solution. It will have to be well-tested. It will have to be deployed with a lot of notice for the flag date, and we just don't have time for that right now. We don't have time for that.
Host: Roger?
RV: One interesting point brought to my attention yesterday, is that by limiting the amount of block space that miners are allowed to produce, that contributes towards mining centralization and it prevents additional players from coming into the mining space that might otherwise come into the mining space. The more players in mining, the more decentralized it is. This was made in an article by John Blocke. I thought that was an interesting point that hadn't occurred to me until yesterday until I read the article. I would like to encourage people to read that post. It's bitcoin economics in one lesson.
Host: Eric, si that true?
EL: I don't think it's true. Even if it were true, I'm not opposed to him wanting bigger blocks. I would love to see blocks that are bigger and support more transactions. We have real technical constraints here. This is not a political question. There are real technical issues that are really tricky issues to overcome if we want to do this without taking serious risks. None of us are in a position to push this unilaterally. I think all this blame that Roger places on Bitcoin Core developers is completely misplaced. Anyone that wants to contribute to this space, they can suggest something. That's the only thing that people can do and see what gains traction. So far none of these other ideas have gained traction. Segwit has been gaining traction. We still need to find other solutions in the future. We know that some of these other proposals propose very serious risks. Even if we wanted to do this, there's no way to do that.
???: Yeah, I mean... Roger, read the IRC logs. It's "herding cats" everywhere.
RV: That's one of bitcoin's biggest strengths and biggest weaknesses. There's nobody to blame or to go to to control the whole thing. Thta's what makes all this censorship resistant, but it's hard to get things done.
???: There's been something that appears in the chats here that has come up multiple times, and that's the phenomenon of empty blocks, and how optimizations can increase or maybe Alex or Eric could give a take on what's going on here. If you look at Antpool, these guys are, the amount of empty blocks these guys mine is shocking.
AP: So... the empty blocks, it's how the miners can show their position about supporting the bitcoin. Because yes technically you can mine an empty block. But it means you're delaying processing transactions. Bitfury made the decision for themselves to not mine empty blocks. But yes, potentially, we can lose a little bit of money. But technically, we're trying to process all transactions and more transactions. I was posting the graphs. It shows that you can increase-- empty blocks-- you can increase the transaction amounts to 10-12% per month processing more transactions. It's 450,000 transactions more if you are not mining empty blocks. Technically, it's-- the economical and technical it's your freedom and choice. You could mine on top of them, or not.
???: isn't the issue with segwit is that, doesn't it offer an improvement on validation speed to avoid some of the reasons that people mine empty blocks?
AP: Segwit provides more compressed blocks. It's like taking more transactions and having physially smaller lbocks.
EL: Sorry for interjecting. Segwit does actually provide bigger blocks. There's also a separate proposal, compact blocks, which solves latency issues between peers and speeds up sync times. This is something separate, it's not a soft-fork on the consensus layer. This is an improvement in relay capacity of nodes. As far as a fix to the validation problem, yes currently there's an n^2 with the number of signatures. It can take a long time to validate big transactions. Segwit fixes this problem. I don't think this is the real problem with empty blocks, though. Sometimes miners use validationless mining and empty blocks to get around latency issues. Alex would know more about this than me.
AP: Yes, compact blocks transferring blocks more efficiently and it's increasing the network efficiency. We have a limited amount of miners. And all the oprhans of collisions, it's decreasing the network possibility to process more transactions. What I really like about segwit is that it's a smart way for how to compact more transactions into smaller blocks. Usually in the network, you are getting more transactions. If you are performing right now like segwit, you're getting almost 2x bigger blocks. If you are performing hte hard-fork half-year later, they can take 8x more transactions per single block. In Bitcoin Unlimited, if you do a 2x block size, you're taking more than 8x... comparing the linear growth to exponential growth, it's more efficient in this way, it's also solving a lot of small problems, there's compact blocks, it's also about this saving this space. And it also provides a way to save fee on bigger transactions.
???: And not to mention that after segwit, we can do a schnorr signature soft-fork which will further increase the efficiency of block space usage.
AP: This is a big part of the roadmap, definitely. This is also something I like about segwit. The Core is not worrying about this one single short solution, they are thikning about log-term solutions, to think about more expansions and you can be sure they are trying to improve the protocol in the long-term. If you are talking about just one physical block size increase, it's only a short-term solution. It doesn't think about the long-term consequences and it doesn't think about how you will solve these other issues after increasing the physical block size. Yes, you can increase the constant in the source code, but it creates a lot of additional problems. It's not thinking about the long-term.
???: And Alex, if I can add a little bit here. I think you are ignoring some of the additional long-term planning by Bitcoin Unlimited team to end transaction malleability. There's lots of discussion going on in that team other than just Core team alone. I think it's important for people to realize that.
AP: Roger, I was following Bitcoin Unlimited. I even tested it. I also reviewed Bitcoin Unlimited source code, just like Bitcoin XT and Bitcoin Classic before it. Bitcoin XT version has a lot of issues. Technically they are risky. The way how they are trying to implement these thins, like extended blocks... are just... was more conservative, and represent less risk... Bitcoin Unlimited with flexible block size, with variationable block size on the fly, I think it's not the best solution. Just fix the block size issue is much simpler to implement. If you try to increase and decrease and have miners choosing the block space, it's more complicated and even security is more difficult. This is why I'm skeptical about this. Most of the time, people just like their own ideas and they want to push their own ideas only. Bitcoin is an open society. You can submit anything you want. When most of the technical experts reject your idea, maybe it means you should not continue to push the idea. Instead, think about another idea. The majority of engineers here are trying to choice the most affordable and most safe solution. It's like building a rocket. It should fly. Most of the people, they would like to improve bitcoin. It's not about destroying bitcoin. This is why we're still thinking about what we're doing and how we're doing it. We're trying to choice the most safe way to improve bitcoin.
???: Roger, what's the importance of nodes in the bitcoin network to you?
RV: So the importance of nodes in bitcoin to me is to provide the redundancy in the blockchain, right? The more copies of the blockchain in the world, the harder it is for someone to say it's a fake copy of the blockchain that undoes certain transactions or whatever. Someone else can say, no, there's thousands of copies. It's not the right one. So the more copies of the blockchain, the more difficult it is for people to censor bitcoin. And the more choices that SPV wallet users have for connecting to nodes. We don't need 100% of the people using hte bitcoin protocol to be running full nodes that implement the protocol.
Host: Eric, does the block size impact the ability for computers to run full nodes?
EL: Well of course, with a bigger block size it requires more resources and more bandwidth. Anything that increases a resource cost is going to put economic pressure downwards on that. I think that today's computers can handle bigger blocks. Segwit is going to deal with bigger blocks. I wouldn't have worked on segwit if I felt that computers wouldn't be able to keep up with segwit. The more that we raise resource requirements, the more expensive it becomes to run nodes. The less that people will run nodes with higher cost. There could be some validation error that goes under people's nose, if people aren't validating. If people are not validating their own transactions, then miners can maliciously include wrong transactions. A huge check on the power of miners is full nodes and users running nodes and businesses running nodes to make sure that miners are mining valid blocks. If you trust miners to validate blocks, then first of all even if miners didn't want to intentionally cause problems, there's already been issues in the past where miners run buggy code that created invalid blocks. And secondly it leads to, if you look at the game theory analysis of different miners competing with each other, there could be issues there with miners being able to do stuff that would go under the rest of the user's noses. It is important that we have a lot of full nodes in the network to make sure that everything is valid. And that's really what puts a check on the network and make sure that the coins that people are buying and selling are actually following the rules.
Host: Phil?
pgp: The one experiment I don't want ot do with the bitcoin network is exprimenting with fewer validating nodes. It's already a pain in the ass, alright. I think that, if we're not careful, we could make running a full node become more expensive and high-bandwidth requirement. And you know, increasingly centralized. Companies might say we'll run some full nodes in the full node. And all of the sudden, Amazon is running 25% of the network. I think node diversity makes sense. In bitcoin, there's no way to incentivize the nodes that are relaying the transactions and are serving up the historical blockchain to new nodes. And I think that, I don't see a way to solve that. I just think we should tread carefully around raising requirements on those operators. I think that, when we look at the block size issue, I think there's two considerations. There's the amount of data that cumulatively you're dealing with. But it's also bandwidth constraints. I think one of the problem with the bandwidth issues is that there's the bruteforce method which is that when a block is mined, you push it around and you have a huge spike in activity which does not work for a lot of people that have asymmetric download/upload speeds and other kinds of issues where their network is not being used efficiently. We have made strides towards this, but we should make that network utilization much more even and much more efficient so that when we do increase the block size, we're not going to be blugeonoing people that are-- that don't enjoy the near free bandwidth in major metropolitian areas in Europe happen to enjoy. I think we want bitcoin to proliferate around the world. Keeping bandwidth down matters for this goal.
???: We're all traders here, so I want to bring up an open related question. We're all traders here. In the past, last year, there was, we were trapped in this range $200-$300 on bitcoin price. That's when the block size and scaling debate started to get heated. Some people said that the price was stagnant because of no block size increase. So my question then is that, in general, market price has gone up since Bitcoin XT and Bitcoin Classic was going on. In general, what do you guys think relevance of the market price of bitcoin in signalling the sort of appropriateness of which scaling solution should be used?
Host: Roger? Do you want to take that?
RV: Sure. If you guys are traders, then I'm sure you know. There are a million and one things that are effecting the market at any one time. We can speculate what the contributing factors are. It's hard to know. I think one of the things that has caused the price to go up is that more people are using bitcoin. The more people use bitcoin, the more they want to use it, and the more the price goes up because of the limited supply. I think the people using bitcoin on a daily basis are unaware of my scaling debate compared to people involved day in and day out with bitcoin.
Host: Is it important for nodes to run behind tor?
RV: I think it's better for them to be able to run behind tor than not. I've been thinking about this other thing, I think it's the absolute number of full nodes that counts, not the percentage. Why, why not? Do people agree or disagree? If all the full nodes are running in one data center, then that doesn't count. It's the absolute number not the percentage.
pgp: I would defintely agree with that. I think it's the number of nodes and you have to weight that against that the location diversity through looking at the octets on the IP address.
EL: Don't forget that nodes provide relay services. If you can't relay to all the clients, then that's also a problem.
???: I think his.... point is that it's not about constant percentage of number of users. It's just that, some users run the bitcoin protocol and other people rely on trusted third parties. I think provider diversity is important.
AP: Connectivity.
???: Yes, connectivity.
AP: It should be fast enough-- the more transactions you enable to process, the number of full nodes is also the ability o the network to process more transactions. If you want to increase the number of transactions, you also have to increase full nodes. If you increase the cost of running full nodes, then you have to increase transaction fees. It's the operational cost of running the bitcoin network. If you are increasing the physical block size, without any other smart changes, it's increasing the requirements for each node.s The bandwidth requirements will be higher. Disk storage requirements will be higher. The fee or just sending the transaction is going to be higher. It's operational cost.
Host: How can we connect better with China, Roger?
RV: If I can add one last thing or two to the full node discussion, I think it's worth pointing out that, so, let's say just for a thought experiment here, let's say the block size was instantly sent to 10 MB over night so now the bitcoin network is given 10x more transactions. Even if 0.5% of the full nodes today are still running at 10 MB, you still have a much greater number of full nodes around the world. To get more full nodes around the world, get more people involved in bitcoin. I'm sorry, what's the actual question?
Host: Eric, can you respond to that?
EL: In what way?
RV: More people using bitcoin and more business and more everything in bitcoin, would mean more full nodes around the world.
EL: That's true to an extent. I think the incentive structure needs to be correct. In the beginning, it was right for nodes. You could mine on your CPU, everyone was mining bitcoin on their laptop. That was their incentive. That's no longer the case, though. They have other incentives to run full nodes for now. If we have more people using bitcoin for consumer applications or point-of-sale, that doesn't necessarily imply that people are going to want to run full nodes. In the beginning, most of the people were enthusiasts and hobbyists and as bitcoin becomes more a mass consumer product or network, unless there's actual economic incentives for people to run nodes, unless people can make money doing it, I think really you reach this-- it's a tragedy of the commons. People rely on others to validate others, without having to put up any of the cost. I think the more expensivie ti s to run a node, the more we will see that.
Host: Phil, would you care to comment and maybe link that to price?
pgp: I think that, how users feel about bitcoin and the price and you know and people looking to see whether price is signalling uh, you know, people favoring one solution or the other.... as someone who runs an exchange, I see the lfows, I talk to customers every day. I can tell you that the price of bitcoin can easily go to the moon without any scaling. That's because bitcoin already has a killer app--- and that's a digital store of value. It's gold 2.0, right. And people using it to store significant amounts of value don't care about paying a higher fee to pay $10k or $20k or whatever. I think that, as a result, anyone who is looking at the price and trying to correlate it with segwit adoption or whatever-- I think that's a red herring. I think that if anyone is trying to read tea leafs about what the market wants or what the market thinks, I think that's a fool's errand.
Host: Phil, I want to ask, what do you think we can do to connect better with China?
pgp: Well, I think that, I mean, are we talking about Core with China or do we mean connectivity or do we mean meta-sense? I definitely think that people in Core need to do a better job of communicating with the miner community in China. That's really important. The more literal interpretation of the question.... the fact that the Great Firewall of China exists, it does create a problem for mining. Miners in china are able to communicate with each other quickly. A lot of validationless mining going on over there where people, where one miner is just mining off the header of some other stuff-- they don't even bother to validate. They just want to start mining immediatley. Maybe antpool is validating? Maybe that's why they are mining empty blocks? While they're validating and while they're building a block they want to validate, maybe call it 30s or 1min, maybe they mine an empty block in the mean time which is why you see most empty blocks happening after right after a block gets mined. To communicate through that firewall into China, if you're mining outside of China, there's a significant problem there.
Host: Roger, can you comment on that?
RV: I agree with everything said about China. I want to back up to another point Phil made and I disagree. He said bitcoin market price can go to to the moon just as a store of value. But the reason why people use bitcoin as a store of value is because it's also being used as a medium of exchange. It must be used as a medium of exchange first. All previous stores of value were used as a medium of exchange. Bitcoin is used as a medium of exchange somewhat today, but it needs to do it more before it becomes useful for long-term storage according to me. If it's not used as a medium of exchange first, then it wont be useful. Gold was used as a medium of exchange first.
???: Gold was used first, yes, but principally as a settlement layer. Silver was the money of the day that changed hands. It could very well be that if you want to buy coffee or you want to do a microtransaction, it could be that you have to use some other blockchain or cryptocurrency which was designed for that sort of thing because bitcoin never got segwit activated and lightning network maybe didn't happen -- that could very well be. Yet at the same time, no hard-fork happening with bitcoin with this that or the other, could go a long way to proving that bitcoin is immutable not just in the sense of the ledger but in terms of its consensus rules. This could lend a lot of value itself. Yes Roger, bitcoin could be so much more. But if it doesn't become that, it still could be -- the price still could go up very dramatically, perhaps not as dramatically as it could.
RV: Maybe where we can agree on this, the odds of it being used as a store of value is much higher if it is used widely as a medium of exchange.
???: I disagree a little bit on that. I don't think it's a big deal. It's already found the store of value thing. You commented that it must be a medium of exchange for all historical assets-- I've heard you say that before. I'm not sure it's really true.
RV: Even if you look at the different fiat currencies around the owrld, they all started as some precious metal and then became government issued paper.
???: And that's fine. We had silver and we had gold. I'm not sure that bitcoin, I don't think, it may be too risky-- to come back to a dev point here. It might be too risky to try to force bitcoin to be all things to all people. At least, doing that in a timeframe that the market seems to defend. It may be that the safer solution is to have multiple blockchains at the end of the day. I'm not necessarily advocating this, but I think it might be reasonable to think of it this way.
RV: I agree that's something worth considering Phil, I'll give it some more thought. I have to drop off the call now. I'll be happy to have a second edition of this in the near future.
EL: Thanks Roger.
pgp: Thanks.
Host: Thanks. Alex?
1h 56m 50s
Community-maintained archive to unlocking knowledge from technical bitcoin transcripts