Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Andrew Clifford & G. Andrew Stone: Bitcoin Unlimited

Episode Date: January 17, 2017

Years into the controversy around how to scale Bitcoin, there have been many challengers to Bitcoin core’s dominance. After XT, Classic and others have faded, Bitcoin Unlimited has been gaining traction and emerged as plausible new way forward. Bitcoin Unlimited wants to make the block size a parameter that is set by miners and nodes, but not fixed at a network level. They argue a natural fee market would emerge, allowing Bitcoin to rapidly scale and realizing its promise of electronic cash as well as store of value. The project is also member-driven, with democratic decisions driving its development decisions. Core developer G. Andrew Stone and Bitcoin Unlimited President Andrew Clifford joined us for the episode. Topics covered in this episode: How Stone and Clifford first got involved in Bitcoin The history of the blocksize debate and Bitcoin core alternatives Why the Bitcoin block size should be determined by miners not developers The natural fee market that would arise controlling the size of Unlimited blocks How the non-profit organization behind Bitcoin Unlimited works How a transition to Bitcoin Unlimited could look like Episode links: Peter Rizun: How Bitcoin Unlimited deals with large blocks Bitcoin Unlimited Website G. Andrew Stone: Examining Effect of Single Transaction Blocks on Network Peter Rizun: A Transaction Fee Market Exists Without a Block Size Bitcoin Unlimited Member Forum Bitcoin Network Hashrate Distribution This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/166

This is Epicenter Episode 166 with guests Andrew Clifford and G. Andrew Stone. This episode of Epicenter is brought you by the Ledger NanoS, the hardware wallet which sets the new standard in security and usability. Get it today at LedgerWallet.com and use the offer code Epicenter to get 10% off your order. And by Jax. Jax is the user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to JAAWX.io and embrace the future of cryptocurrency wallets. Hello and welcome to Epicenter, the show which talks about the technologies, projects and startups by decentralization and the global cryptocurrency revolution. My name is Brian Fabian Crane.

And I'm Meher Roy. Our episode today is focused on the Bitcoin block size debate. We have as guests, Andrew Clifford, who is the president of Bitcoin Unlimited, and G. Andrew Stone, who is the lead. developer of Bitcoin Unlimited. Today we are going to talk about how Bitcoin Unlimited as a project came to be, what its fundamental tenets are, and what do they see as they pass forward. So before we start, we would like both of you to give us an introduction and tell us about

your background. First, starting from G. Andrew Stone, who we will refer to as Zerg during the interview. In 2012, I was working on an open source hardware project, and I discovered that I was spending a lot of the money that the project that the board ultimately sold for actually dealing with moving the money around the world because parts are sourced in China and then fabrication it happens in China. Then everything gets shipped to the U.S., and then I ship it out to Europe. And so I kind of was looking for a simpler solution and a more efficient solution. And I ran into Bitcoin. And obviously, you know, it was not really applicable at that time since it was so small. But, you know, having read the white paper, it really kind of caught my attention.

And what about you, Andrew, Andrew Clifford? Yeah, my background is in mainframe systems. investment banking, writing financial accounting systems and trading applications. And I actually left that in 2010 to become a writer. And it was about two years later, late 2012 that I heard about Bitcoin. And I realized pretty quickly what a breakthrough it was and the benefit to the world economy that could accrue from sound money. and the fact that it was limited to 21 million

and the mechanism to how to achieve that was quite exceptional. So I immediately became immersed in that subject and we're now over four years on and I'm still immersed in Bitcoin hoping that it will succeed and I think it would do a lot of good for the world economy. So Andrew, what did that immersion look like?

Did you, in what ways were you involved? Well, first off, when I heard about it, I joined Bitcoin Talk and started to contribute there. And it was quite a healthy community. And in fact, it was quite ironic because one of my first posts was about the block size. And I said, this isn't enough to succeed long term. It needs to be increased. That was over four years ago now. And I've been banging on about that like every few weeks ever since.

And there was real momentum to solve it in 2013. Well, the idea for making millions of bitcoins as in bits, someone came up with that idea, but that rather largely got publicised through my efforts. I initiated the discussion on Bitcoin Talk and got it, well, it became implemented in a number of wallet applications and it's in common usage. And also the XPT ISO code, I realize that that's important for integrating into mainstream financial systems. So I push that and that has become quite popular as well as a result. So it's really these facets of Bitcoin to help it succeed in the world economy,

the things that I've tried to push. And then when Andrew Stone came up with the idea of Bitcoin Unlimited in late 2015, again, I could see that it's the best approach to solve these scaling issues. So I've been spending quite a few hours a week. involved in helping make that succeed sense. Cool. So, Zirk,

you, so you also discovered Bitcoin in 2012. What did your journey look like in, in the Bitcoin space? And how did you then end up starting Bitcoin Unlimited? You know, I guess the beginning of my journey was trying to convince some Chinese manufacturers to accept it, actually.

