WBD291 Audio Transcription

2020 Bitcoin Tech Review with Shinobi

Interview date: Wednesday 23rd December

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 am joined by Shinobi host of Block Digest. We review the technical side of Bitcoin in 2020, including MuSig, Schnorr & Taproot, discrete log contract, Lightning Labs Pool & Loop and CoinSwap.

“This year, is the first year where I feel like the question of ‘is all this going to work out in the long term?’ is settling itself, everything is just rocketing forward.”

— Shinobi

Interview Transcription

Peter McCormack: Good evening, Shinobi, Brian Trollz.  You know what; I never know which one to call you?

Shinobi: Well, that's part of the game; what is my name?

Peter McCormack: I always prefer Shinobi.

Shinobi: Whatever works.

Peter McCormack: All right, man.  Well listen, look, you were kind enough to come on the show as part of my Beginner's Guide and that was very popular.  My tech shows don't always do as well as the Number Go Up, Moon Juice ones.  But of the Beginner's Guide ones, that was the fourth most popular, and a similar number of downloads to the third one.  There was an Andreas one that did really well, but it was really popular and went down really well. 

I think that combination of your deep knowledge and me trying to get it out in a way that was easy to understand was really popular, so I think it's going to be good to do an end-of-year review with you, man.  So, I appreciate you doing this.  Are you ready for this?

Shinobi: I'm good to go.

Peter McCormack: All right, man.  Well, look, you've been in Bitcoin for a lot longer than I have and even for me, this has been kind of like a really interesting year for a number of reasons.  I was just on the phone, actually, with Willy Woo, chatting to him and one of the things I was saying to him is, it's been a really weird and fucked-up year, because a lot of people have been on lockdowns; but yet, we've all been consumed with Bitcoin.  We've all had this massive distraction on Bitcoin, which I think has helped in some ways, for me certainly anyway, just to kind of get through the year.  I've been able to focus myself on other things.

But, dude, you've been in Bitcoin for a hell of a long time; how does this year compare to other years?

Shinobi: I mean honestly, just everything has accelerated.  I mean, everybody being locked up inside, I think has been a big contributor to a lot of major technical developments.  Obviously, on the economic side, things have gone completely bonkers because of COVID this year, so I don't know what else to say, except this year is the first year where I feel like the question of, "Is this all going to work out in some way in the long term?" is settling itself; everything is just rocketing forward.

Peter McCormack: Yeah, I think you make a really good point there because sometimes, you know, I'm newer round here than you, I didn't -- people have said to me this week, because I did a big buy in terms of borrowed money off the bank to do a buy this week, and some people are tweeting me like, "Why didn't you do it at $3k?" and I think the thing was, at $3k, I didn't have the conviction I have right now.  So many things have happened in this latter half of the year that have given me a lot more conviction behind Bitcoin: one, being here to stay; but, two, being something that goes beyond just retail and interest.  I think, obviously, all the MicroStrategy stuff and corporate interest has happened.

But, one of the things I did want to ask you, before we get into all the tech stuff, is that we've seen all this kind of accelerated interest from the billionaires, the hedge funds and the companies, yet I know you personally are deeply focussed on the tech and what it enables you to do.  Do you have thoughts on whether that is a good or a bad thing, or are you neutral on it; like, does it really matter?

Shinobi: I mean, I think it's both.  In one way, that class of people or investor, I mean obviously, the whole reason you took out that loan is looking through and grasping the nature of a speculative attack, where people just start leveraging their assets to accumulate more Bitcoin because as it goes up, it's less and less of that coin to pay off the loan, or whatever you've leveraged.  So on that regard, that's something people have been predicting or looking towards in this space for as long as I've been here, and it's finally starting to happen.

But, on the other side, I consider myself very politically minded in this space.  I'm not here just for number go up; I want to see this technology, in some ways, erode government control or influence on things.  I want people to have more free access without all this red tape to these types of financial tools.  And frankly, the billionaire class, the Michael Saylors, I don't think they give a crap about that.  They don't care if people have access to those things; they don't care about the development and adoption of those types of technologies; and so, I think that divide is just going to keep getting bigger and bigger, the more of these people come into this space.

Look at Michael Saylor talking about his attitude about Bitcoin, "Who cares about regulatory arbitrage or censorship resistance?  Just use PayPal", or, "Currency should be the purview of governments"; versus somebody like Jack Dorsey, who I also have problems with for other reasons, but actively funding development of things like the Lightning Network, of different protocols and aspects of the software that users interface with to actually bring those tools to people.  It's completely stark contrast between the two's attitudes about the space.

Peter McCormack: Well, yeah, because I certainly think there is this split now, and some people will sit in both camps, but there are certainly a group of people who really are -- I can't remember who said it; it might have been Mike and Space said it; but, something along the lines of, "There's a group of people who basically only care about the 21 million".  It's an inflation hedge and that's all it is to them, whilst there's obviously yourself and other people who really care about how the technology is used.

Someone like Alex Gladstein, actually, is a good lens for that for me as well, because he comes to me with ideas for shows, whether it's people in -- we did a show about the people in Belarus who are striking to essentially attack Lukashenko's state infrastructure, but they need a way to live and survive.  So, Bitcoin donations supported that; a similar thing in Nigeria.  Privacy is important; censorship resistance is important in those scenarios.

Like I say, I think there are people who sit in both camps, but there certainly seems to be a new class who really only care about the scarce side of things.  And, I was trying to weigh it up with myself.  It's like, well does it really matter, because if you have a big influx of billionaires and such, do they create almost a regulatory moat that protects Bitcoin, and therefore allows people to carry on working on it in the background; that higher threat from the state against Bitcoin, does that dissolve a little bit with these people coming in?  I wasn't really sure.

Shinobi: I mean, I think that's just up in the air.  I mean, things could go that way; things could also go the way where these types of people effectively help strangle Bitcoin and capture it so that it's not useful for those things, just to protect their own investment. 

Like Michael Saylor said in, I forget which interview or piece he wrote that he said this in, but he specifically called out that class of investor, "Don't mention about these things, don't talk about these use cases, because that will make these people nervous".

Peter McCormack: Yeah, well that will have to be dealt with separately.  So, listen, we are coming to the end of the year.  One of my goals next year is to become a little bit more conscious of the tech, to explain the tech to people, to understand it a bit better myself, even though I do struggle with it; so, I do appreciate the fact that you're going to be helping me with some of this.  So, we've got a few things to get through today.  I'm going to do what I normally do, is get you to explain it to me in ways that I can understand, but most of all try and understand not only how it works, but how I would use it and the benefits of it.

