This is everyone, this is the great Robin Linus who invented BitVM.

So, you may have seen BitVM on maybe a PowerPoint slide, or someone's pitch deck or something.

And, I mean, you know, I'm not going to say that all those slides are fake,

and that this guy is one million times more relevant than everything that those people ever do in their entire lives,

but it's something like that.

So, BitVM from last October or something like that, or September.

And I created this other thing, BIP300. It's also great.

But we're going to be up here talking about whatever you guys want us to talk about.

We got roped into doing this. What do you think we should talk about?

Well, thank you for the favor, guys.

My name is Michael B. Casey. I am Director of Engineering for Marathon,

and I architected a sidechain platform to try to bring some of the Drivechain stuff to fruition after all these years.

And, you know, of course, we always want to leverage.

I'm not out there like everybody else, claiming we've got it working,

but I want to leverage, if possible, BitVM for a more decentralized pegging mechanism or whatever else it could offer.

And basically what this panel is about, you know, to finish introductions, we have Robin Linus.

Do you want to give a quick introduction to yourself? Because Paul gave you a little bit of one.

Yeah, I came up with the idea of BitVM, and I'm working on that.

I'm implementing it with my team, and I'm also a big fan of sidechains in general.

I'm a big fan of the work that Paul is doing.

Maybe I should even add that BitVM is more or less just a workaround to enable something like BIP300 without a soft fork.

So it's essentially just a way to get around the activation drama.

Do you think that's possible in the near term? That's intriguing.

Oh, yeah, sure. I don't see any big obstacles from the technical side for BitVM in particular,

because now we have implemented that SNARK verifier in a huge Bitcoin script.

And that script is 3 gigabytes, which is, of course, huge.

But with BitVM, too, we can chunk it up into smaller chunks.

And as long as it's smaller than 4 gigabytes, we can probably run it on the main chain, actually.

And we brought it down to 3 gigabytes, which means that it will probably work.

Maybe something super surprising comes up, but currently it looks very good.

Cool. Well, when can we expect it to ship?

Yeah, good question. I was stupid and said four weeks just this morning.

Oh, no.

I hope my team didn't hear that. I don't know if they agree with that.

But, yeah, that's kind of like the time frame.

It is looking pretty good. We are almost finished, I would say.

And I think it's quite realistic to ship the first prototype within the next four weeks.

So for those watching who actually aren't familiar with BitVM,

I don't know who on the planet wouldn't be at this point.

If you want to give just a brief high-level description.

Yeah, that is complicated.

But I think from the most high level, the most important thing that I care about or that BitVM cares about

is both throughput and privacy.

Those are the most important things.

Because I think Bitcoin should be used as currency.

Bitcoin should be used for payments.

And for that it has to be cheap and private.

And so we have to scale it and we have to make it private.

And doing that on the main layer is complicated, in particular the privacy part,

because we would have to change a lot about the main layer to make Bitcoin actually really private.

And so what BitVM does is that it helps us to build bridges.

Essentially, BIP300 is also a bridge.

So just so it's not a roll-up-centric use case for the virtual machine, just to be clear about that, right?

Yeah, roll-up is one use case.

In general, it's about bridges to side systems, whatever those side systems are,

like sidechains, roll-ups, ZK coins is another protocol that I'm working on.

So it solves the Bitcoin is dumb problem.

Yeah, that is what the bridge solves.

Bridging Bitcoin to other systems that can be way more expressive

and that can do all kinds of things that the main layer cannot do.

Well, thank you very much.

So Paul here, Paul has created probably more sidechains, at least in theory,

than anybody else on the planet.

So how many would you say that you have actually set up?

Is it about quantity?

Like if I make enough sidechains, then one of them will be activated on Bitcoin.

So far, right?

I have made quite a few, and some are clones of altcoins, which I think is clever.

So we have a clone of the latest version of Zcash for privacy,

and we have a clone of the latest version of Ethereum.

And I have designed and built many sidechains,

and I think the sidechain is definitely the way that Bitcoin will scale

and achieve all these features that people want their money to have.

And in particular, anything that someone builds anywhere,

someone builds something into an altcoin or something else,

they have written the code, so it is theoretically possible.

And so why don't we just take whatever they do.

I don't know.

Did you have something specific that you wanted to know about the difference?

No, no.

I mean, it is just like I know you have quoted many times saying

the entire reason you went on this mission to create Drivechains

is because you wanted to implement Hivemind, and it was impossible.

Yeah, the prediction markets, yes.

I was interested in one specific thing.

However, the sidechain idea is much bigger than merely the prediction markets idea.

Prediction markets happens to be an interest of mine,

and I have this website, bitcoinhivemind.com,

and you can read to your heart's content about all that.

But really, sidechains, I think, are going to be necessary for Bitcoin's future

because we can't really live in a world where there is not enough scale

or where there is some other system that is actually meeting everyone's needs

for payments and for privacy.

So we don't want rival systems.

Scale is a very important point.

Yeah.

Network effects are very important when it comes to money.

So most people prefer to use the money that their friends are using,

and if something hits a scale ceiling and something else does not,

I do think that the thing that is limited will eventually be replaced.

