WBD357 Audio Transcription

Bitcoin Tech #5 - Bitcoin Consensus with Shinobi

Interview date: Monday 7th June

Note: the following is a transcription of my interview with Shinobi. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.

In this interview, I talk to Shinobi, the host of Block Digest. We discuss making changes to the Bitcoin protocol, hard vs soft forks, ossification, and the upcoming Taproot soft fork means for Bitcoin.

“I cannot stress this enough; when you are trying to gauge consensus for an upgrade proposal, it is not a democracy. Absolutely not. It is not voting; it is not majority wins. That is not how things are done.”

— Shinobi

Interview Transcription

Peter McCormack: Good morning, Shinobi, how is the hangover?

Shinobi: It's a decent one today, it's noticeable but not quite incapacitating, and we'll see how it goes.

Peter McCormack: Perhaps we'll build a hangover together in -- can we talk about you being in Miami, I had to think about that?

Shinobi: Yeah.

Peter McCormack: Yeah, you're going to be in Miami secretly hiding with your secret disguise, but I'm going to find you; we're going to have a beer.

Shinobi: We're going to have many beers.

Peter McCormack: Many beers, many beers, well not as many as you normally have because I've got to work, you're just there holidaying it and sunning yourself; I've actually got to work.  Anyway, listen, it's been a wild week, people are going to expect me to ask you about some of this stuff, but I really want to focus on today's show.

Shinobi: That's it, I quit Peter, I refuse to do this.

Peter McCormack: You quit.  No, I want to focus on today's show, because as you rightly said, the stuff we're talking about is -- today is consensus changes.  This is a very important subject for people who are wanting to understand about Bitcoin tech, and we will cover some of the stuff, the other stuff towards the end of the show, because there is some historical stuff that I just want you to run through, because you'll do a better job than me.  I mean I just want it for me, but we'll cover that at the end.

We're doing consensus changes today, this was your choice, this was your decision and I think it's a good natural progression from the other shows we've been doing, which as you know have been very popular.  Why was it important for you to cover consensus changes?  I've got three questions: what are consensus changes?  And, does everybody -- like do all bitcoiners really need to know this?

Shinobi: Well, obviously a big part of the reason why is the thing we can't talk about until the end of this show going on right now, but I just thought given the fact that we are currently activating a new feature, this would be a really important thing to get into.

Then two, really, it's just adding rules; I mean traditionally there are two ways, we'll get deep into the meat of this later in the show, to kind of change the rules.  You can either expand them and allow something that was not allowed before, which would be a hard fork; or you can restrict them and kind of stop allowing something that was allowed before and that's a soft fork.  So, you can kind of go in two different directions and make the rules more restrictive or less restrictive, but the general idea with rules is, I can lock my coins so that only my key will move them. 

Let's say, I don't know, we want some feature that will let you spend those coins as long as you put any even number in the transaction.  I don't know why on earth we'd want to do something silly like that, everyone's coins would get stolen if they used it, but we would have to go through a consensus change for that.  We would have to either soft or hard fork that new rule in and get everybody running it, otherwise you don't just spend that with an even number, like you can just spend that with no number, because no one's enforcing the rule.

Peter McCormack: Okay, I think there's going to be some people listening who are already like, "I have no idea, Shinobi, what the hell you are talking about", so I think we have to break this down super --

Shinobi: That was a weak analogy.

Peter McCormack: Super simple, step by step, and I think the starting point to it is to just explain what consensus rules are, why they exist in Bitcoin and how nodes enforce those rules.  Maybe a starting point is just to do a node recap, what a node is and what it does.

Shinobi: The node is the little machine you run that is actually getting blocks in the block chain and checking all the contents to make sure they're following the rules, to make sure that every signature for every transaction is valid; that nobody is stealing coins they don't have the keys to; making sure that the proof of work on the block that comes in is actually valid against the difficulty target; all the little things that make sure no one's breaking the rules of the system.  The only reason all of this works is essentially that everybody's running rules that are compatible together on a separate machine.

The whole idea of the Bitcoin Network is literally just a result that all these people, all on their own, are running a node enforcing these rules that is compatible with everyone else's, and that is the sole single thing that makes the Bitcoin Network, is just the same rules everybody running them.  Where miners come into this picture is just kind of --

Peter McCormack: Let's stick with that for a second, again as you know I'll always keep it super simple, so for people who might have only just gone into Bitcoin, what we're really talking about is the design of the system that allows it to be decentralised, right?

Shinobi: Yeah, everybody is enforcing these rules and checking the blocks that come in against them 100% independently; there's no authority there, you're doing it yourself.

Peter McCormack: Yeah, and I'm going just separate it because there's going to be two types of users that are listening.  Those who are -- most likely those who are listening who aren't operating a node and therefore are using somebody else's without realising it, and those that are operating a node. 

So, those operating a node will understand a bunch of this but there will be people who are buying coins on exchanges or holding on a hardware wallet and not running a node, but they probably don't realise that the only way they can send and receive Bitcoin is because the exchange they're using is running a node; so, by virtue they are using their node.  Similar with a hardware wallet; so again, if they're not running a node, they are relying on somebody else's, but it's the network of nodes which keeps Bitcoin decentralised.

Shinobi: Most importantly the ability for everybody to run one.  If you can't actually spin that node up and run that on your own computer, then you can't partake in that network, you can't verify anything yourself.

Peter McCormack: Bear with me, I mean you can partake in it as long as you somebody else's node, but what we're saying is --

Shinobi: Not as a peer on the network, you know what I mean.

Peter McCormack: Yeah, you're not a peer on the network, you're using somebody else's peer.  I just want to keep to that absolute basics of trying to explain to people that it is the network of nodes, whether you are running one yourself or whether you are using a service which operates a node itself, everybody is sending and receiving because the nodes exist.  To keep the network decentralised and functioning, they all have to be in agreement with each other.

Shinobi: Then where miners come into this, is they're just kind of grabbing transactions people throw at them, putting them in a block and stamping that with proof of work; and they spit that out to the network, it arrives at everybody's nodes and they validate it.  The idea is that's not a valid block if something in that block is an incorrect transaction or broke some rule, then that miner earns no money, because nobody running that node, no business, no exchange or anything will actually accept the coins that that miner mined, because something is in invalid in that block.  So, it makes that block invalid, which makes everything in that block invalid, including what the miner just earned mining.

That's literally -- these two things together, the only reason you have that cohesive Bitcoin Network is everyone runs the same rules and miners follow those rules because if they don't, then they don't earn any money.  That is literally the only thing that holds the Bitcoin Network together, is just people doing these things in a compatible way and that just working out.

Peter McCormack: So, in its most basic form, tell me if I'm correct, but so people can understand is that the Bitcoin Network really, in its more basic form, is the blockchain, the chain of blocks building on top of each other.  It is the miner that goes to create the block, as you said, pulling all the transactions in and once a block is found, it is the nodes that accept it and validate it, and all agree that that is a valid block.

Shinobi: To real quick give an example of just how this holds itself together like this, like Bcash, Bitcoin Cash, is a perfect example of they changed rules, they expanded the block size and made themselves not compatible with the rest of the Bitcoin Network and so that split.  All the miners who chose to go mine on that, are mining on their different blockchain now, that is only accepted by different nodes and that is just entirely because they picked different rules. 