So, the first thing we've got on our list, which you helped me put together, so thank you so much; so we have multisig, which you threw in two things I didn't even know existed, was multisig-DN and multisig2.  Now, I'm a multisig user; I've used it twice this year.

Shinobi: Specifically really quick, this is specifically MuSig; it's a 'punny' name for the Schnorr multisig.

Peter McCormack: Okay, interesting, so I'm learning straightaway.  Okay, so I had my first exposure to multisig this year.  I mean, multisig's one of those things; it's kind of obvious what it is, but I'd never really used it until I became a Casa customer.  It blew my mind because firstly, it's that added layer of protection but actually, the UX of what Casa did made it super simple for someone like me to actually use.  I'm really glad I've got my Casa setup.

I've also used the Unchained version to set up my bet over the election with American HODL.  Now, with that one, it was a lot more technical and I had to have my hands held with that.  But, at the same time, there's something really quite fucking awesome about multisig; especially now I've got it for protecting my Bitcoin.

So, I just assumed MuSig was an abbreviation, so let's get into that.  Explain to me what MuSig is, MuSig-DN and MuSig2 are?

Shinobi: Okay, well first to get into this, you kind of need to break down, one, signatures at a high level and how they work; and then, two, how multisig works right now.  So, really in a strictly technical sense, all a signature is, is just taking some secret number that has a relation to a public number, and then taking a message, in this case a Bitcoin transaction, and multiplying that message by the secret number, which then allows somebody to do another mathematical analysis to verify that that signature is related to that secret number, by comparing it to the public one.

Now, all of these signature protocols out there also use a nonce, a random number, in multiplying that message by the secret number.  The reason they do this is because without having that nonce in there, if I just made a signature without that nonce, I could just reverse that and get the private key from just that signature.  So, the nonce is kind of like, think of it a bit like a protective shield, in terms of that's what allows you to sign things without somebody being able to do just a quick maths equation and then actually figure out your private key.

In Bitcoin generally, what that nonce is, is you just take the private key you're signing with and the thing you're signing, and hash that.  And a deeper, scary thing with nonces is, if you ever reuse the same nonce with the same private key to sign two separate messages, that also will let somebody just figure out your private key.  So, the reason that to get a nonce, you hash a transaction that you're signing and the private key that you're signing it with, is that that will always create the same nonce for the same signature, or the same thing that you're signing.  So, there's no way to ever reuse the same nonce for a different message and kind of screw yourself there.

Now, with a regular multisig transaction, all you're really doing is just having everybody in that multisig sign separately with a separate signature, where they make their nonce like that, and so there's no way to screw that up.  But, when you bring Schnorr into the picture and how multisig works with Schnorr, you're no longer kind of having everybody make a separate signature.  Instead of a multisig being these separate addresses linked together, you actually take everybody's separate addresses and combine them into a single one.

This gets really screwy, because everybody's just kind of collaborating with their part of that combined private key to make a single signature, instead of everybody produce their own.  So, that brings into question, how do you guarantee that you handle the nonce safely?  So pretty much, each of these MuSig implementations is a different way to handle that nonce securely.  Are you still following here?

Peter McCormack: Yeah.  Well, this is where one of my questions will be.  Okay, I understand, actually I don't understand what you're saying, but I'm listening to what you're saying.  Hopefully this is just stuff that coders, developers, the people that are building the kind of applications that I would use, they just handle all this for me, right?  This isn't something I'm personally going to have to fully understand to be able to use a multisig wallet, right?

Shinobi: Not entirely, but you're going to have to make choices, or at least pick software based on the choices developers make, because each of these different MuSig protocols handles that completely differently.

Peter McCormack: Right, okay.  So, let's use Casa as an example, because that's the implementation I know because I use Casa.  What's going to happen there; what are they going to do?  I mean, you might not know, but what are the options to them?

Shinobi: Well, they're going to have to pick a variant of MuSig and I think that I'm pretty sure which one they would pick, but it kind of comes down to the security trade-offs you want to make.  So, let's look at the first MuSig proposal and I'll break them down as simply as possible.

In the original proposal, pretty much what has to happen here is that everybody has to generate a nonce and then, that's combined into a single nonce for the whole transaction and then, everybody collaborates on their signature.  But, what the nonce is made of in the original proposal is the private key that one participant is signing with; the public key of everybody in the multisig; the transaction that they're signing; and then also, what's called a "session ID".  This can either be a number that you just increment to add one to every time you sign a message, and then you have to keep track of that; or, it can be a truly random number. 

The problem here though is, randomness with a nonce is much more dangerous than something like generating a key.  Even if you have randomly, so to say, generated a nonce, if there is any kind of bias, or just subtle non-randomness in that number, that can be used to break the signature and find your private key too.  So, using this version of MuSig, the original one, you either have to have a guaranteed source of randomness, like something like a hardware random number generator; or, this number that you increment, you can never lose track of that number, because if that's erased or not updated properly, then the next time you go to sign, somebody can try to trick you into using the same nonce in a signature.

The whole problem here with Schnorr is how everybody generates their own independent nonce and then combines that into a single one.  Let's say you and me have a two-of-two address; if I use the same nonce on the same message, like I just generate something honestly because, let's say, our internet disconnected in the middle of signing something, but you pick something different, then that effectively combines into a different nonce that you created together and now I'm kind of screwed in the same way that reusing a nonce in a conventional way would screw me, and you can deduce my private key.

So, whenever anybody's doing a Schnorr multisig like this, everybody has to use the same nonce for the same message and if anybody tries to change something in a second go at signing that same message, it has that same effect where you can have your private key leaked there.  So, if you do not generate a securely random number, or if you're using this kind of counter and that's reset or not updated properly, this can lose you your private key in signing, with a malicious party.

Peter McCormack: Right, okay.  I'm going to hazard a guess that there are a lot of people who will get this instantly; the tech people will understand that.  But, a lot of people are going to be listening to this, I think, Shinobi, and they're going to be going, "Yeah, you've completely lost me here.  Just tell me that somebody else is figuring this out and when I go and use whatever device I'm using, it's just going to work?"  I think that's what most people would want.  I know some people will argue with me and say, "Pete, stop being anti-intellectual!", but I actually think a lot of people will just hope this is all done in the background.

That's the great thing about Casa, right?  I don't really need to understand multisig.  All I need to do is have my app and have my devices available to be able to sign something, and it works.  All I have to do is be conscious of distributing my keys in a way that makes it very hard for somebody to access them.  I'm kind of okay with that, and I know what people say about trusted third parties, and in some ways Casa is my trusted third party, but I kind of need some level of trust, because I can't technically do this without someone like Casa.