I mean, the fact was that I was able to, get a prototype, physically get a prototype fabricated and mailed to me faster than I could move the money to China, right? It took more time to do the Western Union transfer than it took for them to fabricate the part and send it over. So I was saying to myself, if only the money could be moved instantly, I would cut, you know, the turnaround time, which is very important in half, right? So from there, I made some investments, but I didn't want to, and I also did a quick code review and so forth, but I didn't want to jump in to do development for essentially redundancy reasons. You know, because if you put all your, you know, I had done investment in Bitcoin, so it's better to then be pulling a salary from, you know, a separate endeavor in case Bitcoin fails.

But coming around in 2015, I realized that the promise of Bitcoin as a peer-to-peer payment system worldwide, which is really, well, I both feel like that is the fundamental basis of its use as store value is the fact that it can be used as a peer-to-peer payment system. And also because I feel like that's where it will really affect the world. And when that promise started to fail, I felt like I needed to, you know, become more active in the space. And so coming out of this, I had been, you know, participating a lot in this gold-collapsing Bitcoin Up forum. And a lot of the guys there had similar ideas. And so the idea of Bitcoin Unlimited really came from, you know, a lot of the conversations happening in that group. We talked briefly before that, you know,

Bitcoin Unlimited has been around for a while since 2015. But I think it was after Bitcoin X-C. So would you mind just running us a little bit through the history of, you know, where in that sequence of different clients, Bitcoin Unlimited came, and what sort of happened with the other ones in that course as well? And why you guys felt like the right thing was to do, was Bitcoin Unlimited as opposed to supporting, you know, XT or some other approach that existed? Yeah, so that's a good question. And it did come after Bitcoin XT. And I actually began by contributing to Bitcoin

XT. I did the traffic shaping in XT. But, you know, XT was still XT was proposing, if I remember, some kind of compromise solution.

And also, it was, I think Mike Hearn was leaving at approximately the top, like I think he sort of left, so there was a question about whether Bitcoin XT was going to continue, right? And that was when on the Bitcoin, you know, gold collapsing Bitcoin up for them, we really started

reconsidering exactly what these limits should be. And someone proposed that, you know, that these non-money-protecting functions really should not be consensus parameters. And that is really like a fundamental. philosophical difference from, I think, Bitcoin XD. And that's why Bitcoin Unlimited kind of emerged. And then Bitcoin Classic came a few months later, if I remember correctly, and it came out of some work by the Tumen Brothers,

suggesting that the Great Firewall of China could really accept, I think it was like four megabyte blocks. And so Bitcoin Classic, I think, originally emerged to propose a compromise at like two or four megabytes. I think they eventually settled on too. So this is going to be like one of the main things that we'll focus on is the fundamental difference in approach that Bitcoin Unlimited has, where these are be something like XT and Classic, which are, as I understand, like both creating the clients for and campaigning for block size increases from one mb to some higher value they might be different for different clients but bitcoin unlimited has a completely

different approach where the the block size limit would be removed as a core consensus parameter itself so we'll get into this topic um but before before we jump there i would like to quickly ask one question is, so we have all of these different clients, all of these different approaches to block size increases. Why is it that you think that all of the Bitcoin users, companies and people that are pro-block size increased, why have all of them not kind of converged to support just one client? Why are there, why is the pro-block size increase community like fractured into all of these clients today. If I could take that real quickly, I would say it's one of the reasons is because if you get

seven developers in a room, you end up with ten opinions, right? There are a huge number of proposals, right? And honestly, you know, one of them is barely better than another, you know, in many regards. And a lot of people seem to think that their approach is best. And Bitcoin Unlimited, to some degree, came out of that observation in the sense that it says, you know, that we should let the future us decide the block size and not come up with some top-down proposal that we're all going to follow no matter what or have another block size debate. So it was in one sense of reaction to all the proposals. and it's sort of ultimately then kind of the ultimate proposal, right, being based on, you know, Nakamoto consensus and not yet another algorithm that developers have decided on and are pushing everyone to use. So Bitcoin Unlimited, when people hear the term Bitcoin Unlimited, you know, one imagines, and we did the same thing.

like okay now anybody can create you know a block a block of any size so you know sort of all all limits are off can you run us through first of all what what where's that name from like what what does the unlimited mean in that context and what does it mean in terms of block size does it really mean a minor could now you know bit fury could create a 30 megabyte block and propagate that Right, so unlimited does not mean infinite, right? It simply means that there aren't limits. Or in particular, the market will pick a limit, right? The code does not create the limit, right?

So that's what is meant by Bitcoin Unlimited. And there's also a strong sort of, it's also like refers to a strong philosophy of more like unlimited choice. Okay. And in terms of the age-old question, will a miner create a gigantic block, right? There are forces, you know, in the network that naturally reduce the likelihood that that will happen. And in fact, honestly, that question is actually irrelevant

in the face of the X-Thin work that Peter Shipper did because the time to transmit a block is, is negligible now. The question is really the transaction throughput time. Like how many transactions per second can you ultimately have? And what I'm trying to say by that is if someone produced a huge block, then the chances are very good that subsequently you would have a spate of zero length blocks and the average block size would ultimately then come down to the average that the network can