So, when that Bitcoin Cash block first showed up to Bitcoin nodes they went, "No, this is invalid, this is not following our rules", but all the people who upgraded to a Bitcoin Cash node, they saw that block come in and they went, "No, okay.  This is okay.  This fits our rules perfectly", and those two things split off and do their own coin, because people chose, "Okay we want different rules, so we are going to run those different rules", and things split in half.

That can always happen; all the different ways to upgrade consensus rules, the stuff we're going to get into in this show, every single one of them comes with the possibility that you have the chain split into two separate things like that.  Now, that doesn't always mean that it will happen persistently like with Bitcoin Cash, like the chain will split in two and it will stay split in two forever; but no matter what you're doing to try to change consensus rules, there is always the risk that that chain can split in half.  I mean the risk might be less with some ways, might be more with others, but that risk is always going to be there.

Peter McCormack: Okay, so the nodes themselves hold the blockchain, that's how I understand it.  That's the only place they exist, the thousands, maybe tens of thousands of nodes that exist out there all hold a copy of the blockchain.  When the miner mines a block, they create the block for all the nodes to add it to their blockchain and the first things the nodes do when they receive a block is they check whether it follows the rules.  If it breaks any of the rules, that block will be rejected; but if it follows the rules exactly, that will be the new block that's built up on the blockchain and the miners will start mining the next block.  Correct?  Okay great.

We will come to hard forks, because there are different types but if a miner -- and this is where the game theory plays in, right?  A miner will currently earn, what is it, about $240,000 in block reward and they will then earn the mining fees on top.

Shinobi: Peter, this is Bitcoin, it is 6.25 Bitcoin, who cares how many dollars it's worth?

Peter McCormack: No, I know.  They pay their electricity bills probably in dollars not Bitcoin, but just for those understanding is that this is where the game theory is really important.  It is very hard to mine a block because all the miners are competing, but if a miner makes a mistake or tries to cheat the system, that block will be rejected therefore they miss out on the 6.25 Bitcoin which is worth about $240,000 now, and they also miss out on the mining rewards, which I understand to be about 20% on top.  Is that about, correct?

Shinobi: It kind of ebbs and flows based on the fee market, but just a random fact; there actually has been in 2017 a time period where miners earned more in fees than they did in the coin base reward in 2017.

Peter McCormack: So, we separate them, they get the block reward and then they get the transactional fees, which is the fees you and I pay when we send each other Bitcoin.  Anyway, so what happens is once that block is accepted, it's added to the blockchain and then 90 blocks later, as I understand it, that miner receives their pay out.  This is what keeps the network honest, is that the nodes enforce the consensus rules, and the miners have to keep to those rules, and if they break it the block isn't added, and they lose their reward.

Shinobi: Although I do think that the maturation period is 144 blocks, or no 100 I think actually, yeah.

Peter McCormack: I think it's 90.  If I know this and you don't that's going to be amazing.

Shinobi: I'm sticking with 100.

Peter McCormack: I'm going to bet you a night on the beers on this, and I'm checking.

Shinobi: So, I just got free beer.

Peter McCormack: Right, I am going to double check that, but I think you might be right.  Okay, I owe you a night out.

Shinobi: Yes!

Peter McCormack: I'm pretty sure -- I always thought it was 90 blocks.

Shinobi: 1-0-0, sir; how much fiat you're going to be spending on beers for me!

Peter McCormack: Okay, so how is that block broadcast to the network by the miner once they have found it; and how do the nodes distribute that; what actually happens in that process?

Shinobi: They literally just send it to every node connected to them.  Every node on the network is always connected to other nodes and kind of passing back transactions people are relaying, things like that.  The second a miner finds a block, that goes from the actual hardware operator to the mining pool and its node and then that node just spits it out to the rest of the network.  Then as soon as everybody validates that the proof of work is valid and the contents are valid, they just spit that out to the next node and to the next node and to the next node.  Usually, a block will propagate through the whole network in a couple of seconds that way.

Peter McCormack: Okay, so why is it that we have ten-minute block times?

Shinobi: I could be a cheeky smartass and say it has to do with the speed of light limit and the diameter of Earth and then plot a whiteboard and start scribbling funny maths symbols, but it's pretty much just you have to have enough time in order for that to not only get to everybody else but for them to validate it, before the next block comes in. 

It might seem kind of silly to think about it this way, but this is one of the big reasons we have the block size limit, as well as the ten-minute block time interval, because you can construct transactions that are very complicated and take a long time for your computer to verify and you can kind push up to the point of a couple of minutes, that it will take a normal desktop computer to verify a block.

So, imagine if we had like one-minute block times; some malicious dickhead could come along and start making a bunch of those complicated transactions that take like two or three minutes to verify and because a block comes in every minute roughly, most people will never catch up to the tip of the blockchain, they will never actually be able to verify it.  And so that ten minutes is there because you need that long enough period between things to guarantee that people can verify and keep up with things.  If something's too fast, in terms of block intervals, then it is literally going to be impossible for anybody to verify the chain or keep in sync with other nodes.

Like when Elon brought up the idea of make blocks faster, make them bigger on Dogecoin, his suggestion for that literally would have broken the Dogecoin Network.  It would have been blocks coming in like every six seconds that were 10 megabytes big potentially.  Most computers couldn't keep up with that, like people would not be able to run a node and actually verify anything and so that interval is super important to people being able to do that.

Peter McCormack: This is a hard concept for new people getting into Bitcoin perhaps if they're not the most technical to understand here is that, what the Bitcoin Network is trying to do is create a decentralised network of value transfer.  We can get into layers, we've discussed Lightning previously; but what we're building here with the Bitcoin baseline blockchain is a settlement layer, one where you have high levels of security, but you do also have final settlement. 

To maintain that decentralisation, this is why the block wars were fought to keep the block sizes as small as possible because once you go beyond 1-megabyte blocks, we know that that's going to increase the amount of data that has to propagate and that is going to reduce the number of people who themselves can spin up a node.

Shinobi: If people can't do that, then how is this much different than something like PayPal?

Peter McCormack: Exactly, it's by allowing us all to run a node on an old laptop that we can all validate the entire block chain and that we can all trust; that when we receive our Bitcoin, that it is real and we receive full and final settlement.  This is the settlement layer as Jack Mallers has been telling me for the last three weeks.  But also with that block time propagation, because people talk about it being slow, that exists so that the network has time to fully process each block, and this is what allows us to have a decentralised, fully trustless, highly secure settlement layer.  Every other magical blockchain which has offered faster or cheaper transactions is making a trade-off against essentially decentralisation and security.

Shinobi: Yeah, I mean there is no way to play with something like the block size or block intervals without messing with decentralisation.

Peter McCormack: Yeah, cool, okay.  Let's talk about some of these consensus rules, just so people have an understanding of what they are and why they exist.  Specifically, a miner has mined a block, it has to construct those blocks.  Can we give a couple of examples of very simple rules they must follow?