So, Paul, how would you optimize a sidechain for scale, if that was your goal?

Yeah, I think I have written a post about this,

and I have produced the software also.

And I think you can push the, you know, there was this big block size war in the past.

I'm familiar.

It was very, very famous.

Yeah.

And it's actually not that, we're very, very close.

If you can do things like shrink the size of transactions, which is not that hard,

and then increase the block size by maybe two orders of magnitude,

so it's not quite unlimited, but it's not quite, instead of one megabyte,

we do something like eight megabytes that slowly grows to 80 and 80,

or 800 over like 10, 15 years.

And then the other thing you can do is you have 10, you can have multiple sidechains.

You have 10 that are sort of geographically distributed.

So you have some for Europe, some for East Asia, some for the United States,

some for like South America.

Because most of the people will be transacting with people who are, you know, it will clump up.

So I think actually if you do those things,

it's actually possible to process all the transactions in the world

using this sort of team of sidechains in a triangle.

And I have written a bunch of posts about that.

So if you go to this one website, Truthcoin.info, which is my blog,

I have a website, all the world's transactions,

and I have another one called Thunder, which is like a joke.

Do you have anything to add?

What would you want to see in sidechains of Bitcoin?

I want to see Bitcoin being used as the money of mankind.

I think we should all use Bitcoin all the time

instead of that fucking government money that is ripping us all off.

I think fiat is really, it's a scam, it's a form of cancer,

and we have to cure ourselves from it with Bitcoin.

So what do you consider actually really a sidechain?

I have my own definition.

But what makes a sidechain actually just not a complete scam to you?

I think it should have Bitcoin as its native currency.

That is the most distinguishing feature.

The other thing is it should probably have a consensus mechanism

that is anchored into Bitcoin as well.

By anchored do you mean specifically like merge mining?

That is one option.

What other options?

There is another option that is basically Bitcoin-backed proof-of-stake

where you stake Bitcoin in the main chain to become a sidechain validator.

I find that kind of interesting in comparison to other proof-of-stake systems

because other proof-of-stake systems, they try to secure themselves with themselves,

which is a bit absurd.

And here you have an external thing.

You anchor the proof-of-stake into Bitcoin's proof-of-work,

and this is how you resolve that absurdity of classical proof-of-stake.

Yeah, but the problem that I see with that is

that does nothing to benefit the layer 1 miners.

And to me, that eventually leads to rotten incentives for securing main chain.

Absolutely.

I think that's a very valid concern

that the miner incentives are getting reduced over time

by these layer 2s that do not use or that do not pay the miners.

And that's one of the reasons why I like BIP300 so much

that it actually takes into account the miner incentives

and pays the miners for the work that they are doing.

Now, Robin, last year when we met at this conference,

you weren't talking about BitVM at all.

You were talking about ZeroSync.

So what role do technologies like UtrexO and ZeroSync play

in making Bitcoin and sidechains more wieldy?

Yes.

ZeroSync was about applying snarks to the main chain

and essentially compressing the main chain

in a way that you can verify it on a phone or so,

or in general on weaker devices and weaker networks.

So full node on a phone, people.

I don't want to underlay the importance of what you just said.

So fully verifiable.

You can verify the validity of any transaction from your phone directly.

We have not implemented that yet.

The thing that we have implemented is more or less like an SPV client,

which is the basic version of it.

Proof systems have improved a lot in these two years,

and if we would start it from scratch now,

it would be much easier to implement a full chain state proof now

that actually can run a complete full node on any phone.

I think, to come back to your question,

if we had something like that,

we could probably also increase the block size with less risk.

That would be obviously a good thing for miners

because then we could have more transactions on the main layer

and more network effects.

So it's another way to decentralize

because there's less burden on nodes.

Well, yeah, and the same thing could be done for sidechains, too.

Make them lighter, more realty,

and then you could spread them across.

You've got multiple clients running on a single phone.

For sidechains, if you don't have BIP300,

it is actually a necessity that you prove the entire sidechain.

No, that's true. Yeah, okay.

Yeah.

That makes sense.

Because you cannot actually check what the state of the sidechain is

when you're doing a pegout, when you bridge back to the main layer.

Well, for bridging, yes.

But you could handle that with also SPV, correct?

Sorry?

Couldn't you handle that with SPV?

You can handle that with SPV to some degree.

If you would just have an SPV proof,

you'd create an incentive for miners to mine invalid SPV proofs,

just like a pegout that just didn't happen on the sidechain,

but gives the money to you.

Well, yeah.

You need it in order to mine, but not to transact, right?

I mean, it depends on what the pegout mechanism is.

If there is a dispute, it's possible to dispute.

Well, I'm talking about for just sidechain transactions on the sidechain,

not for pegouts.

I mean, the original sidechain paper by Blockstream had that idea, right?

Yeah.

That you use SPV proofs,

and they discarded that idea because of that toxic incentive

that a miner would just have to mine like some five blocks or so,

including one transaction that was just made up out of nowhere,

that doesn't have any history,

and it just gives the money to the attacker.

And essentially it means you can steal from the bridge if you have enough mining power.

And that is an issue.

And that is an issue that can be solved with SNARKs.