can handle. And we kind of, in my work on empty blocks, I kind of showed that effect happening both empirically by looking at the rate of zero length blocks and how they depend on the size of the prior block. And then I also kind of showed it theoretically. Let's take a break to talk about the Ledger NanoS, the new flagship hardware wallet by Ledger. I'll pass it over to the Ledger's CTO, Nikola Baca, who can tell you all about Ledger's security features and SDK. So, Ledger NanoS is a personal security device based on a secure element, a screen and button, so that you can verify everything that is done on device and make sure that you are really doing what you wanted to do. Compared to our previous solutions, this device is based on the latest generation secure element, the ST-31 from ST-Micero.

The SC-31 is using a secure arm core, which means that you can have the same, ease of development that you would have on a generic microcontroller but benefit from the security features of a secure element. Security features include an application firewall at the lowest level that let you protect applications from each other, which means that you can load multiple applications on the hardware wallet, even post-issurance, and you as a developer will be able to leverage these features to load your own application without our authorization and without any kind of authorization from the vendor. We will be providing this device with an open SDK that let you do anything you want with this device. We provide sample applications for cryptocurrencies, different cryptocurrencies, so Bitcoin, Ethereum. We will also provide a Fido Authenticator and you will be free to add everything you like.

For example, you could have some secure messaging, some encrypted chat, and you'll see that the solution is quite powerful and very easy to develop with. sets the new standard in hardware wallet security and usability. You can get yours today at ledgerwallat.com. And when you do, be sure to use the offer code Epicenter to get 10% off your first order. We'd like to thank Ledger for their support of Epicenter. You mentioned X thin and with that the block says doesn't really matter. Can you expand on that? A two terabyte hard disk costs like $50, right?

and so you will be able to store the entire block chain in your life. And also, really, very few people really do need to store the entire block size as well. I understand that there might be a small security issue and someone could artificially create, if you stored, let's say, the past year of blocks, someone could painstakingly generate a gigantic fake tree that would give them a lot of money, but this is incredible, this is like, you know, can you imagine the processing power that would be required to do that, right? This is a very, very theoretical, you know, like effects. So in reality, even if Moore's law on disks don't exceed the size of, you know, blocks being submitted to disks, you can just enable pruning, right? Which is a feature that

core itself, you know, actually implemented. So I think that they, you know, sort of recognize this reality as well. So the issue is not dis-space, right? The issue is really network communications. And in that case, before X-Thin, it used to be that when a block was transmitted, the entire one-megabyte block had to be transmitted,

and that created a certain latency through the network, right? But post-X-thin, what's happening is all of the transactions are probably already dispersed throughout the network. So the block simply says, oh, yes, and that transaction that you already have, and this one and this one, and this one, it just kind of identifies them, right? So the size of the block is actually really small, referring to existing transactions. And what's actually really interesting about this is that what would happen if you don't have those transactions?

The answer is you have to go and get them, right? And that does take time. So another way of saying that is if the network's capability, like if the capacity of the network is such that it can't push the transactions fast enough to get to you before the block does, then the latency that it takes you to process the block increases, which means from the miners perspective that they're more likely to create empty blocks. and so the average block size will fall.

Okay, that's very interesting. So basically, before, right? It's kind of thick, right? It's kind of detailed. Yeah, no, but I think that's a super interesting thing I was actually not aware of. I think I maybe saw X-Thin mentioned before, but I wasn't fully up to date.

So basically what you're saying, right, is that in the past, I is a minor, would aggregate all these transactions stuff them in a block, mine a block, and then I would send out that, you know, one megabyte or something around. And, you know, it takes somebody, however long it takes them to get that block. And when they have it, they can start mining on that thing. Right. But with X, then, because the transactions are already being propagated in the network,

and there are in the mempool of all these different notes, I can just say, I've mined a block, you know, here it is. And Meher says, okay, I already have, you know, maybe 95% of those transactions or 98%. So I just need to get those remaining ones and then I already have to block. And if I just sort of tell Mejer what to include there, that's much smaller and propagates much faster. There's a bit that he hasn't said yes. X-Thunds even better than that. it will predict the ones that you're missing and send those with the abbreviated block. And in fact, a recent log report showed that there were no missing transactions in an entire day for a node.

And it predicts which ones are missing by sharing a blue. So hundreds, if not thousands of blocks, go through without a single missed transaction in today's level of, use because the network capacity far exceeds worldwide, you know, our current use of it. Okay, that's, this is amazing. Yeah, so it's kind of the proof, right? The fact that that no transactions have been missing from X-Thin blocks for a long time. Yep. And then X-Thin is the standard, are all blocks X-Thin at the moment?

only B-B-U and X-T and Classic are all using it. Can you explain what X-Tin is briefly? Is it a protocol? What is it? Who uses it? So it's a protocol. And so just you guys might all have an aha moment when I say that after X-Thin came out, core implemented compact blocks, which is sort of almost exactly the same.