Shinobi: Obviously as a miner, there is going to be the difficultly target that you have to hit hashing a block, so first thing that has to be correct and valid.  There has to be enough leading zeros on the block hash to meet that target or goodbye, like nodes are going to ignore that.  Also, obviously signature checking; if a miner puts a transaction in a block that doesn't have a valid signature for all the coins being spent, that's invalid.

Peter McCormack: Let's talk about that one because that's important, right.  So, the block itself is essentially a set of transactions, it's adding to the ledger all different transactions that have been included in that block; but if a signature is incorrect, that is somebody attempting to cheat the system, right; create fake Bitcoin potentially?

Shinobi: Yeah, and 100% of nodes will completely ignore it.  That is one of the most core rules that is applied to validating a block aside from the difficulty itself, on the actual block header, but then also then it gets kind of deeper.

Peter McCormack: I was going to say, if a miner tries to cheat the system by putting some fake Bitcoin in there that they're --

Shinobi: Wouldn't work.

Peter McCormack:  -- rewarding themselves to an address they own, the nodes will reject it and then they will lose all -- not only will that not get accepted, but they will also miss out on their reward of their coinbase reward and their transactions.

Shinobi: This actually has happened in the past two -- really quick.  The original block reward was 50 Bitcoin, and during the first halving when that dropped to 25, a bunch of miners actually tried running modified code that just kept the reward as 50 Bitcoin forever, and their blocks were completely ignored by everyone else.  They caved and obviously they did not change the block reward to 50 Bitcoin forever.

Peter McCormack: Am I right in thinking though that if they set the block reward to lower, the block will validate, so for example it's 6.25 now; but if they set it to 5, it will validate; but if they try and set it to 7, it won't.

Shinobi: Yeah, miners can do whatever they want with their coinbase reward.  They can claim some of it, not claim all of it; you don't have to claim that reward.

Peter McCormack: You can't create more.

Shinobi: Back to rules though, it also gets a lot more complicated and deeper at a technical level.  Really, at the end of the day, a transaction is just a script, like a little programme.  Like most normal transactions, the little programme just says, "Hey, here's a public key, check a signature and make sure it came from this public key", but you can do a lot more complicated stuff with that.  You can time lock things, so that you cannot spend a coin before a certain block height or before a certain time has been passed;  you can make the hash lock primitive that the Lightning Network uses for the HTLCs; so, all of these more complicated kind of programmes you can make.

There are also rules on how big those can be, like size limits, how many computations a node will run to validate something before it just goes, "This is requiring me to compute too much".  So, aside from like all the obvious things like, "Don't spend without a valid signature", you kind of have a lot more technical things like that, that kind of restrict things.  Those types of things come back to everybody has to be able to afford to validate this; it's not just the block size that's doing that, you also have limitations on how big an individual transaction can be or the script in an actual UTXO and things like that.  I think that is a good high-level view of things.

Peter McCormack: Let's talk about how somebody may try and cheat the system by creating an invalid block, but also running a node which validates that block, and we're really talking about chain splits here and what happens there.  But there could be a scenario where a miner creates an invalid block whereby they create a bunch of Bitcoin for themselves and that could be validated by a node, but if all other nodes reject it, that block only exists on that node; and they can keep creating new blocks and keep adding it to that node, but essentially they've created a new coin at that point because the chain has split.

Shinobi: They will make no money unless people want to buy that coin.

Peter McCormack: Exactly, so they can try it on their own but the only way to create a new coin which might have value is actually to have some kind of coordinated split like Bcash.  Yes, Bcash keeps losing value relevant to Bitcoin, but at that point there was let's say some form of social consensus where people wanted a different coin, which did something different.  So, they created a new set of rules, they created new nodes, a bunch of people run those nodes, a bunch of miners mined them and that essentially just split the network in two and created this new coin.

At that point some of the exchanges were willing to allow that to trade and then the market, through trading, decided the value of that coin, which is continually dropping compared to Bitcoin, but you can only create, well I'm saying an invalid block; you can only create a block with different rules by having other nodes which run them.

Shinobi: Yeah, if there is not some node out there that will accept that block and somebody to buy it, then a miner mining under different rules, they're just lighting money on fire essentially.

Peter McCormack: Another important part to this is also the exchanges, because the exchanges are what give the market price; so if somebody was to split the chain and create a new coin, then once that coin is traded that will tell the real value.

Shinobi: Without that there is no real to do that and actually succeed anywhere.  If the market can't price that, then the miners can't get paid and they can't keep mining.

Peter McCormack: An important point to discuss with this is people should go and do their history and go and read about the block size wars.  There's a very good history of that written by BitMEX which I'll include in the show notes, but this was regarding the SegWit2x fork that was discussed.  This was back in 2017 where there was a group of people who wanted to increase the block size, which required new consensus rules.  This will have led to a split in the chain; some people wanted it to happen, some people didn't, so it was quite obvious that certain miners would mine one chain and some would mine the other.

What was really interesting with that is when, I can't remember the exchange, but one of the exchanges allowed people to trade futures on those coins.  So, you could trade futures prices off this new coin, which means they could basically set what they're willing to pay for it, and that price dropped heavily compared to the price of Bitcoin, which was a way of people almost voting that they didn't believe in this coin as much.  Would you say that's fair?

Shinobi: Yeah, I think a couple of exchanges did that, but I'm pretty sure Bitfinex was the first one.

Peter McCormack: Yeah, I think so, and that was part contributed to the failure of the fork, because people were pricing this coin as less valuable than the original Bitcoin.

Shinobi: Yeah. I mean futures markets like that, I think, are probably the best tool if things come to that point.  Like if people do really want to split, there's no getting around it, that is the simplest cleanest way to kind of gauge the level of support there without opening things up to manipulation.  You can't fake putting Bitcoin on the line.

Peter McCormack: With regards to mining is there anything else we need to discuss?  Should we discuss orphan blocks, what they are and what that means?

Shinobi: Yeah, I think we could do that now.  Obviously, a miner mines a block, they spit it out to the whole rest of the network and the network verifies it, and then all the miners out there who've gotten that stop mining what they're mining and start mining a new block on top of that.

There's always the potential because when a miner finds a block, it's completely random, that two miners find a block at the same time.  When that happens, they're both going to send it out to the network and some part of the network is going to get one block first, the other part of the network is going to get the other one first.  Until the next block comes in, there isn't really a tip of the chain.  There isn't consensus on what the current balance is until some miner finds the next block on top of one of those two and then that decides which one of those conflicting blocks sticks around. 

Then the other one doesn't make it into the blockchain, that miner earns no money for that and it's almost like that block it never existed essentially.  This kind of just happens as a matter of course sometimes.  Blocks come in when they come in, sometimes that happens; but it's really just that simple in general although that probably will come up as a potential issue with a few ways that you can do soft forks.

Peter McCormack: Right, so if there is an orphan block, the miner that created the block that became orphaned off no longer receives their block reward.

Shinobi: Yeah, it just disappears essentially from the blockchain like it never happened.

Peter McCormack: Is this why we have this 100-block wait for them to be able to spend their coinbase rewards?