That's also why on the Adura platform we actually use a dual mechanism.

So it's not 100% informed, just only on proof of work.

There's also a federation consensus component that does reorg protection

and also validates via full nodes.

That's basically the same conclusion that Liquid came to, right?

Yeah.

Well, I mean, it's tradeoffs, unfortunately.

That's the best thing going.

That's why I'm hoping we can get there with better solutions like BitPM.

I honestly don't like that we have to run a federation.

It's just the best possible path now in order to get stuff shipped.

So, yeah.

It totally makes sense if you just want to go fast and ship something.

It's the best we have so far, and it works.

Back to the operative question of the talk.

What should we ship?

What makes sense?

What does Bitcoin need, right?

Maybe you want to talk about it.

I mean, I'm kind of repeating myself a little bit, though.

But, I mean, I have shipped a lot of stuff that I think people need.

If you go to LayerTwoLabs.com slash download, you can check it all out with plain money.

Yeah, which one of them should we do next?

We could talk about this.

Yeah, this is also this thing that I also came up with called the CUSF, the Core Untouched Soft Fork.

See, this is the thing is that the miners have not –

the soft fork is this great thing that has basically no downsides and innumerable upsides.

But for some reason, we have stopped doing it.

And so I've made it slightly easier to do, I guess is what I would say.

I mean, before, you'd have to do a pull request in GitHub to Bitcoin Core and have it merged,

which is like – could take years.

But instead, you can do the soft fork via its own little application.

It just rides along.

So I think that's a good idea.

I have shipped that also on this site, 5300cusf.com, C-U-S-F.

And then the sidechains that I think we need are these ones that I mentioned earlier in the day about scale,

scale, privacy, being able to mimic other chains that people like, such as Ethereum, assets, names.

I think all of that's important.

And I've shipped a lot of that already.

You can just try it for yourself.

So, Robin, I have a question just in general.

What would you say are the defining characteristics?

Everybody tends to lump all the VM stuff together, between like OP_CAT and Cat VM versus what's going on with BitVM.

I mean, I've been a big proponent of Cat until the Taproot Wizard started pushing it so hard.

I just don't trust these guys.

I don't see them as Bitcoiners.

I see them as like shitcoiners who are selling worthless tokens to people and like promoting spam, like audio notes and stuff like that.

And I see that as like the opposite of the stuff that I am interested in.

I don't think it gets us anywhere closer to beating the dollar.

So I got very skeptical of Cat.

But on the other hand, there are lots of people who are definitely legit, who are pushing for Cat now.

And it's a complicated topic.

I see a lot of potential in Cat.

I see all the things that we can do with Cat.

But I also see ways to abuse it.

And we have seen how the audio notes people have been abusing essentially Taproot to spam the chain.

I mean, as a miner, you probably like the fees.

What happened with SegWit and Taproot is just so ironic to me.

Because SegWit, none of this ordinal stuff would exist if it were not for the SegWit discount.

At all. Period.

And also for Taproot allowing you to inscribe 4 megabytes of data into the chain, right?

Yeah, again, unintended consequences. Very important.

My take on Eric and Udi, I think everyone has different skills or whatever.

I think they kind of like for some reason just took a guess that OP_CAT would be like the next easiest soft fork to do.

And so they kind of just got ahead of it.

I don't think they really even know or care that much about it.

How do you feel about OP_CAT, Paul?

I think the more important thing is that we have lost the ability to do the soft fork.

And so there's all these, like, you could refactor 10,000 lines of code and no one will care.

Or you could write tests on GitHub.

Or you could do something else.

You could do like, so like the Mac Corral's inflation bug was introduced as a result of a refactor.

There was really not a lot of discussion.

You can delete main.cpp from a C++ project and then put in the GitHub commit, this is real,

the lyrics to I Can Show You the World from Disney's Aladdin.

You can do all that weird stuff.

And you can accidentally cause inflation bug.

Or in the case of the level DB, the Berkeley DB, level DB,

you can cause the chain to actually crash and go down for like five hours.

Which is the only time that Bitcoin has ever gone down.

So there's many, many changes that are totally unscrutinized.

And yet, if you want to reactivate OP_CAT, which is an opcode that is already,

like, you know what I mean?

We've moved very, very far away.

We've been moving in the wrong direction culturally.

So like the whole reason the soft fork was invented back in 2012 is because we couldn't get everyone to upgrade.

So the soft fork is this thing where it's like, we don't need, this is a clever idea,

where we don't need everyone to upgrade.

Whoever wants to use the new feature upgrades, and then a 51% hash rate upgrades,

and it's safe for everyone to use.

Even people on the old network.

So we've had this idea of kind of tolerating conservatism while also allowing people to do what they want.

This kind of like, I don't know what you would call it, but maybe like a liberalism,

like a kind of live and let live thing.

And now we can't even do that because it's like,

So I think the bigger problem is just it's too hard to do any of these soft forks.

We mentioned Utrex-O, you get a mobile phone, full node on a mobile phone,

with the soft fork to have the Utrex-O commitment.

We could do the commitment to remove the need for the, whatever they're called, you know, the bridge.

We're overusing that word.