So, again, my same point to you would be, do I really have to worry about all this?

Shinobi: To some degree, because you're going to have to pick which piece of software to use, and there are these multiple ways that they can implement multisig on Schnorr.  But, I will say though, this original implementation that counts on secure randomness or this counter; this is probably never going to be implemented anywhere just because of how dangerous that is, and how easy it could be to mess that up.  Just your computer failing and not updating that index number could leave you open to a malicious person and that multisig figuring your key out.

So, this proposal is kind of, at this point, in the dustbin and if you see anybody trying to implement this, you should probably tell people, "Don't use that software".

Peter McCormack: Is that just MuSig, or is that MuSig-DN or is that MuSig2; sorry, which one is it?

Shinobi: Just the MuSig, the first version that was designed.

Peter McCormack: Okay, so the first version was designed and it exposed some flaws.  So, MuSig-DN or MuSig2, have they solved these problems?

Shinobi: Yeah, in two different ways that come with two different trade-offs.  So, MuSig-DN stands for "Deterministic Nonce" and this is kind of a way to do this how it works normally in a transaction, or signing for Bitcoin, where everything is always going to be the same.  There's no random number interjected; there's no counting index.  It's pretty much just everybody generates a nonce based on, instead of the private key you're signing with, it's a special private key setup just for the nonce, called a "Nonce key"; the public key for all the signers in the multisig and the message.

Then, doing things this way, everybody can make their nonce and then generate a zero-knowledge proof to prove that the nonce that they're giving everybody else was generated this way correctly with these things input to it.  That way, you pass off the nonce and the public key to that nonce key with that zero-knowledge proof.  Then, everybody involved can check the proofs, check that the nonce was generated correctly and then sign everything.

If anybody is playing games, or didn't generate the nonce correctly, so in a way where they could try to steal somebody's private key, then the zero-knowledge proof will fail and everybody can just refuse to sign.  So, this way, there's kind of a two-step interactive process here to sign anything, so people do have to communicate back and forth between the clients; but, there is no need to count on randomness, there is no need to keep this index number safe, this all just kind of works without having to track this other information; so, more like how a non-Schnorr signature works.

Peter McCormack: Right, okay.  So, explain to me; the difference between MuSig and multisig is to do with Taproot; is that correct?

Shinobi: It's just Schnorr versus non-Schnorr keys because effectively, before Schnorr, a multisig is just taking -- let's say you're doing a two-of-three, you literally just take those three separate public keys, or addresses, and then that's put into a script together.  So, you can see each individual key in that multisig after you spend it.

With Schnorr, it's literally just taking the three keys in that and combining them to make a single key that looks just like a one-person or a one-key address.  Then, these MuSig protocols are how everybody with their piece of the key for that can generate a signature without giving their piece of the key to everybody else.  So conventionally, a multisig is just adding these separate addresses together in a line, so to say; and, Schnorr is literally adding them together just to get a single address or number.

Peter McCormack: We should probably explain, some people who are listening have probably got no idea what you're talking about when you're talking about Schnorr, but this is to do with the licence for the signatures expiring, right?  Now, this is the reason it wasn't included before.  I can't remember the name; if you said the thing, I'd remember it.  It's the name of the EDC; no, what's the thing --

Shinobi: ECDS.

Peter McCormack: Yeah, ECDS.  I do remember some of these things!

Shinobi: ECDSA is what we use right now for a signature algorithm and Schnorr is what we're going to be shifting to.  And actually, Schnorr was developed before ECDSA; it's just somebody patented it.  So, the whole reason that ECDSA was created was to just have a signature algorithm that was open for everybody to use without patents.

Pretty much the main difference just comes down to the algebra behind how they work.  With ECDSA, it's not really a straightforward thing.  It's very difficult to do additive or subtractive things without breaking security; which is kind of why multisig is each separate address shown independently, rather than making a single address out of them, because you can't really just add things together and make ECDSA signatures work. 

But, with Schnorr, because the maths works differently, you can kind of do a lot more general maths operations.  Like, if you add two public keys today together, it's not really straightforward, or even secure in a lot of circumstances, to just add two private keys together and be able to get an ECDSA signature, without actually giving one half of that key to the other person.  But, with Schnorr, you can just kind of mush public keys together and it's a lot easier for a group of people to make a signature for that, without having to give up the actual private key to the other person.

Peter McCormack: All right, awesome.  Well, this sounds cool.  As I said, probably something that won't affect me directly unless somebody else builds it in.  I'm certainly not going to look at the details too much.  But, the next thing we should move onto and talk about is Discreet Log Contracts.  Again, I've looked a little bit at this.

Shinobi: Woah!

Peter McCormack: Have I missed something?

Shinobi: We didn't explain MuSig2 yet!

Peter McCormack: Oh, okay, sorry!  MuSig 2.  Sorry, man.  Let's do MuSig2!

Shinobi: So, the trick here is again just how the nonce is generated.  Pretty much, instead of generating a single nonce per person, everybody generates two nonces and then, effectively shares those around with everybody and kind of takes that whole set of everybody's nonces and you hash it.  Then, you take that hash and your two nonces separately, and you combine those things to come up with a single nonce.  Then, once everybody's done that, you combine them together to get the global nonce for the whole transaction.

The trick here is that, if anybody changes one of the two numbers that they share with everybody, then the hash of all of those are going to be different.  So, the nonce that everybody winds up pitching in for the whole transaction also winds up being different.  And so, if anybody tries to play those games of, let's say, trick you into using the same nonce, but I'm going to change mine to try and steal your key, that won't work, because the minute I change the information or nonce that I pick, then what everybody else throws in on the table changes too, because of how you hash everything together before you start adding and generating new things.

So, the big advantage here over MuSig-DN is that, let's say you and me make a multisig, we can exchange those nonces ahead of time; and then, rather than an interactive multistep process to make a signature, it's just one step.  I sign, you sign, you just push the transaction to the network and we don't have to go back and forth, as long as we already exchanged those two nonces ahead of time.

All three of these laid out together are suited for different things, optimally.  Throw MuSig1 out; that's dangerous and shouldn't be used anywhere.  But, MuSig-DN kind of protects you from having to track data besides your keys.  There is no way that if you lose some piece of data, as long as you still have your keys, that you can be tricked by anything.

But, with MuSig2, if we lose those nonces that we exchanged, then we kind of have to take a pause for a second and sort that out, because that opens the door for shenanigans.  But, yeah, these different things fit different use cases.  Like, you brought up Casa a few times in this section.  Casa might want to, say, implement MuSig2, just because it will be easier for you signing with hardware wallets; you're not going to have to go pass back and forth multiple times; it's much more like it is now.