Shinobi: Exactly, because there is always the potential something gets orphaned, a reorg happens, etc, and so that's specifically so miners can't play games and try to con people and then, "Oh that block disappeared, that wasn't real money".

Peter McCormack: So, we should probably talk about confirmations here so people understand what that means.  So if you're using certain software or certain exchanges when you send Bitcoin out, they will wait till they've received a certain number of confirmations till they allow you to spend it.  But really, those confirmations are the number of blocks that have been built on top of the network; that's how that works.

The reason they do that and the reason most go -- I think the general consensus is six, although I know some use three, and there are some people, like crazy people who use one, but the reason they do that is because a reorganisation of the block six blocks deep is very unlikely, whereas a one-block reorganisation, it's still unlikely, but can happen.

Shinobi: Exactly.  This is kind of a core part of mining.  It's all based on probability, so really speaking the tip of the chain, if you like the most recent block that just came in right now, in all likelihood 99% of the time that is the block.  "Look at that block you'll know what everyone's Bitcoin balance is", but then an orphan happens and then, "Oh the guy who just sent you money sends it back to himself", and you never get paid because you just assume that first block was good enough. 

So, especially with large amounts of money, especially, that is the convention for waiting for those extra blocks built on top, because every block that comes on top of the one before it, it makes it exponentially harder and more expensive to kind of go back and undo things.  So, once you have those couple of extra blocks on top, yeah, you don't have anything to worry about unless the entire Bitcoin Network has something to worry about.

Peter McCormack: Yeah, and a good example of that is the company Bitrefill.  I can't remember if they use zero or one confirmation, but they might actually use zero confirmations; but most people when they're buying something from Bitrefill, it's $5, $10, $20, it's usually a pretty low number.  And they've done the calculation that the number of times this will happen is very, very unlikely, therefore they can swallow the cost for the very rare times where they've accepted zero block confirmations.  But if you were sending $1,000, $10,000, $100,000, you're going to want to wait six, maybe even higher number of blocks for confirmation.

Shinobi: My business, we do not accept zero conf for anything.  Until there is at least one confirmation on something, nothing is getting shipped anywhere.  Now, obviously it's your own choice.  If Bitrefill did the math and that's an acceptable margin for them, it's their choice to make.  But, yeah, definitely is wildly different to, say, be fine with zero conf for like $20 but yeah, don't play games like that when you're talking thousands of dollars or something.

Peter McCormack: So, we have the rules of consensus, but we also have this kind of social consensus that builds around upgrades to the system.  Can we talk about how upgrades happen, the process?

Shinobi: So, this is an interesting topic that I think is going to be very counterintuitive to a lot of people, and I will slightly mention Taproot here just to kind of make a point.  Taproot is actually two things, it is the Schnorr signatures that is upgrading standard SegWit stuff, and then it's MAST, Merklized Abstract Syntax Tree.  That's the cool thing where you can bury all the different spending conditions and only show the one that you're using.

But both of those things have been discussed amongst developers since literally 2013.  If you go on Bitcointalk.org you'll find people like Peter Todd, Adam Back, even Mike Hearn the evil enemy of Bitcoin that he was, discussing things like Schnorr signatures and how much that could optimise things; the Merklized Abstract Syntax Tree, that lets fun stuff happen.

People might look around right now and go, "Yay, Taproot, cool new thing", but both of those are literally two ideas put together that are eight years old or more, as far as ideas developers have talked about.  I cannot stress this enough: when you're trying to gauge consensus for an upgrade proposal, it is not a democracy, absolutely not.  It is not voting, it is not majority wins; that is not how things are done. 

The whole way in process for kind of gauging these things is rough consensus and this is actually something that comes from the internet engineering taskforce, one of the big bodies that actually standardises all the protocols and stuff for the internet.  Pretty much the idea is like I propose an idea and now anybody can bring criticism to that idea, anybody.  Now, we debate this idea, we go through all of the criticism and pretty much the only kind of restriction here is, any criticism is valid as long as it's not just total troll. 

If you are actually making a reasoned argument, you have a reason to criticise something, you're not just concern trolling or wasting time, that has to be addressed.  You are not allowed to receive criticism in this kind of process and not address it, not answer the problems that that criticism brings up.  So, the general idea is something is considered to have consensus or rough consensus if the idea was proposed, it was criticised and discussed thoroughly, and all of the reasonable criticism was addressed with answers or solutions or a reason why that's not the problem somebody thought it was.  As long as all of that criticism was addressed rationally, that idea has consensus.

Peter McCormack: So, let's talk about that.

Shinobi: However, if there's still outstanding criticism that has not been addressed, reasonable legitimate criticism, then that idea does not have consensus.

Peter McCormack: Let's talk about an example, let's use SegWit as the example.  A SegWit was proposed, upgrade to the Bitcoin Network, which would help support and enable Lightning payments, but also would increase the block weight of the blocks.  Talk about that as a process.  Somebody proposed the idea, it was discussed as an idea and consensus was eventually achieved.  You mentioned that, as long as there isn't any outstanding criticism, but what is valid outstanding criticism?

Shinobi: Reasonable criticism.

Peter McCormack: How is that judged or is it because we live in a decentralised way, it really just comes down to a general kind of feeling; how does that work?

Shinobi: It's just rationale.  A big part of the reason for SegWit was not just the Lightning Network, but also anything like it that had the same kind of requirements, because you have this issue transaction malleability.  And before SegWit, I could make a Bitcoin transaction, I could sign it, but I could play games with it.  Let's say I signed this transaction and then you take an output in that that I'm giving to you, and you sign another transaction based off of that; I could play with the signature, but it would still be valid and it would change that transaction I did.  

Because your transaction and every transaction in Bitcoin has to point to the last one, in the chain of transactions where the coins that it's spending came from, I changed that transaction ID; so that transaction that you made, spending off of that one is invalid now, because the transaction ideas is different because I played this game with it. 

The whole core idea behind SegWit was to handle the transaction differently so that it's not part of that transaction ID, so that if I go play games with that, it does not change the ID of the transaction that I'm playing with, and it does not invalidate anything built on top of that.

There is a lot of just nonsense around that.  There is still a signature there, it's just put together differently in terms of data.  And one of their "criticisms" of SegWit was that removing the signature would let anybody spend anybody's coins without signatures.  There is a little kernel of truth there, but it's mostly complete horseshit; and the kernel of truth is that when you add a new feature like that in a soft fork, the way that that works is there are essentially op codes or programme pieces in the Bitcoin script that are not defined, they do not do anything right now. 

When we add a new feature, we define those and then deploy it, but the people who haven't upgraded yet, they don't have that new definition, so they don't know what's going on there, they just trust anything that uses it, no matter what.

If most nodes, if most miners, if almost nobody actually upgraded to SegWit and then somebody created a SegWit UTXO, yeah anybody could steal that coin without the keys, but that goes for literally any soft fork including past soft forks that went just fine.  So, you look at SegWit and it's obviously kind of contentious, but at the end of the day, all the arguments against it were things like that.  That's a not a rational argument; you're kind of distorting the truth here to try to argue against SegWit, so in rough consensus -- but you just ignore that because it's not an honest, rational argument.