There's Relay, there's some kind of like secondary person that has to publish like a huge,

what do they call it?

I don't know.

Whatever it is, you could do the Utrex-O.

You could do, just forget Utrex-O, just any kind of Utrex-O commitment you could put into Coinbase.

And this would have some utility, you know, to a lot of, to like many, many people

because most people use SBB or something.

You could say, well, but no one wants to even talk about doing any of that.

And then you have what happened with CTV where Jeremy Rubin not only quit CTV,

but he quit Bitcoin until very recently.

Came back in multiple years.

Now he would spend multiple years away from Bitcoin.

He had to grow a beard.

It happens.

And he has shaved the beard, so now he's fully back, I guess.

He still has that mustache, though.

And APO was created as a lightning bit.

It checks all the boxes, right?

It's a lightning bit.

It was made by the right people.

It was on Signet.

I mean, it was on Inquisition or whatever.

So it did all these things.

It's many, many years and they're not pushing it, I think, just because no one knows how to do any soft fork

and no one wants to touch the soft fork.

So I think that, so you say, what do I think of OP_CAT?

It doesn't matter.

The soft fork category is the issue.

It's the soft fork part.

And that is why the CUSF idea, actually, I think, is the good idea.

That is C-U-S-F.

One thing that I'm concerned about is this general crackdown on crypto from governments.

I'm not sure exactly how it is here in the U.S.

I think Elizabeth Warren is trying things.

But in Europe, it's quite extreme.

Like the EU Parliament is going quite crazy on crypto and seeing these things.

I get a bit concerned about adding too much features to Bitcoin's script

because one thing that could happen is that at some point,

governments say that you cannot take your money from exchanges

except for to addresses which are fully KYC'd.

Yeah, that's very scary.

If you can impose that restriction at the protocol level, that's very dangerous.

And like perpetual KYC on the protocol level would be already almost possible with OP_CAT.

It's a definite concern. That could happen.

A handful of opcodes that are currently debated would definitely enable

essentially perpetual KYC on the base layer.

So like CTV, that's not a concern with CTV.

You can do that one time, but you couldn't do it recursively, right?

You need more dynamics. CTV would be too static.

But with OP_CAT, you could have like trees,

Merkle trees of addresses that you are allowed to send to.

And then let's say you have Opcheck from stack as well.

Then the government could sign routes of Merkle trees of addresses

which you are allowed to send to.

And OP_CAT would give you enough covenant introspection to check which amounts you're sending and everything.

There's no risk of anything like this with BitVM, right?

Well, BitVM in general cannot enable anything that is not possible already today.

There are always ways to abuse things, right?

In general, the entire community of bad people has not spent a year

of trying to do the worst with BitVM possible.

It just did not happen yet.

So we don't know the worst thing that can happen with BitVM.

And there's always unintended consequences.

There are always unknown unknowns.

I'm not sure what's the worst thing that BitVM can do,

but I'm very certain that a particular set of opcodes could enable very bad things on the main layer.

And the other thing is many of the new users like Blackrock

or the people with huge pockets,

they would not care at all if the base layer would enforce KYC all the time.

They would be happy about it.

They think regulation is a great thing and they just want to have digital gold

and they would not care if everything would be KYC all the time.

They would be happy about it.

Is there any hope now for just general Lightning as a scalability layer of Layer 1 Bitcoin?

I don't really see Lightning working as a scalability solution for end users.

And in particular, when fees are rising, and we hope that fees are rising to fix...

Fees have to rise eventually.

Otherwise, the miners will stop getting paid and the whole thing collapses.

And if fees are rising, then Lightning will become worse and worse for end users.

And to some point, it will not even be possible to enforce users' rights anymore

because you have to be able to pay on-chain fees to enforce your channel's rights.

Now whenever I hear anybody talk about Lightning, they talk about it as a settlement layer.

It's hilarious to me because seven years ago,

that's the way everybody started talking about Bitcoin.

They said, oh no, you'll use Lightning for payments.

No, no, Bitcoin's a settlement layer now.

So now we've come full circle and it's just settlement layers all the way down.

Yeah, I don't like that either.

I like Lightning in general.

I think it's a great technology, but it does not work for payments for end users.

Yeah, it's not a scaling apparatus.

It does a lot of things really, really well,

but scaling isn't one of them because of the fee problem.

You want to add something?

No, I agree completely with all of that.

I'm not sure that I would care so much about the...

I do actually think it's a...

I agree that we shouldn't add too much expressivity to L1

because it is possible to make really bizarre...

But I think that problem would actually solve itself

because it's quite possible to add functionality via soft fork,

but it's also very easy for miners to chip away,

like carving a marble statue or something.

It's pretty easy to go back in and just start disabling things.

So if something problematic arose,

I do think it would be easier to just delete, you know what I mean?

Like what Satoshi did when he removed OP_CAT.

What's the hard fork?

Well, that was only a hard fork, I think, as I understand it.

It was because that was the same commit that he added the opnops,

and the opnops are the hard fork.

So I think he tore out a bunch of...

He just said these are all banned,

and then the opnops are all new, and they always succeed.

That's what I remember, right?

It's kind of a minutiae thing.