I think that they don't do this transaction prediction, so they have slightly higher retry rates. But I think theirs are more in the 95, 98%. I haven't tested it myself. This is just what I hear. So do you guys know what compact blocks is? No. Okay. So the idea is instead of including, this is not rocket science.

Instead of including the full transaction in a block, you simply include the transaction. transactions hash, right? It's SHA-256, right? But then you can observe that with relatively few transactions, say millions, right, running around the system, you don't really need a 256-bit identifier. So you could just chop that a little bit and only send like the first 64 bits or whatever,

first 128 bits. And so you can gain additional compression by sending a partial Shaw-256. instead of the transaction itself. And then on the other side, the block is reconstructed on the receiving side. And of course, if there was a Shaw-256, or a Shaw 64 collision and you put the wrong transaction

in the block, then ultimately the block's signature, the block's hash wouldn't match. And so there's no chance that you're going to I mean, the chance of you constructing an incorrect block is the same as the chance of two people creating a Bitcoin wallet with the same address in it, right? Almost impossible. So why did Core not also adopt X-Thain? Why did they go with some other thing called compact blocks? I think that this goes into political and personal reasons, which only Corps themselves can know.

I think there's a huge amount of not invented here attitude in Corps, and I think they see Bitcoin unlimited as a threat to their business model. And so it would be bad to suggest that a single advantage. I'll give you an example. When I first, I didn't write X-Thin, but I put the announcement out on Reddit in the R-Bitcoin users group, and it got like 150, 200 of votes. It was right at the very top. And then I edited the original post and I said, you know, this work was done under Bitcoin Unlimited.

And the posting was removed within five minutes. So I do think this is like a political thing. But what it effectively means is like for. Correct me if I'm wrong, but there have been like lots of research papers that have investigated the economic behavior of minors, always assuming that it takes time for a block to go from one minor to another minor. And based around this, a lot of strategies like, you know, selfish mining, network analyses have been done. And I'm pretty sure there are like 25 to 30 academic papers that do this. But what you're saying is something like X-Thin basically changes the dynamic completely,

that it takes very little time for the blocks to be transmitted between the miners, and it effectively removes the need for a 1MB cap. Yes, absolutely. I mean, particularly the time to transmit a block is no longer proportional to the block. block size, really, right? Or it's proportional to a factor divided by thousands, right? So it's essentially a constant size, given today's networking capabilities. But that all does presume that the transactions are fully propagated, right?

So where we get to an interesting case is in a theoretical case where we're far above, probably far above 10 megabyte block sizes, right, where the transactions aren't fully propagated. And what's really interesting about that is then what happens is that because a minor hasn't fully propagated the block, because the receiving minor hasn't fully validated the block, he has to produce zero-length blocks, right? Which a lot of people think are evil, but I think they came to that conclusion without really thinking about it. Because what a zero-length block in this case says is the full transaction set wasn't propagated to me, so I need to slow down the processing of the Bitcoin network, right? And this is how like a small miner is no longer

penalized by these sort of issues, because he can simply produce zero length blocks. And, you know, his essentially hash, he's essentially doing a hash power weighted vote saying, I think that the network should handle fewer transactions, right? And that will, you know, in the end, create a fee market, right? Just like, you know, Peter Reisen's paper was suggesting that block propagation time will create fee market. But that fee market will be naturally, will naturally come about due to the limitations of the Bitcoin network itself. It won't arbitrarily chosen at one megabyte, right? And because of that, you can't really imagine that an altcoin will outperform it, because it's performing at the limits of the global network.

So anyway, that's like the fundamental philosophy behind Bitcoin Unlimited, right? And why we believe you can have block sizes that the developers do not limit. Okay, that's super interesting. Now, just to have a clear picture of this. Now, with X-Thin blocks, how much space does a, you know, one-megabyte X-thin block take up? And what about, you know, an 8-10-meabide block? Andrew, do you remember what the compression rate was?

I think in the bullpark of 50 to 1, so 20KB, including the Bloom photo. Yeah. Wow, this is quite mind-blowing because Genuinely mind-blowing. Why? Yeah, why on earth? There's no reason. There's no real reason. By the way, we've done tests on the propagation rate from like China through the Great Firewall China right out to America and like London. And these rates were, you know, in like the tens to hundreds of milliseconds.

They were just a bit above the speed of light because it's a great advantage. When you're propagating small blocks, the China firewall can often let them through. For some reason, we just kind of empirically run tests and then try and figure out what's going on with the great firewall China. but it seems to drop packets and connections, you know, proportionally to the bandwidth, right? So if you just pop 20K through once every 10 minutes, it's more likely to let that go through. So, okay, just to test my understanding. So assume I'm like this small, minor, let's say, in Iceland, right? And before X-10, when a block was generated, one MB of data needed to,