But, they also might want to implement MuSig-DN, because even though you have to go back and forth, you don't have to store these nonces and not lose them to make a signature, you know what I mean?  So, there's kind of a little trade-off in terms of what you're protected from and how easy it is and how little steps you can make a signature in.

Peter McCormack: Yeah.  I mean, like I say though, I just want Casa to make that decision for me and not really even think about it, which I know really winds people up, some of this; but, it is just so complicated.  I don't want to have to know how both work and which has a benefit or not; I just want them to make a decision for me and that's essentially what I pay for the service for.  You understand that, right?

Shinobi: Yeah, but it's just, think about it like you're not going to have to, and most users aren't going to have to understand the details of these things to such a low level, but you're going to want to at least have some kind of understanding of, okay, I'm using this one so I only have to click the sign button and then put something to the computer and submit it.  But, I have to make sure that I don't lose this extra piece of information that I can't just generate from my seed; versus, okay, I'm going to have go back and forth a little bit, but I don't have to worry about not losing this other file; do you know what I mean?

Peter McCormack: Yeah, but as long as they explain that to me.  It will just become a procedure.  I already have a procedure at the moment with the various hardware wallets I use to sign a transaction.  As long as that's all explained to me; but, the actual inner workings, that needs to be solved in UX, otherwise it just becomes too complicated for most people to spend time over, and also opens them up to making their own mistakes.  But, I'm sure Casa will solve this for me.  What I pay Casa for every year, I'm paying them for the UX.

All right, well let's go on to the Discreet Log Contracts, because I think this is a bit more interesting to me, because I think this is potentially something I could see over the next few years be something I could start to use as I start to use Bitcoin a bit more.  So, let's start by you explaining what Discreet Log Contracts are; and, I know when they were announced earlier this year, people were very excited with them, so let's explain it.

Shinobi: Okay.  So, if you think about a Lightning Channel, what is that?  It's just a bunch of pre-signed transactions that enforce an outcome, you know what I mean?  If I open a Lightning Channel to you, I spend half of a Bitcoin to you, so there's half on my side, half on your side; we have these pre-signed transactions to guarantee that we both get the right amount of money, right?

Peter McCormack: Yeah.

Shinobi: So, a DLC is pretty much taking a bunch of pre-signed transactions like that, but instead of just requiring you and me to sign off on something, it requires an oracle.  But, the neat trick of how you construct this is, the oracle effectively is just an entity that, let's say, tracks the price of Bitcoin.  And, every 24 hours, with its oracle key, which it publishes publicly, signs the price of Bitcoin in a way where it reveals information to sign with that key; or, to fulfil a condition in an adaptor signature or a smart contract.

So, what you and me would do, if we want to bet on the price of Bitcoin, is create a whole set of transactions.  Let's say we're only going to care about dollar price swings.  So, we start with the price of Bitcoin now and then, below and above it, create a transaction for every dollar that Bitcoin could go up or down, to a certain point, that all require the oracle to sign that price to be valid.  We pre-sign all of these and then, just load that like you would a Lightning channel with the funding transaction.

At the end of it, the time-out period, the oracle, if acting properly, will sign the price of Bitcoin and then, both of us could either just cooperatively sign and settle that properly in one transaction; or, if one of us doesn't want to cooperate with the other, we take the signature from the oracle and plug that into the correct pre-signed transaction, and one of us can just settle that unilaterally.

The nice thing about how this works ideally is, an oracle just broadcasting this information doesn't have to know who's using them as an oracle.  You and me could just privately go, we're going to make this bet, and pick some public oracle that signs that and make all these transactions; and that oracle has no idea that me and you are using them to settle this bet.

Peter McCormack: Okay, that's interesting.  So, let's try and think; have you got a good example of that people understand of how this might be used?  You've said bets; we could do a bet on the price of Bitcoin going up and down.  But, can you think of anything else, any other scenario this might be used in?

Shinobi: Yeah.  I mean, this has been used to bet on political elections; you could use this for sports betting.  Like, hell, if you can find an oracle that will sign off on the weather somewhere, you could bet on the weather.  Pretty much anything that an oracle two people will trust to say this is what happened or didn't happen, where you can actually make a set of pre-signed transactions that will settle money accordingly, you can use this to bet on.  You can gamble; make financial contracts like futures or options.  You really just need an oracle that people trust that are going to go, this happened or this didn't happen or this is the price of something, and so on.

Peter McCormack: I guess there is a scenario though where the oracle can be corrupted, the oracle could deliver false information; so, what can you really do about that?

Shinobi: Well, through the beauty of cryptography, you could use multiple oracles.  Let's say we don't trust Bob, the oracle, alone to tell us what the price of Bitcoin is, so we'll get Alice and Carol and we'll get all of them involved in the contract, so that we're not trusting a single one of them.  And then, federate that in a similar way to stuff like Liquid; there's still trust involved, but you're not trusting a single party.

Peter McCormack: Right, okay.  So, do you see a scenario therefore of a marketplace being created for oracles?

Shinobi: Yeah, absolutely.  I think really, the bigger that Bitcoin adoption picks up in the sports betting, the gambling markets and so on, I think we'll start seeing a shit ton of different oracles pop up for all kinds of stuff like that.  I mean, sports betting, poker, those are some of the biggest transactional uses of Bitcoin, and have been for at least as long as I've been here.

Then, from the financial markets side of things, it's just a matter of time until people start building financial derivatives and stuff with this.

Peter McCormack: Okay, just thinking about this.  So, do the oracles themselves take a small part of the transaction fee as a payment for being the oracle; is that something that's built into this?

Shinobi: It's not something built in inherently, but you could try to do that in certain ways.  For instance, I think there's some thought at shared bits for kind of monetising that with micropayments over Lightning Network.  You could potentially try to play games with selling access to a signature for a certain event or something.  But really, it's just the design space of how you want to implement this is massive. 

You can have an oracle that knows that you're using it; you can have an oracle that doesn't know that you're using it, like in the example I gave; you can have ones that operate for free; try to find some way to charge for it.  There's really just a lot of flexibility in different ways you could use this.

Peter McCormack: Yeah, I think this one's super interesting, especially on the betting side.  I love a wager myself, not just in sports, as you've seen this year; but, I could see a real use case for that.  It sounds like a business use case for this, for example legal contracts.  Could you have an oracle which is not based on, say, a specific piece of data that's coded in, but I guess a trigger of certain events that would lead to the payments of …