Really?

What do you mean by that?

Well, it was certainly a hard fork

because he disabled something that was possible before.

So soft forks, I think Paul's right.

With soft forks, you can restrict functionality.

You can't expand functionality to prior nodes.

You can soft fork anything out of existence,

so you can't do that anymore.

That's how it would work if it contains OP_CAT.

Yeah, you're right.

So it would be interesting to have an old consensus.

We want it with OP_CAT still.

The old version of OP_CAT, but it's not tap or the dangerous one.

Oh yeah, there's a new...

There was some details about that.

It was a hard fork in the sense that it became incompatible.

Like the version that was before that fork is not compatible.

A soft fork is usually defined to be backwards compatible.

That's what I meant.

It's funny that I actually wrote a blog post

about how the terminology is screwed up

because there's actually three different dimensions

to whether or not something is a hard or soft fork

and people constantly switch between them.

And there's backwards compatibility,

and then there's whether or not it resolves itself

without the user having to do anything,

and then there's something else like whether or not

it is restricting the user.

But yeah, the terminology is actually terrible.

But the point that I was trying to make is that

if you add something terrible in,

you can probably get rid of it pretty easily.

So I wouldn't really be that worried

about the unintended consequences of adding the functionality to L1

because there are unintended consequences to just doing nothing.

I do think we would probably both agree

that we cannot just spend another ten years

doing whatever it is that we've been doing for the last ten years.

I think that is not good enough.

So let's talk more about Core Untouched Soft Forks.

Do you have a question or anything?

Yeah, I can try to give you a devil's advocate there.

Yeah, sure.

Yeah, please.

Okay, so do you want to give miners the power over the network now?

Is it now like a miner democracy

where it is decided by the people who have the most hash power?

Yeah.

The flip side of this is

do people actually really believe in proof of work at all

or is it just going to be some kind of communist bureau

that decides everything that happens?

But I think the miners have a special ability

over the activation of a soft fork.

And I think this has always been true.

And CUSF doesn't really change it, I think.

I think that it just states it more clearly, in fact.

So this is just...

There's a difference between when does something activate and how.

And then it will only really be part of the protocol

when lots of end users' nodes are enforcing it.

So I think those things are not really that different about CUSF.

The CUSF thing is just a very, very small idea

that's just about in what order should things happen.

And so it is about right now there's like a pocket veto and there's just like no one knows how to get the process started.

And no one knows who's responsible.

Generally, it's just safer to do nothing, right?

That's what it's viewed as. But I mean, if you do nothing for long enough, then there's a problem.

Then, you know, eventually you die, right?

But in the short run, it's always safer to do nothing, right?

So that's, I think, what the default is.

But exactly as you said, in the long run, if you do nothing, you will die.

So I don't know if that answers it.

The idea of giving more power to miners, it's like the miners are users.

So with the soft fork, unless you upgrade to the new software, you cannot use the new feature.

That's pretty normal.

But if the miners want to collect the transaction fee, they also need to be users of the new feature.

So it's just like people adopting software that they like.

It's not like some kind of...

They have no additional power over the protocol that was pre-CUSF, which is 99% of it.

So if I understand you correctly, miners just don't get much more power with the CUSF in comparison to regular...

I think it's a status quo. It's just a different way of describing it.

I think it's just a different way of describing the status quo.

The miners could always be the ones who...

They could be on GitHub releasing the next version of Bitcoin Core and then running it, right?

They could do that, but they just don't.

But there's nothing fundamental about that, you know what I mean?

That's like an ad hominem fallacy of the...

Actually, I wanted to play devil's advocate, but you didn't mention a very important point that I think you should add.

A strong counter-argument is, should we give the core devs the full power?

With the Communist Bureau, I was referring to them, so maybe it's a little too subtle.

But yeah, it's like someone is deciding, and right now they decide mostly what impresses their friends.

Really, though, that goes back to the definition of Bitcoin and continuity.

And it's like the core devs, even the core devs that exist now,

almost none of them are the same core devs that initially put SegWit through.

I think there is a very bad incentive, actually.

The miners have a very good incentive to keep the users happy and to generate transaction fee revenue.

They want... The more users, the more growth.

These are real users who pay real money.

We're going to need transaction fee revenue, because the block reward is going to keep going down.

It's a very good criterion to say, can we maximize the amount of money collected?

And whereas in Bitcoin Core, I don't know, the incentive is something else.

The incentive is like, can you come up with something really complicated that's very impressive,

and then you get a grant or whatever, or you get something.

And so I think that it is...

So it's just like everything else, it all boils down to incentives.

Maybe you could also say it takes away unwanted pressure from core devs,

because I feel like many core devs don't want to be the rulers of the system, not at all.

It's more like they shy away from controversial ideas.

Especially nowadays, I think.

Well, that's the impetus on them to not push it for any soft fork,

because then there's nothing controversial for them to have to deal with.

It kind of removes politics from core.

But I mean, it removes politics...

As we mentioned before, the story with APO is like, this is one where...

Built by them.

Built by the insiders, basically.

And the lightning thing, but they don't want to touch activation because they just don't...

Well, yeah, it wasn't built by...