Peter McCormack: What I'm saying is, there's no objective way of measuring whether consensus has been achieved.

Shinobi: No.

Peter McCormack: I guess that the idea gets pitched and it gets tested, it gets challenged and even if there are people who oppose it, quite vocal opposition, if enough people feel that the criticism has been answered and it's worth doing, people will just start working on developing it, whether or not there is that outlier who might not like it.  They can work on it as much as they want, they can commit the code, but let's talk about acceptance of the code.  How do we actually get to that point where it is accepted?

Shinobi: People have to start running it but, yeah, I think we're kind of getting towards the point of how do we coordinate all this stuff?

Peter McCormack: Yes, how is this all coordinated?

Shinobi: Like I said at the start of this show, you have a soft fork and a hard fork.  A soft fork will restrict the rules more than they are now and a hard fork will expand them.  I think we should start with soft forks, that's the super majority of the upgrades Bitcoins have done.  Some people would argue --

Peter McCormack: Let's pre-empt that, sorry.  So, just to make it clear there are soft forks and hard forks; just differentiate the two so people understand why they are different?

Shinobi: It's whether you're restricting the rules or expanding them more.  Whether you're not allowing something that used to be allowed or whether you're going to allow something that was previously not allowed.

Peter McCormack: The important difference being is that a hard fork -- sorry a soft fork is backwards compatible, and a hard fork isn't?

Shinobi: Correctomundo.

Peter McCormack: Am I right in thinking we've never had a hard fork in Bitcoin; I can't remember?

Shinobi: That is actually a hotly debated thing.  There are, I think, two instances where some developers call things a hard fork.  I personally do not think that the things labelled hard forks were.  That's a whole can of worms, but I think, no.

Peter McCormack: Okay, we'll do that another time.  Certainly, we haven't had a hard fork for a long time and let's explain just very quickly why a hard fork is so challenging.

Shinobi: Everybody has to upgrade at once or you de facto get two new coins.  Like there is no backwards compatibility, there is no grace period.  If you hard fork, this is the hard fork; when that point is reached, anybody who is upgraded forks off, anybody who doesn't stays where they are.  It is 100% guaranteed that that chain will split into two, and now whether it stays that way or not, that's up for debate, but it will split.

Peter McCormack: It will split because -- will it split even if all miners upgrade but say some nodes don't?

Shinobi: Yeah, every node that doesn't upgrade will stop receiving blocks.  That block chain will stop growing and those nodes will just sit there forever waiting for a block that will never come.

Peter McCormack: In some ways, it's more important at that point that all miners upgrade; it's up to the nodes themselves, because if they want to have a dead chain that's up to them.  But if a miner doesn't upgrade there's -- because what I'm kind of thinking is that it's probably easier to coordinate all miners to upgrade than it is nodes, because there are lots of people out there who are probably running nodes who might not keep an eye on everything day-to-day whereas miners all --

Shinobi: You have to have everybody upgrade at once.  Just doing miners doesn't solve anything because you're talking businesses, the economy; anybody who doesn't upgrade their whole business break, like everything falls apart.

Peter McCormack: What I'm saying is then, whilst you might get consensus from all miners to upgrade, and you might have consensus from the majority of nodes to upgrade, there's going to be a few outliers who just haven't got around to it yet, maybe haven't upgraded their software.

Shinobi: I mean that's irrelevant if they're not using it.  If you're running a node and you're not using it for anything, then it might as well not exist.

Peter McCormack: Well for example now, I'm away for five weeks, if the upgrade happened but I didn't upgrade my node, I would have a static dead node with no new blocks being generated.  I can always upgrade it when I get back and catch up, but it feels to me the real danger is -- well there's two dangers: There are dangers if miners split and they start mining separate chains, that's a problem; or if miners want to upgrade, but the majority of nodes don't.

Shinobi: That comes down to what are they going to do in the market?  If all the miners upgrade to a hard fork and none of the businesses, none of the users do, nobody wants to buy that new fork coin probably, so those miners aren't going to make any money.  And if they're rational economically, they're going to turn off the hard fork and they're going to go back to mining what people actually want to buy.

Peter McCormack: So, this is what happened with UASF, so again I've said to people they should go and look into the block size wars; specifically they should go and look into UASF, because at that point the miners, a lot of miners, were signalling to do the upgrade, the S2X upgrade, to upgrade to 2-megabyte blocks, but that was economically driven.  The users themselves, led by a shadowy underground Bitcoin guy and --

Shinobi: Led by no one except themselves.

Peter McCormack: Led by themselves, but the UASF upgrade -- the movement for the nodes was that, if the users don't support this then this is bad for miners, so that was a big support for maintaining the 1-megabyte block size.  What I'm saying is --

Shinobi: Let's shift to soft forks because that's really what a lot of 148 everything was about but, yeah, like you said earlier, they're backwards compatible so this guaranteed things are going to split in half dynamic with a hard fork; that is not a guarantee for a soft fork.  Now, it's still possible, but it's not guaranteed the way that a hard fork is, and the reason that most upgrades in Bitcoin's history have been done this way is specifically because of that. 

If you take currently almost -- no, less than because of Elon, less than $1 trillion market cap, monetary network, and you split that in half, you are screwing with a massive market.  That will have economic consequences that will cost businesses money, it will probably result in a devaluation in the market; that is not something you want to do with a big valuable network, so we do soft forks.

There's actually a couple of different ways that these have been done historically.  The earliest and the simplest way is just a flag day, and this is almost all of the soft forks, actually I think all of the soft forks that Satoshi deployed before he disappeared, were done with flag days like this.  It's literally just you put a line of code in there at this block height or at this day in time, just start enforcing this new rule.

It's very simple, it's very easy but the problem is you don't really know who has upgraded or not in that situation.  Just having that turn on for anybody that upgraded, that doesn't tell you how many miners upgraded, how many exchanges and businesses upgraded, how many users upgraded.  So, this is kind of where that risk of a chain split happens. 

Like I said earlier with, anybody can spend your coin in SegWit stuff, that is true for any new feature that isn't being enforced by most of the economy and most of the miners.  You do something like a flag day, you know tomorrow it's turned on; and then a bunch of miners didn't upgrade, a bunch of businesses didn't upgrade, well some A-hole can come along and steal somebody's SegWit coins, so to say, and then those miners who haven't upgraded, they'll just accept that because they didn't upgrade, they're not validating it.  They'll mine that block that just stole SegWit coins against the rules and all the miners that haven't upgraded, they'll keep building on that block; and so you will have chain split here between people who actually upgraded and started enforcing SegWit and those who didn't.

So, that is kind of why BIP 9 was created.  It's pretty much a deployment mechanism where, in a section of the block there's kind of little bits, like ones and zeros, that are supposed to tell you like the version of a block, what version of the Bitcoin protocol is this enforcing, is this made with.  The entire idea behind BIP 9 was we could deploy a client that's going to turn a new feature on, but only if miners flip that bit, and if enough of the miners have. 

So, the idea here was this is not voting on whether to turn anything on whatsoever, but it's just a way to kind of gauge how many miners at least claim they've upgraded.  Once a majority of miners have signalled that and claimed that they upgraded, then the feature will turn on and everybody's nodes who have upgraded will start enforcing it.