come to me with the block and then I would start building on it. I would validate that block and start building on it. Yeah, in the worst case too, sorry to interrupt, is that you have to remember that every hop in the Bitcoin network would fully validate that block, you know, receive it, validate it fully, test all the signatures and send it on, right? Yeah. So that's important too. But go on. Yeah. So now with X-10, the normal operating case is that I will already have heard of all of the transactions that are going to be put into the block and I just need to know the, let's say, the transaction numbers. So that is very, very little data, right?

So that is around 20 kb. And out here, like, if I heard all of the transactions before the block was made and then I can just do with receiving 20 or 30 kb of data and that's it. Here the risk is that some adversary might spin up a lot of nodes in the network and manipulate the network in a way that me, the small miner in Iceland, does not receive all of the transactions. My transaction mempool is not updated because some adversary is gaming the network that I don't receive my transactions, right? That is the risk. A civil attack. Yes, the civil attack is the risk, right?

So because of this risk, now the question becomes what would I do if that sort of thing were to happen? So what you're saying is if that sort of thing were to happen, as long as the network would ensure that that 20 or 30kb of data about the new block reaches me, there might be a chance that I know the header of the new block, but I cannot validate all of the transactions in it. But just knowing the header, I could start building the next block. assuming that this 20 or 30 kilobyte header is correct yes that's not quite the way it happens in the network today but that could definitely occur okay so the way it happens in the network today is that all of the miners have registered as minors in all the other minor networks and so but they're not actually mining with any hashp in the other mining pools networks. But what happens is that a miner sends a block update out to all of its, you know, minors, right? And the competitive miner receives that block update.

And so then it gets the, you know, the header and it can start mining zero, you know, an empty block until it receives the full block. it's just a small detail but the end result is exactly the same and you are right that if you didn't do that if you didn't have this validation list mining it's called going on then

you would fall back to exactly what you're talking about I think Gavin first created a patch actually to do that it's called headers first mining or something like that Today's magic word is unlimited. That's UNL-I-M-I-T-E.

Head over to let's talkbidcom to sign in, enter the magic word, and claim your part of the listener reward. What is your estimate? What kind of block sizes do you think the network could support today? I don't think that. that supposition about that is really all that helpful, right? I think that they're much higher than they are today. I think a better way is to turn that round and say what block size is the demand out there for a legitimate demand. And that might be one and a half megabytes at the moment. And then

we can look at the historical growth rate in transactions because before blocks got full, they went for when there was an up trend in the size of them. And we can predict that forward and we can get an idea of what the block size should be based on historical trends. And it's a number to know. Obviously you can't predict the future, but it's better to have some information than nothing. And I think that should be the ballpark of where we say blocks should be is based on the historical

trend prior to them being full. And the network can definitely handle that with the. X-then and the compact block propagation methods. One thing to add is that we still don't have very fast block propagation for re-syncing a node. So when a node is offline and needs a thousand blocks, they still have to be sent full size. But in the normal course of events,

nodes should have quite a bit of long periods of uptime, and that's not a major consideration. Cool. Well, let's talk a little bit about Bitcoin Unlimited as an organization. Is it a nonprofit currently, or did you guys have a formal organization that's kind of behind the project? I can give you some background on that. The organization was unincorporated, has articles, and they're on our website,

Bitcoinunlimited.com. info and it had in there the provision to become a registered non-profit and that's what we did back in August last year so it is a registered non-profit but as we're still in the nascent stage we're not really doing a lot with a non-profit but we're building the organization and it has about 50 members at the moment. And that would lead into the question of how people become a member. And the way that is done is that we have a forum, which is the Bitco.in forum, where we can have censorship-free discussion, and that's been the home for BU.

And people are welcome to join that, and if they support BU, they're welcome to apply for membership. and membership is free. People have to evidence an online history, such as on Reddit or Twitter or Bitcoin talk, showing a medium, showing a history of positive writings about Bitcoin doesn't have to agree exactly with what Bitcoin Unlimited says. You just want to make sure you're not a sock puppet, right?

Some history. Yeah, some history is a real person. And then the membership will decide, the existing membership decides on the admission of new members, which is the best way to maintain the integrity of an organisation. So you would have a vote, a regular vote, and new people want to become members? We do. Every couple of months, we have a vote,

and we induct a number of new members. Not a huge number, but it's growing. And that's good. How many members did we induct, Andrew, the last time? We had a vote like a week ago. Yeah, January the 1st was our last vote that finished, and we had eight new members join then, all with good track records of writing about Bitcoin

and interest in the space, investors, developers. So we've got some very good people in the membership. now. Are you guys trying to be exclusive with that or have a certain high standard or what's through it? Because 50 seems like a very, very low number given also the recognition that Bitcoin Unlimited tasks. So are you guys intentionally trying to keep that fairly limited?

Which would be slightly ironic, I mean. No, we don't want to limit. I mean, we should be great. You know, everyone who wanted Bitcoin to succeed. could become a member, but obviously there's a lot of different opinions in the Bitcoin space. And some people have opinions which are so strong and so divergent from the ethos of Bitcoin Unlimited that they probably wouldn't make a good member. But that is up to our members to decide.