Maybe some people would be so...

Can you tell us, is it?

Well, yeah, I'm just saying it's like from Bitcoin core universe,

from the Bitcoin dev mailing list, from the lightning universe.

But even that one is not...

That one, they just coded it, and then it just sits there on a shelf, being not activated.

So...

I see your point about they don't want the politics.

Yeah, I'm just saying it might be good for them.

It might be diminishing their role, but giving them the role that they actually want.

Well, sooner or later, decisions have to be made about what's going to be done.

It's nice to work on projects for years that have minorly meaningful optimizations,

but eventually, either things are going to stay exactly the same they are now,

or they're going to have to change, and they will be.

I don't know, it's just getting to the point where I'm not seeing anybody asking

and trying to actually take up these issues at my core level.

They just kind of throw up their hands and say,

oh, we'll decide when we have consensus.

And we never reach consensus because nobody's tackling anything.

I don't know.

Here's one thing about CUSF, though, that probably the both of us like,

but maybe you don't.

It does push some of the responsibility onto the mining pool, such as Marathon.

So it's like, you guys can just decide now if you run the software or not.

So now, you can just say, ah, there's no consensus or whatever,

but now it's your decision to make, not yours personally.

Marathons, maybe.

Well, there is something to be said to have somebody to appeal to,

as we do in the current system.

Yeah.

You know to whom your grievance should be addressed.

That is an advantage of this, where it's like,

you know that the answer is no until 51% pools say yes,

so that you at least know where you are.

I actually had an idea.

I published a little stupid Medium article way during the block size war,

and I always wanted to see if it would work.

What if you created a wallet that tracked actual transactor sentiment

as to whether they won or something by the amount of transaction they spent?

So that way, the miners could tell how the people who are paying them fees

actually think and feel, rather than Twitter.

I don't know.

As a miner, you could actually measure it, right?

Because as a miner, you see how much of these fees you actually get yourself.

Right.

It's distributed kind of randomly, but yeah.

But that is the point.

Because otherwise, the metric could be gamed.

If another miner that has a lot of hash power would just game the metric

by inserting transactions that pay themselves,

then you would never get that, and then you would not get that signal.

But money that is paid to you is no lie.

Nobody can lie about that.

So that is a very high signal.

Exactly.

Because if you're only monitoring things you know that cannot be gamed.

Unless people want to pay you money, in which case you don't care if it's gamed or not.

They're paying you money.

I think another interesting thing is that it's actually not possible for miners

to activate arbitrary soft forks.

Let's say the miners wanted to activate a soft fork

that increases the block reward or something.

Then users would resist that a lot.

So the incentives for miners are aligned to activate soft forks

only if users actually support it.

They have very low incentive to try to push a soft fork against the user's will.

And I feel like in that regard, the incentives are quite well aligned with CUSF.

Thank you guys.

It's been a wonderful panel,

but I think we should try to take some questions from the audience if possible.

Oh yeah, sure.

Ask any questions.

Don't be shy.

Ask a question.

If you want.

Okay, thanks.

Nobody was expecting, well, maybe nobody,

but the whole Ordinals improvement to DRC-20 is part of that.

And I'm detecting the feeling that the core community is not going to want to see

something go off the rails again.

There's an obvious question about that.

Couldn't we see like two or three years of ossification here

before a new BIP really got approved?

I actually think that Ordinals is a negative consequence of ossification.

So it's actually if we had had normal progression in development

and also normal developer community that actually cared about

what the end users who pay a fee, those are the real customers.

If the developer community actually cared about those people,

they would have long ago built something or promoted something that worked for them.

And we could have solved all the earlier problems.

So like Counterparty was like a very early version of this.

Everything that was on an altcoin was originally on Bitcoin,

like years ago in like 2011, 2012.

So like all this stuff, Ordinals, Runes,

it's like almost an offshoot of ERC-20 on Ethereum,

but that was an offshoot of Counterparty and colored coins

and all this other stuff that's ancient on Bitcoin itself.

But what happened was in Bitcoin,

the developers have a lot of contempt for the user.

They have a lot of hatred for the user,

and they don't want to build something that the user likes.

And so Counterparty and these other things were suppressed,

partially for good reasons, because they did have negative...

But the point is if you actually put engineering effort

and human creativity into that,

you could address what didn't work

while still giving the end user what they did want.

And so if we had done that,

there would never have been an Ethereum in the first place,

and there would never be any Runes or Ordinals on L1 either,

because everyone would already have gotten what they wanted 10 years ago.

But instead, we have this weird other thing.

So I kind of don't think it works that way.

And I do think Ordinals and Runes, again,

this is another thing where it's like

you can't get the thing that you want directly,

so you get it very indirectly

at a way that is interfering with L1's normal operation.

So I have a very different view on that.

I don't know if you share that view or not.

Yeah, I totally agree that Ordinals is a symptom

of mainchain fees being too low,

and that is a symptom of the system not being useful enough,

and that is a symptom of the system not being scalable enough.

So in that regard, I totally agree.

I think it's a distraction.

It kind of distracts the Bitcoin community

from the actual core goal that we should have,

which is establishing Bitcoin as a currency worldwide.