The whole idea was just to be able to gauge and figure out when most people have upgraded so that you don't have that chain split happen because a lot of people didn't, and some guy made the transaction that broke the rules because he knows it's going to split the block chain in half.

Peter McCormack: Let's talk about miner's signalling.  How do they signal that they are going to activate the upgrade; and what kind of percentage are we looking for of miners signalling for us to say, "Okay, it's ready to switch on"?

Shinobi: Well, they literally just flip a piece of data in the block.  Actually, most mining pool software that I'm aware of literally has custom features, so they can just do that at the snap of a button.  Pretty much the percentage is kind of an open question.  Historically it was deployed every time up to SegWit with a 95% requirement.  They wanted a super majority of all miners upgraded and signalling before turning something on.

The most recent Core deployment was Speedy Trial for Taproot only required 90% and so honestly, that is something you can kind of play with; there is no hard requirement there except that it be more than half of the miners.  You have to have at least a clear majority so that if none of them are lying, they would orphan a block for anybody breaking the new rule so that even people who have upgraded aren't going to get cheated or follow some block chain they don't want to be.

Peter McCormack: So, I noticed on Twitter with Taproot route with people tracking miner activation, they were still, after 95% of miners signalled, that was when people started to kind of like leap around and celebrate and say, "Okay, I think we're ready to go".  Once we've reached that point how do -- is it then agreed that at this specific time, people will activate the upgrade?

Shinobi: Yeah, if this locks in, in the next difficulty period, with 90% plus miners signalling, that will lock in.  Everybody who is upgraded to the newest Bitcoin Core, or the USAF client out there, Taproot will be guaranteed to activate and that will start being enforced in November.  The reason for that long delay here from now till November is, like I said, mining pools, their software is set up so they can signal for upgrades just like that, and not actually have to upgrade to the new client.  So, I think the logic here for the long window before Taproot route actually turns on, is to just let miners signal and lock it in, but then have this long period before it's enforced so that miners can actually upgrade to the new client that enforces Taproot, if they haven't already.

Peter McCormack: Okay, cool so that kind of makes sense.  One of the things that seems to be very cool about this, which does run in opposition to some of the critics of Bitcoin, which I always see as people who are either massive shitcoiners or new to Bitcoin, is that they claim that Bitcoin is old tech, boomer tech, it's being out competed by other technology which moves faster; but this is one of the things I love about Bitcoin.  I'm holding all my, well let's say a majority of my wealth in Bitcoin; I don't want it to be easy to change; I want it to be hard to change; I only want changes to come that are absolutely necessary and absolutely benefit the network.  I see this as being hard to change as a feature.

Shinobi: Yeah, and for anybody listening, there's this idea that eventually Bitcoin will ossify and it won't be changeable anymore.  I think a lot of the reason at least my thinking behind why I think that will eventually come to be, is pretty much think about the rough consensus and how we actually gauge consensus for the thing itself before we try to activate it.  Think about how hard that is going to get the bigger Bitcoin gets and I think if that doesn't play out that way, if Bitcoin doesn't ossify, then that's very dangerous.  If Bitcoin just keeps getting bigger and bigger and bigger and it does not get harder to change the bigger it gets, that's kind of a dangerous situation to be in, you know what I mean?

Peter McCormack: Yeah, that kind of makes sense.  I mean, we have this Taproot change coming.  With these soft forks, by the time it is activated, has it been so well tested that some kind of catastrophic bug is unlikely; or will there be a period, say after the activation of Taproot, where someone like yourself will be like, "I'm just not going to just move some coins for a bit, I just want to see how this works"?

Shinobi: I mean there is always the potential for bugs, always.

Peter McCormack: Of course.

Shinobi: But the developer community is getting bigger, this code has been going through review for over a year now and like I said, the underlying concepts have been bounced around by devs since like 2013.

Peter McCormack: Right, okay, okay, but still --

Shinobi: There is no rush whatsoever when a new feature is activated to just go rush and use it immediately, unless you want to do something that you need that new feature for; don't feel any rush to do that, it's not the end of the world.  Like when SegWit activated, I didn't start moving UTXOs to SegWit addresses for months afterwards; it is not a big rush.

Peter McCormack: Okay, so let it bed in, let it be tested, get a feel for it, etc.  With Taproot, are we getting new Taproot addresses?

Shinobi: Yeah, real quick, and then I feel like I would be completely irresponsible if I didn't bring up the date in this section.  But, yeah, we are getting a new address format.  Hopefully, this should be the last time this happens.  The whole reason for the Bech32 addresses that SegWit uses was to make it harder to screw up manually copying an address somewhere and there was a little goof up by Peter Wuille in implementing that. 

When this first came out, he was like kicking himself over the head and like, "Oh I can't believe…", I feel like he way overblew how big the issue is in terms of apologising it, but Taproot is going to come with a modified version of Bech32 to fix that.  After that, we should never need to add a new address format ever again; everything after Taproot can just keep using that.

Peter McCormack: Okay that's fair.  Are we ready to talk about Taproot?

Shinobi: You got to do the update, man.

Peter McCormack: All right, the update.  You should explain what a BIP is, firstly, just because people go, "What do mean BIP?"

Shinobi: A Bitcoin Improvement Proposal.  These are pretty much the documents that people write up in order to propose a change to Bitcoin.  Also, just document things that might not be well understood or documented; but BIP 9 and BIP 8 are the two proposals for activating soft forks and different ways to do that.

The thing with BIP 9 and the miners signalling is, it can fail; the whole design for BIP 9 is if the whatever threshold you set for miners to activate a new feature, if that isn't met in the activation window, then that feature will just completely fail to activate.  So, it leaves the door open for miners to disrupt something or stop something from activating, even inf the entire rest of the network has consensus and wants this thing. 

The idea behind BIP 8, at least originally, was you pretty much do something just like BIP 9, where miners can signal and it will activate based on miners signalling, but instead of failing to activate at the end of that window, if miners haven't signalled enough to activate the feature at the end of the window, it'll just activate anyway so miners cannot play games or stop users who upgraded from enforcing that feature.  All they can do is turn it on early and if they don't turn it on early, it is going to turn on at the end of that activation period anyway.

I feel like I should save most of my thoughts on this for that show in Miami, I want to keep this less about my opinion and just the facts here, but that's the core difference between the two of them.  BIP 9, if miners do not signal, then whatever feature is being activated it will just fail to activate; but with BIP 8, it will turn on at the end no matter what miners do.

Peter McCormack: Okay, all right, so Taproot.  I think knowing how complex Taproot is, and it's mainly a lot of stuff in the background that unlocks a number of features for the techies, I don't think we need to go into a huge amount of detail.  I did cover this with Andrew Poelstra, I'll add in the show notes, people can go check it out; just do the short version of why Taproot's important.