You know, a lot of people talk about, for example, housing contracts.  Once contracts have been handed over, all the different payments that need to be paid to the different parties can happen.  Is that something that could happen like this, or is this purely for databased oracles?

Shinobi: Well, I mean potentially, but really what it comes down to is being able to map a set of possible outcomes, or where that money should go, to a set of pre-signed transactions.  So, you could try to do things like that but, honestly, personally I think it would just make more sense to just use a normal escrow without pre-signed transactions set up like this for those kinds of things.  But, in principle you could.

Peter McCormack: Okay, all right.  Cool.  Well, that's definitely something that's interesting.  I'll be intrigued to see how that plays out.  I guess prediction markets is another one then?

Shinobi: Absolutely, you could build prediction markets on top of this.  And really, that would get kind of interesting in the sense that, the way this works is you can kind of pick your own oracles, you know what I mean?  There is absolutely no requirement for, let's say, people who bet on the US election this year, there is no reason why everybody making that bet has to use the same oracle.  You could use Bob, I could use John, somebody out there could federate and use both of them.  So, it really kind of starts, at least in my mind, asking the question, what is a single marketplace; do you know what I mean?

Peter McCormack: So, the next thing we're going to talk about is Lightning Pool.  So, before we get into this, I want to tell you my kind of views on Lightning at the moment.  I've kind of stopped caring, I kind of lost interest in Lightning, just being someone who's more of a light touch Bitcoin user.  I was thinking, I've got no use for this.  My use case for Bitcoin is holding and storing value and occasionally transferring some of that value around, usually big ticket amounts.  I just don't really have a use case for buying things with Lightning and I just didn't really care too much and I actually started to think, is this a project that we don't really need.

Then, I did this interview recently with Nik Bhatia about his book, Layered Money, where we really talked about the evolution of Bitcoin, the evolutionary stages, where it goes from store of value to medium of exchange.  And then it was that realisation that there will come a time whereby I potentially will be using Bitcoin for smaller ticket purchases, not because I'm choosing to use it instead of fiat, which doesn't make any sense right now; people want to hold onto their Bitcoin.  It's because you want to hold onto Bitcoin and you will only accept Bitcoin, because we're going to move to the stage where fiat becomes so worthless that you only want to transact in Bitcoin. 

So eventually, you might get to that point where maybe I'll have a business service that only accepts Bitcoin, or I'm dealing with people who only accept Bitcoin, so I'll have to use Lightning.  And therefore, I got this realisation, it doesn't matter how much Lightning is being used now; it's how useful and how ready it is for that stage where we have moved to that point where it's a medium of exchange.  Do you understand that realisation I went through; sorry for my shitty explanation?

Shinobi: No, I mean, yeah.  It's really the nail on the head there.  Most people don't want to use Bitcoin for payments and, I mean, it makes perfect sense.  I frequently do just because I'm all in Bitcoin.  If I still had some fiat revenue or fiat holdings that for whatever reason I hadn't put into Bitcoin, I would instantly spend that first; but, I'm all in.  That's kind of the big bootstrapping problem.

You didn't really use these terms, but I think you hit the nail on the head.  Everybody constantly talks about Gresham's law and how, "Everybody wants to just hold the good money and not spend it".  But, the other side of that is Thiers' Law, which is, "Nobody wants to accept anything but the good money".  And so inevitably, there has to come that tipping point.

Before that tipping point, you really have to specifically create a reason for people to want to spend Bitcoin and that's kind of the entire thought process behind products like Lightning Strike, you know what I mean; just hook your bank account up there and you can spend your dollars, but people will receive that as Bitcoin if they want to.  So, it's kind of bridging the gap between Gresham's Law and Theirs' Law; do you know what I mean?

Peter McCormack: Well, I do, I do, because there are certain times where I've had to use Bitcoin to buy things; I had no choice.  Whatever it is I'm buying only accepts Bitcoin.  So, that realisation that I might do the same at some point, or this might be an increasing phenomenon, that people just don't want fiat.  I do, I have to because of my lifestyle; I can't be all in Bitcoin.  But, that kind of realisation that, well, hold on, if that is something that's three, four, five years ahead, isn't it great that we will have had a decade of Lightning development in that time.

All this great work, for example this Lightning Pool that we're going to get onto, that all will be done in advance.  So, that was a really important realisation.   So now, when somebody says, "Nobody's using Lightning", I get it.  It doesn't matter how much they're using it now, it's whether it's set up and ready for the point when people need it and it does the things they need it to do.

So, just before we get onto this Lightning Pool, what is the general status of Lightning development because, outside of Lightning Pool and a couple of other things earlier in the year, I haven't actually heard too much?

Shinobi: I mean, honestly, it's been ripping along at a massive speed, and that is all super nerdy, autistic things; but, things have really been moving forward.  There's been a lot of development for kind of solving issues of, let's say, the fees go up very quickly and you have a pre-signed transaction with a much lower fee on a Lightning channel; how to deal with that.  There's been a lot of development in terms of whole new ways that you can structure the pre-signed transaction that a Lightning channel actually is, that's a lot more efficient using block space.

And then, that's ignoring things like Lightning Loop launching, which allows you to atomically swap in and out of the Lightning Network and the main chain without closing a channel.  A lot of stuff behind the scenes that people not actively playing with this probably haven't noticed, but from my point of view, there's been a lot of development progress this year; quite a lot.

Peter McCormack: All right, cool.  Well, let's get into Lightning Pool because again, this came out recently, a lot of excitement around this; explain what it is and why this is so important?

Shinobi: So, this solves one of the biggest problems of the Lightning Network, which is if you don't have Bitcoin, how do you get somebody to open a channel with you so that you can receive Bitcoin over the Lightning Network.  It's not on-chain; you can't just be sent money; somebody has to open a channel with you to do that.

So, pretty much what Lightning Pool did is build this massive marketplace where you can solve that problem.  Before this, pretty much the solutions here were stuff like Breez wallet would just open a channel with you when you create a wallet, so that you can receive money, with their own money.  But, that is very ineffective and eventually, they're going to run out of money.  Lightning Breez is probably not sitting on enough Bitcoin to open up channels to every single user as their user base keeps growing.  Or, pretty much go on Bitcoin Twitter and be like, "Hey, can somebody open a channel to me?" 