But yeah, maybe in hindsight,

it was a good thing to shift the overtone window,

to change the discussion in different directions

and make people think about other things.

I agree that it is.

The whole topic kind of is a distraction.

The one good thing that came out of it

was that there was so much ossification,

and then Ordinals and Runes were like someone doing something new

and something fun, and people actually liked that.

So weirdly...

Anyway, feel free to ask anything else.

Ask a question, everyone.

Some critics of Bitcoin under its chain

say that it's caused deep reworks,

and the miners are stealing the sidechain

and using it as an opportunity for merchants to prevent that.

Is that a deep rework?

Yeah, that's just like incorrect,

and it's kind of like a weird thing that people think about that.

But what would actually happen in the timeline of events

is like miners preemptively declare

that they will destroy the BIP300 sidechain,

and then users preemptively declare

that they will not allow that transaction in the block in the future.

So nothing has happened for many months.

Like three months later, there will be the moment of truth

when the transaction tries to make it into the block.

At this point, anyone who has voluntarily,

who is already a user of BIP300,

who has voluntarily decided to UASF the transaction,

this is already like a much smaller percentage then.

Everyone who is just ignoring it completely

and going about their lives, nothing will happen to them.

But these people, if they were using BIP300 sidechain,

and they tried to do the UASF,

and the miners tried to destroy the chain,

and the miners are successful

in attracting 51% hash rate to their cause,

and they're not deterred at all by the fact

that they will lose the entire stream

of transaction fee revenues and blah, blah, blah,

no one stops them.

If all of those things happen,

what will happen is the people who do the UASF

will just be stuck in a chain that never finds a block again

until they give up.

So there will never be a reorg ever under any circumstances.

And the only thing that will happen is that people who have chosen to...

The other thing I would mention is that actually the UASF

is a contradiction because despite the name,

it must either be a hard fork or it must be driven by miners.

So if you have a situation where the user has minority hash rate,

they are then breaking the heaviest valid chain rule,

which is in principle no different than breaking the 21 million coin limit

or the block size limit.

So they're breaking the heaviest valid chain rule in one specific way.

It also has the same property as a hard fork

in that only the people who have done this activity

will find themselves on the new network.

Everyone who's doing nothing,

which is going to be 99% of the people,

will just be doing nothing and ignoring all of this.

All of those people will find themselves on whatever the heaviest chain is.

So there will never really be a reorg.

And if there is, it's just because people have decided

that they want to reorg for some reason.

You know what I mean?

Like they could always just decide,

I don't like this block has the hex spells out a certain thing

and now we want to reorg or something.

It's not really...

The other thing is that risk of reorg is always a part of Bitcoin anyway.

So it's in...

There's no such thing as like being free of the risk of a reorg.

So even in that case, it's not because of BIP300.

To cement his argument,

just to spice up the discussion a bit,

it is definitely true that BIP300 would change the miners' incentives

in a sense that if 51% of the miners...

60%? How much is it?

75.

If 75% of the miners would collude

and decide to rob a sidechain,

they could just do that.

They could just vote to process an invalid pegout

that gives the money to them,

stealing all the money from the sidechain users.

And that is true.

But that would not change the layer 1 incentives, right?

Right, exactly.

So that is true that the sidechain can fail that way,

but I see that as actually sort of a good thing in a way.

The whole theory behind Drivechain is that

the transaction fees from the sidechain

will be more than enough to offset whatever can be stolen.

And the reason why this is likely is because,

first of all, no one will use a sidechain that doesn't have that property.

It's kind of like if you open a restaurant.

Will the restaurant make enough money

so that you don't rip out the copper wires and the piping or something like that?

Start a restaurant and not every restaurant is going to succeed,

and that's actually a good thing.

That is how we make sure that the list of sidechains is only the good ones.

And no one should use a sidechain at first.

You should just wait and see if it is actually viable first.

But the turnover and the stock and the flow are different things.

So you could deposit like 2 Bitcoin to a sidechain,

and over there, there could be this huge turnover

so that millions of people are using it.

They each pay a tiny transaction fee,

and 1.5 out of that 2 Bitcoin ends up as transaction fees for the miners.

There's only 0.5 left.

But you got an unbelievable amount of use out of it,

millions or trillions of people.

Just maybe as a thought experiment,

I would bring up like you put two coins into a desert island

that has two gold coins.

They can circulate like a million times.

So the fact that there's only two coins on the island,

it doesn't mean anything about the limitations.

So the reason I bring that up is just to say

the two coins, that's what the miners can steal and destroy.

But what they have to gain is potentially much more than that.

But essentially it's a change in the sense that you can say

if someone has enough hash power, they can steal from the sidechain.

So there would also be an incentive to collude.

Yeah.

Well, I don't know about it. Maybe.

If so, if they destroy all the sidechains,

we'll just be back to where we were now.

So again, it's kind of weird if that's considered a change.

We'd be changed, just changed back to where we, the current status quo.

I think we have another question.

Yes.

Hey.

It's been a long time.

Excuse me.

I'd like to hear your expert opinions

on how it relates specifically to Drivechains

and also VPN.

Can you answer it?

Yes.