Shinobi: First off, Schnorr signatures allow us to do multisig way more efficiently, so that instead of having however many signatures there are keys in a multisig, you just have one.  That is a huge privacy win and a huge cost effectiveness win.  Then there's the MAST aspect of it, the Merklized Abstract Syntax Tree stream.  That is awesome, because let's say I want to lock my coins up, make sure that you can spend them if I die, right now I just have to make a massive UTXO that has that whole script in the UTXO; I can spend it with my key or Peter can spend it with his key if I haven't moved this in six months, because I'm probably dead.

Both of those things will be visible on chain, both of those things will be there no matter which way it gets spent and I have to pay fees for it.  Taproot lets me do crypto magic and bury that, you can spend if I haven't moved it in six months, out of that script; so, you all you see on chain is just my key can spend those coins.  Then, I give you the information that would let you spend it like the little Taproot tree that commits to that, and nobody will ever know that you can also spend my coins unless you actually spend them.  That is just completely hidden from the world unless you use it to actually move those coins.

Peter McCormack: Okay that is a good simple explanation.  This is a massive upgrade though; do you think this is going to be the last big upgrade or is there something that people are thinking about starting work on afterwards, because I know this is something that's been in the works for years?  Last big upgrade or what are we going to do next?

Shinobi: I hope not because if it is, then Bitcoin is going to be a lot more crippled and less flexible than a lot of us hope.

Peter McCormack: Why is that?

Shinobi: Well for one, Lightning; it does not scale properly without the next feature that people want, any prevout.  You know how I said earlier when you spend a UTXO in a transaction, you actually have to point to the previous transaction that created that UTXO by transaction ID?  Any prevout would allow you to, instead of pointing at a specific transaction, you just point at a script, so like this public key and an amount.  You can spend any transaction, regardless of what the transaction ID is, as long as it is that key and that amount.  So, this lets you kind of streamline the Lightning Network heavily.

Right now, every pre-signed transaction you make for every update to your channel you do, you have to keep all of that.  With any prevout you would only have to keep the most recent one, because the little magic of it is, you can take a signature that spent a coin that has that script and that amount, and you can make any other transaction that has that same script, that same amount do anything else with that. 

I have a transaction hitting chain that is using any prevout.  It's old, like it's not giving the Lightning participants the right amount of money.  Instead of penalising them, what I would do is I would the signature from that transaction and then I would take my most recent transaction and attach that signature to it, and I could actually spend the out-of-date one that just hit chain with my most recent one, but you can only do that for a transaction that came after.

There's a little sequence number in the transaction that gets incremented up by one every time you update, so when I use the most recent one, there is no higher transaction, so I know I'm going to get my money.  All I have to do is keep that one single transaction or piece of data, instead of a piece of data for every single time my Lightning channel is updated.  Without that, Lightning is way less scalable and flexible; but that is the next big feature I think most devs are concentrating on.  And I really, really hope Taproot is not the last upgrade because if we don't get that, then Lightning will still be very useful, but it will be a lot less useful than it would be with that.

Peter McCormack: Wow, it sounds like we will definitely get more upgrades then if that's super important and I've been using the Lightning network over in El Salvador.  I used it a number of times and loved the fact that I could make quick and cheap payments, and I was actually buying coffee with it, which was quite funny.  Cool, all right, so is there anything we've not covered here that you still want to cover because, we've covered quite a bit?

Shinobi: I guess we could talk a little bit about the dangers of forks in terms of malicious ones.  A big benefit of soft forks is that they're backwards compatible, but that can also become a very bad thing.  Let's say 70% of the miners decide they're going to censor you, Peter; they're never going to mine one of Peter's Bitcoin transactions ever again and they're going to orphan any block that does.  There is nothing you can do about that.  Those miners have decided that they are going to do a soft fork that only they are enforcing that Peter's coins can never be mined again.  It does not matter at all that no user, no business, nobody else is enforcing that, because they make all the blocks.

Even though nobody is running this new feature that Peter can't transact, no other user or economic entity is enforcing that, because all the miners are, well it's enforced.  It doesn't matter that your node isn't enforcing that, the miners are forcing that stricter rule on you and there's nothing you can do about it.  Soft forks are very useful in terms of the backwards compatibility, upgrading things without being disruptive to the network, but miners can enforce malicious forks that users would not want and there's not really much we can do about it in a lot of the situations.

Peter McCormack: Right, okay.  Something definitely to be aware of, okay.  Before we finish can we please talk about the Mining Council, because I do just want to pick your brain, bring up any relevant historical context, because there's seems to be split views on this.  I just think Elon Musk's a fucking clown right now and the reason I think he's a clown is two reasons: firstly, he has access to anyone. I'm sure if he put out there, said, "Look, I would like some advice, I want some help on Bitcoin", anybody would come forward and help him.  I feel like if he sat down with somebody like Adam Back, etc, he would be able to learn a lot very quickly about Bitcoin, but he's choosing to learn in public; something I've done myself, which is a brutal experience as well.

You know as much as I do how much early time, I spent putting ideas out there that were stupid and wrong and got heavily shit on for it and I'm grateful for it, in retrospect because --

Shinobi: You were actually learning in public though.  Elon, I think has got a lot of shady shit going on.

Peter McCormack: There is that as well, but it was a healthy experience for me, but it pissed a lot of people off in the process, but that's fine.  It's just one of those experiences you go through; you discover Bitcoin, you think something doesn't make sense, you put it out publicly, you get criticised, you go and research and you refine your ideas.  That's how I've done it, but I've tried to be honest about doing that.  I feel like he is part learning in public but also, I don't 100% obviously trust him.

Shinobi: It's all carbon credits.  This is all about carbon credits.  I 100% guarantee you he wants a Bitcoin mining carbon credit market, but that's where Tesla makes all its money.  If it weren't for carbon credits, that company would be making no money.

Peter McCormack: I suspect you're right, so be it if that's his game, so be it; I don't think it's particularly healthy.  What really pisses me off is we seem to get two tweets at a time from him, it will be a Bitcoin tweet and then it will be a Doge tweet and the Doge tweets are very -- he is just basically bullish on Doge.  Whether he means it or not is a different story, but he is leading lemmings off the cliff who will get rekt as we know.

Shinobi: I'll tell you this, if Tesla goes private in the near future, then Elon just pumped and dumped his shitcoin on a bunch of morons so that he could take his company private.

Peter McCormack: Potentially.  Whatever he is up to, so be it, but I've seen a mixture of responses.  I'm just trolling the fuck out of him, because I just think he's a bit of a dick for some of the ways he's behaved and the influence he's exerting.  I have seen a couple of people say, "Look, fossil fuels are an issue", and I think that's debatable, I know some people don't think they are.  I mean I think they are, but I also think the free market's important; but other people saying, "Look, it's just a group of people who've got together to agree to publish their energy mix", which a lot of companies do anyway.

Shinobi: What I call bullshit.  I call total bullshit.  If that was true then when asked about carbon credits, I forget his name, one of the participants in this, would not have said, "I can't comment on that on behalf of the council", he would have said, "No".  That answer means that came up in that conversation.  Like this -- I'm sorry, like maybe I'm just an asshole, I give zero benefit of the doubt here.  This is arrogant people who think that everything can be solved with a call to some corporate boardroom, stepping up and larking about, "We're going to fix Bitcoin".  That is what this is, it is nothing else, it's going to be the same shit over again.