So, this Lightning Pool marketplace kind of solves all that.  And pretty much the idea behind it is somebody's operating this pool, so in this case Lightning Labs, and in order to enter it, what you do is you connect with Lightning Labs and make a two-of-two multisig, kind of like a Lightning Channel, with a pre-signed transaction that will give you your money back after a while; and then you load that wallet.  And pretty much the whole point of the marketplace is that I can go to this marketplace and I can go, "Hey, I would like to have somebody open a channel with me so that I can receive money", and what I'll do is, in this two-of-two that I opened with Lightning labs, we'll call it an account, I'll place a bid. 

Every block, they will match bids to people with money to open channels with and this is kind of like a CoinJoin.  They'll go around everybody who has had bids matched in the marketplace and make a big transaction that pulls money out of everybody's accounts, and pays them to the person opening a channel with you, if you're buying a channel.  And, in the case of somebody selling a channel, it will actually open that Lightning channel together in the same transaction you're paying for.

So, they'll go around and get everybody to sign this transaction and then, all at once, in a big block transaction on-chain, it will take money from everybody buying channels; and then, from the people selling them, it will actually open up those channels.  And, the neat trick here is that I can kind of guarantee that a channel will be open for however long I paid for, because they add an extra time-lock on the channel that gets opened so that it literally is not valid to be spent on-chain until the lease that I opened expires.

So, if I go in this marketplace, I pay a small premium to, say, have somebody open a Lightning channel to me for two weeks.  That channel will have a two-week time-lock on it, so that it cannot be spent on-chain until two weeks.  So, this person who opened the channel with me, they cannot close it until my lease expires.  So, it's kind of a decentralised way for routing nodes to sell their receiving liquidity for a small premium to people who need it.  And, it's atomic, so you pay money; you either get your channel opened, or you just don't sign your transaction and nothing can happen to your money.

It solves this problem of, how do I get a channel to receive money without counting on some single, centralised entity, or going on Twitter and being like, "Can somebody help me out?"  So, this really solves one of the biggest core problems that Lightning Network had.

Peter McCormack: Okay.  So, can I myself choose to essentially loan Bitcoin into the pool?

Shinobi: Yeah.

Peter McCormack: So, I guess the question I then have is, opening up and closing a Lightning channel, as you said, requires a two-of-two, so that requires two on-chain transactions.  So, for me to do that, obviously potentially depending on what fees are like at the time, but that's something I have to consider, whether I'm going to lose or profit out of loaning money into the pool.  And, I'm imaging the fees are very marginal, yet the on-chain fees could be a bit higher.  Have the economics of that been thought through?

Shinobi: Yeah.  I'm not sure if this is actually implemented right now, or if it was just part of the design, but the bidding process allows you, I think, to kind of specify, "I don't want to pay more than this in fees", to safeguard against things like that.

Peter McCormack: Do you see a scenario where, in the future with Lightning, that channels almost remain permanently open, or could remain almost permanently open?

Shinobi: I don't really think, given how money flows in the economy, that that's possible to do forever, but I think the more the fee market matures and Lightning grows, that people will try to keep channels open as long as possible, as long as they're actually gaining some benefit or profit out of that.

Peter McCormack: Well, it sounds interesting and, you know, Lightning is one of those things I do need to spend a bit more time on using it and understanding it, but this is obviously a super important thing.  Decrypt said, "This brings DeFi to Bitcoin"; is that true, or is that just one of those annoying statements?

Shinobi: No, I would actually say that that is pretty on point.  The interesting thing about this, from an economic point of view, is that this is kind of another revenue stream for routing nodes on the Lightning Network.  Right now, you just open channels where you think people will want to make payments to, and if you guess wrong, well you're just not going to make a lot of money; you have to close that out and go guess again. 

But, when you're leasing channels through Lightning Pool, even if you open a channel somewhere that doesn't receive a lot of money, you're not making a lot of routing fees off of it, you still make the premium to open that channel in the first place.  So, this actually makes revenue for routing nodes a lot more predictable.  You will at least get the lease fee, even if you don't get a lot of routing fees for opening that channel.

Peter McCormack: Okay, that makes sense.  Okay, before we move on to the next thing, is there anything else on Lightning you want to cover?

Shinobi: I could probably sit here for the next hour ranting about a million different things!

Peter McCormack: All right, we'll do a separate Lightning show at some point.  Okay, the next one is something I am interested in.  It's CoinSwap, because I had Belcher on the show, and it's known as the Chris Belcher project, right?  It's the one -- the Human Rights Foundation are sponsoring that project, helping fund that, helping fund his work.

Shinobi: Them and Square Crypto.

Peter McCormack: Okay.  And this was, as I believe it, I'm trying to remember back to my interview; this was something which Gregory Maxwell kind of theorised and that Chris has picked up.  So, let's explain to people what CoinSwap is, and some people will be aware of CoinJoin, so how does it compare and contrast?

Shinobi: Well, let's look at CoinJoin and describe that as a privacy tool that everybody sees you doing.  If I make a CoinJoin, I mix some coins in a giant transaction where everybody's outputs are the same amounts; everybody sees that.  I'm creating confusion and now you are not necessarily able to point at the input of mine and figure out which output is mine.  But, you know that I mixed those coins; you can see I am trying to obscure which coins are mine, and there's no real deniability there.  So, CoinJoins are kind of everybody making a single transaction together. 

The idea behind a CoinSwap is that you are pretty much atomically linking a bunch of separate transactions that don't connect to each other so that you and me can swap our coins between each other and if done properly, nobody really sees that; do you know what I mean?  It doesn't give away that I'm trying to obscure which coins are mine.

Peter McCormack: So, how does this compare to a mixer, the old mixers that we used to have back in, say, 2013?

Shinobi: Imagine CoinSwaps as somewhat similar to that, except there's no central person who is kind of doing it and seeing where everything is going.  An old mixer is, you give me your coins and I give you completely different coins, but I see which coins were yours and which coins I gave you.

The idea behind CoinSwap is kind of accomplishing a similar thing, but there's no person in the middle who sees where everything is going.

Peter McCormack: So, there's no person who can be arrested for running a mixer.  Interesting questions here where we have to talk about the regulatory side, or the regulatory lens that might come over this, because obviously we had the DropBit wallet CEO arrested and is currently facing charges for running a mixer. 

So, do we potentially face -- this is something that can be created and run, I'm imaging from what you're saying, without that central person, but do we still face potential issues of those people working on it under threat?  Is that something that's been considered and talked about?

Shinobi: I don't think so.  I don't think we're anywhere close, at least in the West, for developers being targeted just for writing software, but I do think there is kind of a different risk that CoinSwaps have versus CoinJoins.  Say, with a CoinJoin, everybody just throws their inputs in together and then constructs their outputs and as long as everybody sees they're getting their money back, they sign this transaction and push it to chain. 