So we welcome all applications and the members normally accept, you know, the vast majority of applications, but some will get rejected. And that's how the organization maintains its integrity. I'd say for potential members, it's important to understand that you don't want to become a member just because it's cool or whatever. The job of the members is to vote on the proposals. And these proposals will ultimately, you know, resists. result in changes to the Bitcoin client, right? So you have to be willing to put in a few hours,

you know, preferably a lot of time understanding, you know, the Bitcoin environment in general, right? But then a few hours really studying the proposals and talking about them. And, you know, if you're for large blocks, but you don't have the time to help steer Bitcoin Unlimited, then membership is probably not for you, right? But if you want to actively shape what the Bitcoin Unlimited Client is going to be, then, you know, we want you. And those proposals would be on what kind of basis are you talking about?

So a few hours on a weekly basis? I think we tend to have votes like once a quarter or once a month. It would really depend on how many proposals are presented. and any member is allowed to present a proposal or they can sort of sponsor a proposal presented by a non-member. Okay, so somebody who's knowledge above Bitcoin and has a, you know, I would probably a decent technical understanding

and is willing to spare a few hours per quarter evaluating different proposals for Bitcoin Unlimited, it would be suitable for a membership. Absolutely. Okay, very interesting. Well, I mean, we'll definitely post a link. So if people are interested in joining as members, they'll know nowhere to go.

I think that sounds quite interesting. Also, perhaps as a way to just be a bit more engaged with it, you know, whatever one's opinion. Actually, I find that I think that would be very interesting to see what the developments are. Moving on the next thing, One of one thing that stands out about Bitcoin Unlimited is that you guys have articles of Federation. Why did you choose to do that?

And what are some of the main ideas in those articles? I wrote the articles or pulled the articles together from, you know, a lot of writings of other people. So I'll begin with why I did that before writing. a single line of code and then maybe Andrew can talk a little bit more about it from a you know from the president's perspective but I started by writing the articles because um I felt like the there was no process in the in the method that was um occurring in Bitcoin core it seemed like there was a lot of talk about consensus but it seemed like consensus was actually defined by when one of the leaders said there was consensus,

there was no quantitative way of measuring consensus. And it seems even that proposals would not even be allowed to exist even. They wouldn't get a BIP number, for example, unless they adhere to certain people's opinion as to the way these things should work. And so it seemed like there was a veneer of process, but the truth was it was like a veiled dictatorship. And I didn't feel like I felt like many voices were being ignored and crushed through that process.

So I didn't want Bitcoin Unlimited to be like that. It was never my intention. And in fact, one of my own BYU proposals was recently not passed to kind of prove that Bitcoin Unlimited it is not a dictatorship by me, right? So just to continue a little bit further, the articles that we have are trying to create a new model of a democratic development where we really do try and get a feel for what the ecosystem needs

from Bitcoin and produce software, which delivers that. And the BU members are a proxy for the wider Bitcoin community. and therefore when they vote on a software change and one of the software changes that was rejected early on was that RBF replaced by fee and one reason is the damage that it does to the zero confirmation business which was working really well for Bitcoin

prior to blocks being full and in fact the zero comp is an entry point for new users to Bitcoin that often and the first experience that people will have is buying a beer with Bitcoin. It used to be, but it probably isn't any longer. And who knows, someone who buys a beer with Bitcoin may suddenly understand this is wonderful, and becomes a major player and runs up 100 nodes or whatever. You know, these people are not joining Bitcoin now

because the entry barrier for joining is higher because zero-comf transactions are not happening. So RBF was rejected by our membership. And this is the democratic aspect of development and action. And we think that we are mirroring what the ecosystem wants and needs more than any other implementation. Let's take a short break to talk about Jax. Jacks is a multi-coin wallet created by the people at DeCentral. Now in the past, if he had a whole bunch of cryptocurrencies, it was a pain. handle them. You either had to leave them on an exchange, which was insecure, or you had to have all

these different wallets, which was a hassle. Fortunately, now with Jacks, those medieval days of darkness, misery, and suffering are over. Jack supports multiple cryptocurrencies and new ones are being added. But it's not just storing cryptocurrencies you can do with Jacks, but you can also exchange them directly from within side the wallet thanks to their shape-shift integration. And since there's only one seed, Jax makes it super easy to back up and sync to your other devices. Jaxx works with Windows, MacOS, Linux, Android, iOS, and has browser extensions for Firefox and Chrome. So go to jacks.io, that's J-A-A-DoubleX.I-O, to download the wallet and get started today. We'd like to thank Jax for the supportive Epicenter.

Bitcoin Unlimited has been around since 2015. What's the status right now? What percentage of the miners are supporting Bitcoin Unlimited or of the nodes? And what kind of threshold do you think is necessary to reach until Bitcoin Unlimited actually gets activated and bigger blocks get created? Yes. At the moment, the mining percentage is about 15%, which is quite a healthy percentage of the mining. and of the full nodes, about 7%, 8%, is the peak that it's reached. These percentages do need to be higher before we will see larger blocks. But I want to actually just go back, go to another aspect of Bitcoin Unlimited,