Peter McCormack: Yeah, potentially.  Like I say, there is though a mix of responses.  The question I really want to ask you is, as somebody's who's lived through a lot of the history of Bitcoin, there will be people listening, I know there will because I've seen the replies.  So, when people are trolling Elon, whether it's I or other people, there's a lot of people jumping in saying, "Leave him the fuck alone", "Shut the fuck up", "Elon's good for Bitcoin", etc. 

At the same time, I've also seen Michael Saylor get heavily criticised for the first time.  Now I like Michael and I think his intentions are honest, but I also at the same time am aware he's a large Bitcoin holder; by-the-by, whatever.  What is the historical context regarding meetings such as this, associations such as this?  Why is it that we should be fearful, what is at risk here?

Shinobi: Normalising the idea that a bunch of corporate CEOs dictate how Bitcoin works or how to handle Bitcoin's problems.  I do not like Michael Saylor.  He's said the right things, he preaches to the maxis on Twitter.  I don't care because none of that changes at the end of the day that he is the CEO of a regulated company that will kiss regulatory ass anywhere necessary to protect his investment.  He is not here for the same reasons that most of the people I know in this space are here.  He will not put up the fight that most of the people I know in this space will, end of story.  He's the CEO of a public company; he can't play those games.

The danger here is people in this space, the actual experts, the actual people who have been here, the actual people who know what is going on, need to stop -- excuse my language, greeting every famous rich person who walks into the room with a free hand job, because all this is doing is creating this impression to the larger general public that people like that have any clue what they are talking about; they don't. 

Go on Michael Saylor's page, or his Twitter page, and look up the video he posted, "The seven network effects of Bitcoin".  He's just regurgitating shit Trace Mayer said for years.  That whole multi-layer, that's Trace Mayer; he's just repeating what Trace Mayer said.

Peter McCormack: Okay, all right, well I'm holding judgement back for the moment from Michael Saylor, because like I say, I've been impressed with his fast understanding of Bitcoin and his staunch defence of it very publicly.  What is the actual risk here; what is it that bitcoiners are worried about could happen from this?

Shinobi: This is going to create a regulatory body that can be captured by the government.  They're already talking about pressuring miners based on different energy sources, that's what this disclosure will amount to publicly, so think about how that goes.  Maybe miners who aren't green enough get taxed more or don't get approved for opening up an operation. 

Like I said, carbon credits, why are you refusing to comment on carbon credits on behalf of the council because some members of the council probably want that.  Ultimately this is just how regulatory creep happens.  Not to mention the fact that one of the mining pools involved with this are the jokers meming about being OFAC-compliant and we're just going to censure transactions that the government tells us to. 

It's this simple; shit does not happen in a two-week news cycle and too many bitcoiners are focused like zombies watching the mainstream media on this two-week news cycle.  When it ends, they completely forget what happened in the last one and move onto the next one and people don't pay attention to the longer-term directions and trends of things, because, "Oh everything didn't explode in this news cycle, so it's not a problem; onto the next one.  I just forgot what happened in the last two weeks".  That is how apathy happens, that is how people get away with shit right in front of our eyes, because everybody just pretends like if something doesn't explode in this week, it's not a problem.

Peter McCormack: So, it's something potentially slippery and shady in the background, so a slippery slope to potential regulatory capture of a bunch of people who feel influential, or are potentially influential, changing both the narrative and forcing things which aren't in the best interest of Bitcoin?

Shinobi: Yeah, I mean like they're the miners, you can't get more integral to the functioning of Bitcoin than the miners.

Peter McCormack: What is the role of bitcoiners at the moment, if you care about this; what do you think people should be doing?

Shinobi: If you're a Twitter troll, call people the fuck out and don't let them get away with it.  If you're a developer, start diving through things like BetterHash, Stratum v2, P2Pool, start looking at actual technology that can help decentralise mining more.  If you're a business guy, I don't know, see if you can find some way make money pushing things in that direction; but it's just do something, because sitting around and making excuses for people who keep nudging things in that direction, it's not going to end well.

Peter McCormack: Okay, so it's pretty big stuff; so we should call them the fuck out, not accept any of this, troll them, question them, pressure them; what are we trying to get them to do?  Are we expecting the Mining Council to be disbanded; or are we expecting them to publicly discuss their plans?  What do you think should be happening here?

Shinobi: Get rid of it, from my opinion, although we both know that's probably not going to happen; so if you're not going to get rid of it, yeah.  You want to do something like this?  Open up, give us transparency.  Don't give us this horseshit closed-door meeting and then have one member of the meeting just, "Oh I can't comment on that issue that totally came up for everybody, but I won't acknowledge it came up".  Get the fuck out of here!  Imagine mining in North America where you have to deal with carbon credit bullshit.  Imagine that, you just completely set up regulatory capture.

Peter McCormack: Okay, well I'm going to see if I can get anyone on to discuss it then.  I think we should put all the questions to them publicly and I'd be interested to see if they would actually do it.  I do think perhaps I pissed some of them off by just flat-out calling bullshit on it.  Yeah, it's an interesting one because there are people I like and trust, like Nic Carter; I like Nic a lot, I trust him a lot.  I think he's a good bitcoiner, he supports Bitcoin.  He was quite dismissive of how influential this could be; is that the slippery slope?

Shinobi: Yeah, and just to say too I respect Nic a lot.

Peter McCormack: Yeah, Nic's great.

Shinobi: I think he gets shit for a lot of idiotic reasons, but I do fundamentally disagree with him on this.

Peter McCormack: That's fair, that's fair.  I mean I'm going to talk to him about it as well, because I'd like to see what his thoughts are on it, I think Nic is fucking great and we're blessed to have him.  He's one of the best writers on Bitcoin as well. 

Interesting times Shinobi.  It's funny, four years in Bitcoin is a long time and you certainly become a different person the longer you stay and the more skin in the game you have.  You care a lot more about protecting the network, reducing influence and calling bullshit out.  It's a really interesting thing sometimes because sometimes I'm like, "You should shut your mouth, Pete, you might piss sponsors off, you might piss potential guests off", but I don't know, man.  I feel like there's bigger issues at hand now and you have to call this shit out and go and take all the flack with it.

Shinobi: I can't knock needing to make a living, Pete, but this is why I have never done the sponsor thing with any content I make.  I'm going to call shit how I see it and I'm not putting some financial incentive between that.

Peter McCormack: Yeah, that's fair.  All right, man, well listen, awesome episode, we've done 90 minutes which is incredible.  Looking forward to getting this out there and seeing the feedback.  Do you know what we're going to next month, have you thought ahead?

Shinobi: Actually, still unknown who the developer was, I think that might be interesting if it's someone I have gotten into shit with in the past, but I feel like the next one, we should bring that core dev who wanted to come on and discuss the larger internet infrastructure in terms of mining and the network attacks and stuff.

Peter McCormack: Let's do that, man.  All right, cool.  Well listen, I'm going to see you in just over a week, looking forward to hanging out in person and perhaps we'll record a show in person while I'm in Miami.

Shinobi: Sounds good.

Peter McCormack: All right, dude, I will see you in a week.