So, it's just a single transaction; it's very clear that everything that goes into that is mixing itself; and, you might get yelled at for that.  Some more brutal regimes might try to argue that's money laundering in and of itself but in reality, it's clear that you mix this; and, at least in America and a lot of other places, I don't see much trouble, other than if you deposit that to an exchange somewhere, they're going to be like, "Explain this"; do you know what I mean?

With a CoinSwap though, this is like you and me put our coins in a multisig that looks like a single sig address with a withdrawal transaction so that, if somebody cheats, we can just take our money back and no harm; but, people can see that we were trying to do a CoinSwap.  But, if things go successfully, our coins go into these two intermediary addresses and then, they come out of them later and they're both in our control; unilaterally, we've switched our coins.

Well, let's say you're some crazy terrorist and I didn't know that, and I go to deposit to an exchange.  That's a lot more of a sticky situation, because we did not kind of taint our coins together in a CoinJoin where it's like, we are mixing these and everybody can see this.  We just switched them over with no connection between them.  And so, rather than making everybody's coins tainted in the same way, we're just kind of switching any taint that might be associated with that coin; and, there's no obvious sign on-chain that something like that happened.

Peter McCormack: Right, so if a coin's tainted and I've got a tainted coin and I swap it with you; you now have the tainted coin?

Shinobi: Correct.

Peter McCormack: So, that presents some issues really in that you could CoinSwap with somebody and give them a tainted coin that identified you as having done some particular things, like you say, maybe terrorist activity, money laundering.  Could somebody face prosecution for somebody else's activity?

Shinobi: I mean potentially, yeah.  But, the silver lining there, at least in my mind, is that as far as Chainalysis and evidence like that, I have still, to this day, yet to see any conviction in court where that was the sole piece of evidence.  That has always just been part of the evidence pile and there's a lot more than just Chainalysis to accuse and prove somebody did something.

So, I don't think that somebody's actually going to do this in a situation like that and get thrown in jail for ten years, but that might create a very large legal headache in the meantime dealing with that.

Peter McCormack: Yeah.  How will this be used?  Does somebody have to run a service for you to be able to use this, or can it exist as a decentralised service?

Shinobi: The way Belcher is implementing it now, it's kind of like the maker-taker model that JoinMarket uses; everybody can just advertise, "I have coins to swap with", and them people can come in and pay a fee to do that. 

Peter McCormack: But therefore, it does require a centralised service to run it?

Shinobi: No, it just requires some way for the makers to advertise themselves to takers so that they know they can go swap with them.

Peter McCormack: But, how do they actually do the exchange?

Shinobi: Well, the thinking that Belcher's at, the last time that I talked to him, is just creating a distributed message board over something like Tor.  And, when somebody wants to offer coins as a maker, he's looking at the idea of using like a bond, where somebody has to sign and lock up some coins for a while to prove they actually have coins, to stop the coordination board from being spammed; but, pretty much just like a distributed network where people can pass around these advertisements.  And then, if you want to go and make a CoinSwap, you find a maker who charges fees you like and you go, "Hey, I want to CoinSwap".

Peter McCormack:  Right, interesting.  Okay, so do we know how far away this is to being something that's actually usable?

Shinobi: Honestly, I don't like putting timetable predictions to development work.

Peter McCormack: Okay.

Shinobi: But, hopefully, given that he's actually received multiple grants for this, sometime next year maybe we'll have something pretty relatively fully formed to play with.

Peter McCormack: All right, cool.  All right, let's move onto Taproot.  We don't need to spend too long on this.  I've done a couple of shows with Andrew Poelstra about this and --

Shinobi: Quick interjection?

Peter McCormack: Oh, yeah?

Shinobi: Sorry, I keep doing that!  But, the one thing I want to say last about CoinSwap is, nothing is magic in terms of privacy tools in this space alone; and, I think that CoinSwap and CoinJoin are probably going to be useful things interacting with each other.  One kind of gives everybody the same taints, but everybody can see that's happening; while the other just kind of swaps it around and nobody can see that's happening.

I see a lot of use for maybe a pattern of CoinSwap and the CoinJoin that, or vice versa, to get the benefits of both; do you know what I mean?

Peter McCormack: Yeah.  Okay, yeah, privacy is something I definitely need to work harder on; another one of the things on my todo list for next year.

Okay, so Taproot, again, like I said, we don't need to spend too long on this, because I've had Andrew Poelstra on a couple of times about it and to be honest, it does go way over my head.  I think a lot of people it will do.  It seems to me it's just more like a tool for developers.  But just out of interest, just a very quick overview of what Taproot is.  We're going to obviously be repeating ourselves from the MuSig stuff, but I think the thing I'm most interested in is what's happening with activation?

Shinobi: Well, I think that everybody has PTSD from SegWit activation, pretty much!

Peter McCormack: Well then, you're going to have to explain that to people, because they'll be some people who, you know, I get new people coming in all the time, especially right now as we're in a bull market.  Why do we have PTSD from SegWit?

Shinobi: Well, back in 2017 when it was deployed for activation, Bitmain and a lot of their customers refused to activate it, demanding a hard fork block size increase too.  That became a whole month-long thing where some people in the community were threatening to just turn it on anyway and risk a chain split, and the miners dug in and, up until the last minute, refused to just cave to that.  And, at the end of the day, it came out that SegWit pretty much broke a mining optimisation that Bitmain was using that allowed them to make extra money, and that was the whole reason behind it.

A lot of the miners, aside from Bitmain, pretty much didn't really care about it.  They were just being told by Jihan that if they supported it, he would stop selling them hardware.  So, it pretty much became a giant shit show between this mining business that didn't want to lose a competitive edge, and most of the rest of the space who kind of wanted to push the technology forwards, so that it was more scalable and flexible.

That was a good six or seven months of shenanigans, arguing, sitting on the edge of the seat, before finally, through a bunch of silly rationalisations, they just activated SegWit and then backed off on the block size increase and made Bcash.  So, I think everybody is just kind of caught in the mindset of, any fork is going to lead to a big fight like that, because everyone has PTSD.

Peter McCormack: All right, but it does have to get activated at some point, so what's going to make this happen?

Shinobi: I mean honestly, at this point, I don't know.  I mean, the miners are getting on board with it now; a lot of the mining pools are showing their support for it publicly and signalling; most of the community supports it; there's no real argument against it.  I think, just at this point, a lot of the contention comes down to, how should we activate it; just set a date where it turns on; have miners signal for it?  And, nobody can make up their mind because of differing degrees of worry about 2017 repeating itself.