which is that we don't want to replace Core with Bitcoin Unlimited. We want a new environment where there will be multiple, implementations, decentralized development. So the model we would like to see is that all developed implementations have less than 50% of the nodes and 50% of the mining power. And that provides lots of checks and balances in the development as well. It makes Bitcoin stronger with the decentralized development. So though we may see Bitcoin unlimited,

we don't know whether it will happen or not, go above 50% and we get bigger blocks activated, the long-term goal would be to go back below 50% again and see a landscape of competing implementations and we get Darwinian natural selection, the benefits of it. That's the vision, the longer-term vision. So let's say in the future, the block size does end up going in the path you think you want it to go,

which is unlimited block size set by the natural dynamics of the network, right? What would a transition from the current regime of 1MB blocks to a regime of blocks set by the network look like? How would that transition happen? What Bitcoin Unlimited is doing is giving quite a bit of control to the miners about block sizes they'll create, which is really the only way that it can work. The miners have all the skin in the game with the financial investment in the SHA 256 HASHE power. So they will look at what happens if we don't

know whether it will happen, but if at the BU mining percentage gets up in the region, of 70 to 75%. They'll be looking at triggering a hard fork. So we'll lies with them and probably announce a flag date a month out and agree with the miners that greater than 1MB blocks will be produced after that date. And hopefully a lot of the other full nodes on the network will upgrade. And even the core ones can remain core. All they need to do is that. has changed that number to be instead of one up it to six or eight or something, depending on what people want. Or it could use our patch for Emergent Consensus,

which would be a relatively small patch that we can give decor around that time. They can use it if they want. And at that point, the miners can then create a larger block. We would expect that the other 25% of the miners would see the writing on the wall, and most of them would switch it. that point so there should be 95% mining power by the time the flag date is seen. Now if nothing happens ahead of the flag date then of course that could be cancelled and but it should function in a manner like that and be quite a smooth process.

Right now you said Bitcoin Unlimited was a 16%. I think the segregated witness share is around 25% And segregated witness has a 95% accuracy threshold, I think. And of course, segregated witness is the proposal and the favorite way to achieve scalability or indirectly achieve scalability to provide a Bitcoin core team. So, you know, it seems like both are very far from breaking through. I was wondering, why doesn't Bitcoin Unlimited not do the Unlimited, way of managing the blog size and also add segregated witness in there because I could imagine if one could sort of combine those forces of support might be much

more likely that hard fork would go through. How do you guys look on that? I think that that's actually a fairly interesting proposal. I haven't looked at the code line by line but from a structural standpoint it's not my favorite solution. for a variety of reasons that basically are summed up with the word technical debt. And what that basically means is you create a lot of problems for people working on the code in the future, right? For example, you know, you're creating a transaction, right? And it's actually completely valid. But let's say it's not a segregated witness transaction because you screwed up the witness section of it.

But it's going to be, it's going to look completely valid for the old rule. Right. And so now God knows what's going to happen to that transaction, right, if it's improperly formatted. A similar example, actually, we have today of this same sort of design problem is the fact that every once in a while somebody accidentally creates a transaction with a gigantic miners fee, right? Because in, you know, today's transactions, you don't explicitly say how many bitcoins you're giving to the miners. It's just, If you add up all the inputs, you know, and then you add up all the outputs, then the miners get the difference, right? Every once in a while, someone will make a big mistake and they'll accidentally send the miners a couple hundred bitcoins, right? So this is the sort of thing that creates technical debt, right? And it's much better to create a simple transaction format where it's very hard to mess it up, basically. So I haven't heard a word from core about a compromise. And it actually begs the question,

if we're going to do a hard fork anyway, then why should we do a segregated witness soft fork, right? Let's take that technology and make it into a hard fork, right? And I haven't heard any proposals from them about that, right? And actually, that same observation does make a lot of the large blockers wonder at the promise of core to increase the block size down the road, right? Why have a soft fork now if you're planning to ever increase the block size in the future, which I think, you know, was promised? Because you get the worst of both worlds, right? You incur the technical debt of a soft fork,

and yet you're still having a hard fork. But I would, you know, I would bring something like that to the membership and see what they say, and that would start me. actually analyzing the segregated witness code for its, you know, quality and completeness? I will just add that we do actually have a Buwip for us, a hard, hard for Segwit amendment. And that's in our list of billups that have not yet been readied for voting upon. Yeah, I mean, I could imagine that this would at least maybe get some people over into the can, right I mean there's certainly also a whole set of startups you know from lightning network and or side chains or R Ski or a whole set of startups right

that want something like segregated witness and and you know whatever their position would be on on the box size so they might they might be sort of you know coming to into the bit kind of unlimited camp if if support was for that. Yeah, it's interesting, and that's why we consider it. A lot of those tech, like Bitcoin Unlimited is not against Lightning at all, right? We're essentially for Lightning and would like to let it, I mean, I think Lightning has, you know, some really interesting use cases, right?