In case someone in the chat did not get to know us.

Like, do you like how it relates to the work with VPN and Drivechains?

I see you're wearing their hats.

Are you in their team?

You're just a fan.

Okay.

I didn't have time to really look into it.

In particular, BitcoinOS,

I think they have not open sourced their code yet,

which is hard to assess then for me as a developer.

I mean, I know the people behind that.

I know they are doing interesting things.

But I cannot say right away how good it is.

Of course, I'm super psyched that people are working on it,

that people are investing developer resources

into building BitVM kind of like things.

That's cool to see.

I'm, of course, very happy to see my child grow.

But I would be careful with these things.

Like, it's quite easy to announce something

and it's really hard to build something

that actually works in practice.

The other thing is, as far as I know,

they are using the BitVM 1 model.

zk-SNARKs.

Yeah, zk-SNARKs.

But it's not true?

Sorry?

It's Google.

Ah, okay.

Yeah, they're using the BitVM 1 model.

And that was the same model that we started out with.

However, we came to the conclusion

that it's quite hard to build efficient bridges with it.

Like, to verify a snark is the one thing,

but the other thing is to actually use that snark in a bridge

to bridge Bitcoin to other systems.

And our conclusion was that BitVM 1 is a bit too complex,

or BitVM 1 bridges in particular are a bit too complex.

And that's why we went back to the drawing board

and reconsidered everything

and came up with a BitVM 2 design that we are working on right now.

And that is definitely...

Four weeks!

...that we will hopefully release within the next few weeks,

the first prototype version of it.

Let's get one more question.

My question was to Osbert.

Why don't you go directly to banks to get Bitcoin?

No, that is...

In a way, CUSF sort of is doing that, in a way.

The miners, though, are like, you know,

they're just committed to just, like, blah, blah, blah,

saying, like, we'll look into it later, or whatever.

Even though it makes them hundreds of billions of dollars in the future.

But I think that that is the healthier thing,

because...

But the miners are very interested in, like...

They have, like, a focus on just getting cheap power.

They're, like, very narrowly focused, I think.

They're not really...

These things are like a palace affair to them, or something.

It's like it's...

Maybe you know, like...

So, like, in a way, I...

Okay, yeah. Do you have something else to say?

Okay.

One thing is, of course, they risk a chain split.

Like, if somebody were to use a resisted soft fork,

then the chain could split.

And in general, I think miners don't want to see

any funny business in that direction.

And that's why they're hesitant.

You just say you want to enforce it

until there's a super-majority hash rate.

I mean, that's like a solvable problem, right?

Then you will never get the actual split.

Only the user-resisted...

Again, that's like...

Again, this is really...

The UASF really is a hard fork,

because you just put yourself on your own network

with whoever else is running the new software with you.

It's the threat of a hard fork.

Yeah, yeah.

So, I think that's a very, very, very, very empty threat.

It's very silly.

But maybe. I don't know.

I think, in general, just a lot of people

have to wrap their heads around a lot of things.

I don't have an answer for you.

I mean, I think the miners should do it,

activate it unilaterally.

They should activate all these soft forks unilaterally,

which they can't do easily.

Microphone.

Oh, sorry, Eric.

Yeah, because of the fact that

consensus rules aren't enforced by

node-runners and the economic acquisition network,

the miners are going to be just trusting themselves

to not kind of...

Hey, we're going to kind of back out of this.

Yeah.

We might start not applying...

But first of all, that's very likely to work.

And second of all, it's not strictly true either,

because as soon as someone else runs

the same software that's enforcing the rules,

you have, like, all the miners plus one person,

and you have...

The miners have no way of knowing

the exact date and time that Coinbase

or some exchange decides to actually run.

So it's actually...

Even if it was only miners,

it would still be likely to work,

because the miners have no real way

to defect out of the coalition

without stabbing each other in the back

an endless number of times.

But then they also don't know

who else is enforcing the new soft fork rules.

So I don't actually...

I think that would...

Even that, which is a very, very, very extreme

way of activating the soft fork,

I think that would work just fine, actually,

if you actually made me guess.

Iago? Yeah, we got something?

So this is pure hearsay.

I just looked up, and so you guys

don't get any surprises.

You have the...

He was asking about it.

Hey, you have the hats.

Just asking about the news.

I'm not saying to be careful

about any BitVM things.

I think I said explicitly

that I'm happy to see people building

BitVM-like things.

I just said I'm careful about announcements

when I don't see the code.

We have a tech talk

on the open-source stage tomorrow.

We also want to provide

a deep dive into

growth. We were thinking about

doing it at the Dare to Growth

tomorrow night.

Can you get this work out?

I know the other announcement

from Rootstock.

Also, full disclaimer,

I like the guys from Rootstock as well.

I think they're doing interesting things.

They have committed

interesting contributions

to our code base as well.

Unfortunately, I didn't have time

to follow the announcement because I was traveling.

What I saw was

that they said they're ready.

There were a couple of questions.

They said they're ready

except for these two things

and some minor other things.

I see the marketing point of things,

but on the other hand,

I think

having things that

are useful to people in practice,

that is what we should be about.

Whoever does that

first should have

the glory and the honor.