Peter McCormack: Right, okay.  All right.  It does feel like a different scenario though from 2017, because we don't have the same issue of people wanting to create a new coin out of this?  So, I mean, I can't really add anything of interest here, but okay; it will be when it will be.

Okay, last one on the list that you wanted to talk about was BIP-0085.  Just so people know, again because people listening won't even know what I'm talking about or what you're talking about when we talk about a BIP; but, a BIP is a Bitcoin Improvement Proposal.  So, what is BIP-0085, and why do you want to talk about that?

Shinobi: So, this is a really cool thing as far as wallet generation and backups, that I think could be very, very useful, pretty much for more technical or competent bitcoiners to hold the hands of less technical people and their family or friends circle, and so on.  But, pretty much even the less technical people listening should know this.  You generate your wallet and you get your word seed and if you lose that word seed, all your money is gone and you're screwed.

Well, what BIP-0085 allows you to do is take a pre-existing seed like, say, mine and I can deterministically generate, from my own seed, a separate seed; and, there's no way cryptographically for that new seed that I just generated to ever be reversed back to my original one.  So, I can generate as many new seeds off of my main one as I want to, and any of those can be compromised and it will never be possible to take one of those child seeds and figure out my parent seed again.

So, just on a single person using this, this can be very useful, because there are so many wallets out there.  People who actively play around with, or spend, their Bitcoin are going to have multiple wallets.  Rather than have a bunch of different separate seeds that you don't want to lose, you can just have your one main seed and generate multiple other seeds off that.

So, I can have my cold storage and I can generate my hot wallet for Lightning, for Blockstream Green, whatever, and just import those.  And, as long as I keep my cold storage safe, all of the other wallets that I made off of it, I can just regenerate again.  So, rather than have to keep six different seeds safe, you just have to keep your main seed safe and all the other ones are recoverable from that.

I think that the really interesting thing here from my mind, and I want to be very clear here, that this is a risky thing; so, this should never be done, except between people who would trust each other with their life.  Do not do this with somebody who, for a fraction of a second, you think is not trustworthy, especially around money.  But, I finally convinced my parents to grab a little Bitcoin over the last few years, and they are some of the most terrifyingly technically incompetent people I could imagine existing.

With BIP-0085, I can take my word seed and generate a new one off of that for my mum and she can store her coins there.  And, as long as she doesn't pass her seed off to somebody else, or fall for a phishing scam, like if she loses that, I can just regenerate it and go, "Here you go, mum; don't do that again".  But, the risk is here, I can always access my mum's money.  She can never take the seed that I made for her and access my money, but I can always access hers.

So, in a small social setting, like really close friends or family, if you have that one competent person who can handle shit properly and everybody else around them can't, that person can kind of hold other people's hands if they trust him not to steal their money in that situation; so, there's no way to lose money.

Peter McCormack: Yeah, I mean the perfect example for me is my kids.  So, they're different ages but my son definitely has an interest in Bitcoin now.  He knows some basics, like he knows there are 21 million; he knows what I do; he knows of the name, Satoshi Nakamoto. 

He said to me a couple of times, like he came to me -- actually, I'm out of order.  He came to me recently when I gave him his birthday money and said, "Can I have it in Bitcoin instead?"  I was like, "No, don't worry about having a Bitcoin now, because this is your money you spend through the year".  This was back in April, right, so actually he would have made some good money off that.  And I was like, "By the way, when I die, you get all my Bitcoin anyway".

But actually, to be able to create him and his sister wallets for Bitcoin and to be able to educate them about Bitcoin, but for them not to be able to worry about the seed, which is something they could screw up, but just so they have a period of time; they're going to trust me, I'm their dad.  And then, when they're ready, they can obviously, at some point in their adult life, create their own wallets and transfer the Bitcoin out.  But, I can see that scenario working between me and my kids perfectly.

Shinobi: Yeah, exactly.  So, as long as there is trust in whoever is actually generating the seeds for people, I really think this is so underappreciated in terms of how powerful a tool this is for more technically competent bitcoiners to hold the hands of their friends and family, so that we don't move forward with shit tons of stories of, "Oh, I lost that.  What, I wasn't supposed to take a picture of that and upload it to iCloud?" and so on and so forth.

Peter McCormack: Yeah, that's pretty neat.  Okay, cool.  Well, listen, I think that's a lot of good tech stuff we've covered today; a combination of items which, as per usual, I don't think I will spend too much time on.  I will be trusting other people to do that work, and particularly things like MuSig; but, I am very excited about CoinSwap; I'm very interested with what's happening with Lightning; so, that's very interesting.

Just looking forward to 2021, is there anything else on the horizon that's particularly of interest or excitement?

Shinobi: Well, definitely, I'm going to lose my marbles if we don't get Taproot actually activated next year, so that hopefully.  But really it's just, I don't know, that question, I am not quite sure how to answer.  I can think of tools and software that I can see being built out, new advances in just really base-level technical stuff coming.  I think next year I think is going to be a very bright year for Bitcoin.

Peter McCormack: Yeah, well based on this year anyway, I'm very excited about next year.  I'm also quite excited about the fact that you're going to be helping me a bit more through the year; can we talk about that?

Shinobi: Yeah, you want to jump in and let everybody know?

Peter McCormack: Yeah, so based on the fact that everyone yells at me all the time for not being technical enough and not understanding enough, Shinobi's agreed to come on the show once a month to run through technical items, to give an update and for me to ask those questions like we've done today.  So, I'm very excited about that; we'll do a monthly show on that and that's going to be very cool, so I appreciate you doing that.

We do argue a lot, but I do think we appreciate where we're both coming from, so that's going to be cool; so, appreciate that, man.

Shinobi: I appreciate the chance, man.  I dove into making content in this space just to try and push information as wide as I can and I think you helped me out a little more than vice versa here on that front.

Peter McCormack: All right, well, sweet.  That will be good.  Every month, we'll get a show out; we'll cover the tech stuff; and, I think you're going to be mentoring me a little bit on the stuff I'm a bit shit with, so that should be good.  Well listen, look, appreciate you as ever, Shinobi, appreciate you coming on.  We've come a long way since that first fight when I was getting on a plane from Boston over to Hong Kong and, look, I appreciate everything you do.

Have a great Christmas.  You were pretty much the trigger for -- well, not pretty much; you were the trigger for my show going Bitcoin only back then and I'm glad I did it.  But, I appreciate you, man.  Have a good Christmas, Happy New Year and I look forward to 2021.

Shinobi: Same to you.  I plan on violating lockdown three times this holiday season!

Peter McCormack: All right, man, take care, see you soon!