I'm not sure if scalability is one of them because as people have pointed out, it scales the number of transactions that a particular user can make, but it doesn't really scale the number of users, right? But there's lots of great use cases for it. I don't think that segregated witness is the only path to getting to lightning at all, right? And we have several proposals down, you know, as Andrew was saying, that I think lightning can be built upon, right? Because basically, in order to implement lightning, you've got to clean up a couple of mistakes that, you know, exist the current transaction format. Let's still assume, though, that no compromise happens.

We are stuck at this place where there's a significant minority that wants to go in different directions, one of them unlimited, one of them segues, maybe some other ones. And, you know, a year from now, we're at the same point, or a year and a half from now we're at the same point. It's just there's no progress there. it seems at some point, right, the best solution might be or one solution might be. I don't know if you guys think it would be the best solution in a situation like that is to have something like we had in Ethereum, right, where you have Ethereum Classic,

Ethereum, the regular Ethereum, and there's a split, even if there's not an overwhelming majority. Do you guys think at some point that could be the best solution? I think this would be something that would have to go to the BU. Well it would be a B-UIP about anything that would create a permanent fork. What you're talking about is say a minority fork. That's off the table at the moment as far as we're concerned. We still think that a hard fork can happen. We're relatively early days in the process and Andrew Stone can tell you about our new

release, which is due out imminently, and that should generate quite a bit of interest and excitement. So we really are hoping not to be where we are here in a year's time. So that is quite hypothetical. A lot of things will happen before then. It's important to remember that Bitcoin Unlimited always follows the hash power majority, to the extent that we can code that. That's what we mean by emerging consensus. Unless the monetary property, unless like a transaction were to,

or a block where to undermine the monetary properties of Bitcoin, so, you know, we will stick with the hash power of majority, regardless of what, you know, that is. So to create this fork that you're talking about would, you know, be, changes to both the philosophy. It'd be almost a different project, maybe built on top of BU, because it would change both code changes

and philosophical changes. Personally, as early as I think 2013, I was commenting that I thought that there was maybe room for three coins in this world. One was an app, like Ethereum style, actually four coins, an anonymous coin, store of value, like Bitcoin and then a micro-transaction coin, right? And that would presume, now the question is,

the value of a store-of-value coin can be undermined if this micro-coin can do the job just as well, right? And with, you know, reasonable block size increases, at this point, you know, Bitcoin can be both this, you know, small transaction coin. and a store of value coin. So I don't see right now, you know, this fork to be imminent. Yeah, it's certainly not imminent. It's just, there's always, there's just a question whether it will be possible to come to some kind of agreement. And I think what's also interesting, right, we've done many episodes with sort of new blockchain proposals, right?

New blockchain networks. And one of the topics that we see coming up again and again and again and that everybody's thinking about is how do you have some governance on chain that you can resolve questions like this. And so that one doesn't have a situation where, you know, there's differing opinions about where the protocol should go and there's just no real way of resolving it. So if it doesn't happen, right, this may come up. Yeah, combining the governance with the blockchain is like a fascinating concept, but it's certainly beyond the scope of Bitcoin Unlimited. Yes. And really, there's only one thing wrong with Bitcoin, and that is the block size.

The rest of it just requires optimizations and improvements. There's nothing fundamentally wrong that would probably require blockchain governance to fix. Yeah, that's an excellent point. Yeah, I mean, I think for Bitcoin, it's not feasible. I think one probably has to program that in from the very start. And there's certainly pros and cons to both, right, having an indirect governance mechanism in Bitcoin where essentially are choosing by choosing the client or by the hash rate is also a way of doing it. This is it because the network is a balance between the miners and the non-mining force.

nodes and this is a major difference with our emergent consensus proposal in the the BIP 100 initiated by Jeff Garzik which was purely a minor voting proposal with our emergent consensus the miners will experience pushback from the full nodes beyond a certain level where the miners are creating blocks which are damaging to the network financially So that is a governance mechanism within the emerging consensus so that the ecosystem as a whole has influence on the block sizes just beyond the rate of transactions coming in. Cool. Well, we're at the end of our episode, but Andrew and Zirk, thanks so much for coming on.

It was extremely interesting learning about your work in Bitcoin Unlimited. Thank you. Thank you very much. And of course, we'll have links to the resources, the Bitcoin Unlimited websites. There is some papers as well. Zerg mentioned the one he wrote, that there's another one about transaction fee, transaction fee market, and a whole bunch of other information there. And we'll also be linking to the place for those who want to get involved in the project to become member,

that they can let them know of their interest and prove that they are in the... human being and not an account commanded by the forces of enemy or an evil. And yeah, with that, we are at the end of our show. So thanks so much for a listener for listening. We will be back next week. And you can, of course, find this show and many other shows on Let's Talk Quickone.com. And if you want to support the show, then please leave us an iTunes review that helps new people find the show. We appreciate that very much.

So thanks so much. I'm looking forward to being back next week. Thank you.