Hello, good morning, guys. How are you guys doing? So yeah, many of you guys might be

familiar with what I do. I work mainly on a software project called U3XO. It's by Tad

Stryza, who's right there. But today I won't be talking about that. Today I'll be talking

about the hardships and the things that we go through when we work on an implementation

of Bitcoin that is not Bitcoin Core. So these are my slides. If you scan the QR code or

go to the link, there'll be a bunch of links. There'll be a bunch of evidence of my complaints

about Bitcoin Core on the presentation. So if you would like to follow along, do scan,

and then you could take a look at it together. Yeah, so for me, you could take pictures of

me on the stage. The only thing that I ask of you is that the picture you post on Twitter

look nice. That's the only thing that I ask. And so, okay, let's get started then. So BTCD,

this is the software projects that I stumbled upon being a maintainer of now. And so BTCD is

essentially just a alternative implementation of Bitcoin Core. Bitcoin Core, as you guys might know,

is a reference implementation of the Bitcoin protocol, of the Bitcoin spec. So if you run

Bitcoin Core, that is essentially Bitcoin. But then if you take those rules and just implement

a different software project, it's like, yeah, you could theoretically do that, right? And if you do

that in the Go language, well, you get BTCD. So that's what BTCD is in a nutshell. Not many people

really know about BTCD, or if such a project exists. So today, can I get a show of hands on,

like, if you've heard of BTCD before? Oh, quite a decent amount of people. Okay, cool.

But I wanted to sort of share, if I go to a conference like Bitcoin Magazine conference,

and I introduce myself as, hey, I work on BTCD. Usually, they'll be like, oh, what is that? But

then they'll be like, yeah, I know what you do. You work on the Bitcoin dominance, right?

It's like, yeah. Or in Hong Kong, there was a guy that I was talking to. I was like, yeah,

I work on BTCD. And like, you probably don't know about it. But then it's like, yeah. Oh,

like, how do you know about BTCD? Oh, it's that stablecoin, right? It's the BTC dollar. So there's

a bunch of other projects like this that I had issues with, I don't know, like little miscommunications

with. It's like, oh, you work on Bitcoin Dark, you work on Bitcoin Diamond. And then I was Googling

and I found this thing called BTCD. I think it's like a crypto credit card or something.

But anyway, no one really knows about BTCD. And in this presentation today, I would like to sort

of go through why I work on BTCD and why I work on BTCD is like really simple. I just, I hate C++.

That's the only reason. That's the only reason that I work on BTCD. No, it's not the only reason.

But I really, really don't like C++. And so that's my personal reason. But there are other sort of

philosophical reasons as well. And I want to quote someone of a higher reputation than me,

which is Roastbeef, the CTO of Lightning Labs. And how Roastbeef, or Lalu, views BTCD or Bitcoin

is that, you know, Bitcoin is an idea. It's not a software implementation. So Bitcoin Core is a

reference implementation, but Bitcoin Core shouldn't be Bitcoin. So that's how he feels about it.

And this is what a lot of others feel. This is what the people that work on BTCD sort of feel

about Bitcoin. It's like, hey, like, Bitcoin should be a thing that we could implement,

and we could have multiple implementations. It's just an idea. It's not C++ code that is Bitcoin.

So yeah, so not many of you guys know about BTCD. But this is one of the things that I want to point

out today. BTCD is a weird software project, because you don't know about it. Not many people

really use it. But it's very, very influential in terms of the entire Bitcoin ecosystem, because

a lot of the Lightning Network depends on code from BTCD. How many of you guys remember the

the unfortunate segwit bug that happened a few years back that crashed the Lightning Network?

And so, yeah, so it's very influential. If we screw up with BTCD, then we screw up with a lot

of things in the Bitcoin ecosystem. But so yeah, I'm going to get into the main meat of my talk.

I want you guys to take two things away. First thing that I want you to take away is why

alt implementations are difficult. Who else works on alt implementations here?

Oh, yeah, I got some people, yeah. And I do want to also sell you on BTCD itself. Like,

why should you give it a try? Or why should you look into it? Why is it worth your attention?

So first things first, why are alt implementations hard?

More or less, yeah, Bitcoin Core's development process treats Bitcoin Core as the only

implementation. I quoted myself. You can take a picture. It's okay. You can post it on Twitter

for fiery memes. We could have a fight on Twitter online. But yeah, so Bitcoin Core,

when I don't think the devs are malicious in this, it's just that it's not on your mind.

It's like when you're working on a protocol change, or when you're working on something

even like minor, whatever, like, it's just not on your mind. And that's, I think that's totally

understandable. If I worked on Bitcoin Core, I would probably do the same thing. But this is

the reality of things in that, hey, like, the development process doesn't really pay attention

to these other implementations or doesn't sort of, I don't know, like, care for them. So

I want to give you guys two examples of these things. The first example happened a few years

back. It's by Nicholas Goiga. And the disclosure, BTCD consensus bugs due to the usage of signed

transaction version. So this is one of the bugs where to validate some rules on Bitcoin, you had

to typecast from signed integers to unsigned integers. And Nicholas, in this Bitcoin Delving

Post, sort of points out that, hey, like, it's BTCD's fault for not doing this typecast. Like,

you should have done this typecast. It's written in the BIP specification. So you should have done

that. But in reality, you know, it's like, no one really knew about this rule. So I want to point

out, it's like, hey, like, prominent Bitcoin developer, Gregory Sanders, said, hey, what? I

have no idea that we should treat it as unsigned. Like, we have to, like, cast it. So this rule

that supposedly BTCD couldn't bother implementing is a rule that is not known to prominent Bitcoin

core developers. So there's two BIPs for this. There's BIP 68, and then there's BIP 112. So in

the BIP 68 specification, there is no mention of the typecast that you have to do. So this is a

screenshot of BIP 68. And nowhere in the specification is there any mention of this

typecast being done. So how can you say that, hey, this is a BTCD bug? It's not a BTCD bug.

It's a BIP bug. So there's this section for specification, and it mentions nothing about

this typecast. You have this other section. It's very small. But you have this other section called

implementation. And in this implementation, if you look there in the very bottom, oh, okay.

Well, anyway, if you look at the implementation, we're back. Yeah, nice. But if we look at the

implementation here, it's like, yeah, we should cast it. So it's not in the spec. It's in the

implementation. It's just C++ code on the BIP itself, and you have to go through and read these

tiny implementation details to know that there is a typecasting to be done. So this is BIP 68.

What about BIP 112? And BIP 112 situation is basically this. It's like, hey, like, we should

totally write a specification about typecast. This is very important stuff. We should probably have

it, right? So BIP 112, I'll give them credit. They just sort of skipped the writing up a

specification and just slapped the code on there and called it a specification. And if you look

there, yeah, there's a cast. There's no comment on that you should cast. But there is a cast.

And this is very frustrating. Because, hey, like, these are important consensus rules that alternate

between the two. And, like, these are rules that implementations have to obey. And if you document

it like this, then how are you going to obey these rules, right? And, like, other prominent Bitcoin

developers share this frustration with me, right? This is HL. This is HL looking at the CTV BIP and

saying, hey, like, this is just C++ code pasted on to the BIP document. It's like, we shouldn't do

this. It's like, if you don't know C++ code, how are you going to implement it? I totally agree.

We shouldn't. We really shouldn't, right? But in, like, these BIFs, in these older BIFs, it's like,

yeah, like, we just slap on C++ code and call it a day. And if something goes wrong, it's a

BTC debug. And that has been frustrating. It's not like BTC is perfect. Like, there's the lightning

bug. And that one just, like, it's just screw-ups by the BTC people. But, like, stuff like this,

it's very annoying. How are you, like, I don't know. Like, Greg Sanders doesn't even know about

the rule. So, it's like, yeah, what are we doing here? So, this is the first example. The second

example is much more recent. This is a recent PR that I had on BTCD. And the, if I were to

summarize it, the Go library, it wraps IPv4 and IPv6 addresses. And this is so that for if you

have a computer that's dual stack and if you want your IPv4 addresses to be read, it's just in the

IPv6 form. The top, I think, is just filled with Fs. So, this is how the Go library by default

deals with it. And so, that's how addresses are just parsed in the Go standard library. But it

turned out that Bitcoin Core doesn't do this. This is, oh, I'm sorry. This is specifically for

a the P2Pv2 protocol. You guys, show of hands if you're familiar with P2Pv2. Okay. So, P2Pv2 is

just the new encryption protocol for the Bitcoin network. So, when you're sending and receiving

messages instead of being unencrypted and showing your ISP everything that you're doing, we

encrypt it so that they can't see what you're doing. But in this P2Pv2, how we share addresses,

it's just you can't wrap, you can't do this IPv4 wrapping and IPv6. So, was this written in the

BIP? So, P2Pv2 is BIP 155. It's very recent BIP. Is this in the specification? No. It is not in

the specification. I did this, like, search thing. Is IPv4 embed not? No. It's, like, nothing. It's

not in the spec. It's not in the BIP anywhere. So, how are you going to find it? It's just in

Bitcoin Core code. You go in, I forget what file this was. But you go in, look there, and it's,

like, oh, we shouldn't wrap IPv4 addresses. Or we shouldn't embed them in IPv6. So,

that, so you have to go look through all this code to find this very, very important detail

about, like, being able to synchronize and work together. And it turned out that because of this,

Bitcoin seeders were dropping BTCD nodes. So, if you had a Bitcoin seeder running,

even if the BTCD node was good, it would just drop it. Because we were wrapping it.

We were embedding IPv4 and IPv6. So, this is, I will not take credit for this. This was from

a coworker. And this is the chat that I had with the coworker. I was, like, is it implemented? No,

I hate Bitcoin. It's, like, of course it's not. Naturally, like, very important specification

details are not documented. You have to go look in the code. And this is the most frustrating

thing when you're working on an alternative implementation. It's, like, oh, you can't take

a look at the BIP and be okay with it. You can't trust the specifications. You have to go look at

the code. You have to test things against Bitcoin core. And we talk about, like, Bitcoin core as,

hey, like, we have these things. And the consensus rules are very complicated. So,

we can't specify things. But for stuff like BIP 155, you could. It's just lack of effort.

So, if you're working on an alternative implementation, what you always have in mind

is are we in consensus with Bitcoin core? This is not what Bitcoin core devs have in their mind.

When you make a new change to Bitcoin core code, do you think about, hey, are we in consensus with

BTC? Are we in consensus with Bitcoin? That's not something they have in mind. And you can say,

hey, like, why should the devs have that in mind, right? So, this is a chart that I took

off of coin.dance. And 99% is Bitcoin core code. So, it's like, yeah, like, why should you care

about that sliver of minority? And that's true. If I was a Bitcoin core developer, I would not

care either. So, I'm not saying that these other developers are evil. I wouldn't do that either.

I'd be like, yeah, screw you. Work on Bitcoin core. Why are you working on some other implementation?

But, you know, like, come back to it. For whatever reason, it may be, Bitcoin core

treats itself as the only existing implementation. And that makes it really difficult. I have this

one other reason. Like, this is a side reason that I do want to mention. Bitcoin core is also

much more prestigious. So, like, people will share on Twitter, like, hey, like, hi, I contributed to

Bitcoin core, right? And it's like, and we want people to feel that way. Because this will bring

more contributors in, right? This is something that's important to have. And Bitcoin core does

have this. And this is, I think this is good for Bitcoin in general. But, you know, of course,

BTCD doesn't have this. The kind of tweets you'll get about BTCD is like, yeah, I broke BTCD.

I hope the devs notice, you know? So, these are the things, these are the reasons why

having a, like, developing an alternative implementation is difficult. But now, let's get

into, like, why should you try BTCD? I want to sell you guys on, like, trying BTCD. And I want to

talk about, like, these five different things about BTCD that I think are good. And that I

do believe that they are better than Bitcoin core and other alt implementations as well.

First of all, code that's much, much, much easier to understand. And Bitcoin D has also onboarded

very important prominent figures to the Bitcoin ecosystem as well. So, again, I'm going to quote

Roast Beef. So, this is what he said to me in a call a few years back. He said, yeah, BTCD code

is much better than Bitcoin cores. And at the time, I was very confused. Because when we did the

IBD benchmarking, BTCD code was much worse than Bitcoin cores. So, I was like, oh, are you sure

about that? But now that I think of it, I think he meant in that, hey, like, Bitcoin cores code

wasn't written to be read. BTCD code was written to be read. This is another quote from Tad Schreijer,

who was in the audience. Yeah, I could kind of read BTCD code. But Bitcoin core is kind of

difficult, because it's C++. So, that is two very prominent people in Bitcoin that BTCD has

onboarded onto Bitcoin. If BTCD didn't exist, these people wouldn't have been working on Bitcoin. And

I think that speaks for itself. Okay. He's like saying, okay, but fine, fair enough. Moving on.

I want to do a case study. I wanted to sort of point out, it's like, I wanted to give an example

of BTCD code that is written in a much easier to understand way. And so, block index traversals. So,

in Bitcoin core, or in Bitcoin consensus, you would have the, if you, there are times where

you need to just go back a couple blocks. And so, what each block node has is it has a parent

pointer. So, this is just a linked list. And so, it has a parent pointer, so you can move back.

So, one of the requests could be given block 10, fetch block 2. So, when you're at block 10,

you would just go back. Like, right? 9, 8, 7, 6, 5, 4, 2. And then you get at 2. So, that's how you

would do things. But let's say at block 900,000, fetch height 6. This is a much more expensive

operation. And this would be way too slow to just go back one block at a time. So, we're not going

to do that. So, each block index entry has a parent pointer and it also has a skip pointer,

which is which allows you to skip many, many blocks back. So, like, for this specific example,

let's just define many blocks as a floor of divided by 2. So, if we do the same example again

with block 10 and then fetch heights 2, you have block 10, you go back to block 5 because

block 10 divided by 2 is 5, right? So, you have that skip. So, you skip once. And then at 5,

you divide it by 2 and you take the floor, which is 2. And then now, you have block 2. So, that

is a lot of reduction in the traversals that you have to do. So, yeah. How was this implemented

in both BTCD and Bitcoin Core? This is BTCD, right? You could sort of look at it and like you

could sort of like read through and be like, yeah, this is like pretty easy code, right?

I think it's pretty. I wrote that code. So, I think it's pretty easy code.

But then let's look at Bitcoin Cores, right? It's a mess. It's hard to see the mess. I zoomed into

the mess. Can any of you who works on Bitcoin Core here? Yeah, yeah, yeah, yeah. Do you know,

have you seen that code? Do you know what that code does? Exactly. What is the minus 2 for,

right? Like, what is this? Sipa wrote that code, by the way. So, we have these brilliant engineers

that write code in brilliant ways that only their brilliant minds understand.

It's a normal pleb like me, I don't know what that code does. And so, like, this code that I wrote,

other plebs can also read it. It's easier to validate. And it's easier to get a grasp on what

the actual code is doing. So, anyway, sorry for calling you guys out on that. But, yeah, like,

BTCD code is much, much easier to read. Second reason is that BTCD has, like, these static builds

and we have good distribution across numerous operating systems. So, static builds, you smoosh

everything together. There's no dynamic loading of libraries in the operating system. So, if you

have the binary, it will run anywhere. So, because of this and because of how Go supports so many

different platforms, BTCD for each release has 31 different targets that we support. And we support

weird operating systems such as Dragonfly. That's the first time I've seen that. And we also support

weird architectures such as MIPS. And, yeah, so, like, lots of different platforms. So,

if you're a nerd and you run LoomOS because it has Dtrace and it has lots of tracing

capabilities in the operating system, then, yeah, you can run it. For Bitcoin Core, it doesn't

support BSDs that well. So, your only other option would be BTCD. Third reason why I think BTCD does

better or where I think BTCD does better is openness towards features. So, this is, again,

so, if I were to quote him, he said, I want BTCD to be a node implementation where new features

arrive first. And we have been doing this. So, this is one of the PRs that are open and that I

need to get back to for merging. And so, we implemented this new thing called Swift Sync

and the reception has been very positive. And barring any delays, I think we'll have this in

the next few months. Other things is, like, yeah, Electrum server. It's, like, yeah, like,

Electrum server is not the best thing in the world, but, yeah, we can have it because it's

an optional thing that we can have in BTCD. In Bitcoin Core, if you wanted to do this,

it's, like, hey, we take a look at the address space index. We don't want address index. It's,

like, Greg Maxwell, we don't want this address index. And one of the things that points out is

that Bitcoin Core's code is not very modular enough to separate these things out and it'll

be difficult to support for where, you know, this address index has only a few users and it becomes

a maintenance burden. But for BTCD, the way the indexes are implemented, it's very clean. It's

very modular. And so, this was back in 2014 and this is how Roastbeef got into BTCD by implementing

the address indexer.

So, this is, yeah, now, in January of 2015, Roastbeef implemented the address index and now we have address index and because of how the things were implemented in a very modular way, we're able to support these features.

So, with this address index, we have these now new websites. This is called BTCD.watch. You can go on there right now and check it out.

This is a block explorer and a mempool based on BTCD. And it's just the only node back end that you need is just BTCD.

I could sell you guys on the fact that it's Canadian made. It's by Suheb from Lightning Labs. And so, it's Canadian made and operated. So, if you guys want to check that out.

So, yeah. So, we're able to have these features like the address index because it's very modular.

So, this is a diagram of the different dependencies of how different packages are imported within BTCD.

These are the main packages that are able to be reused across different systems. And these packages that you see here are used everywhere.

If you write Bitcoin code in Go, you are using one of these packages. And because of this modularity that we have, we have code that's impactful across the ecosystem.

So, this is not an exhaustive list of things that use BTCD or things that depend on BTCD.

Of course, you have a lot of Lightning Labs on there. But you have things like the Bitbox app, like the Bitbox Wallet app.

You have things like ArcD. The proto-fleets is the mining software by Block. And that is also importing BTCD code.

So, BTCD code is pretty influential across the ecosystem.

Now, I do want to point out, if things are so great about BTCD, why wouldn't you want to use them?

There are two historical cons about BTCD that I think are getting better.

One is performance. I think some of you guys know about these blog posts from Jameson Knopp.

He goes through and tests different Bitcoin implementations.

And this was his latest one, which Bitcoin Core on his machine took 12 hours to sync the entire chain with checking signatures.

And BTCD took 3 days, 11 hours, and 28 minutes.

And I do want to point out that we have gotten a lot, lot better about performance on BTCD.

So, there's three things. You have the block download logic. So, how fast are you able to download blocks?

Two, you have the signature validation efficiency. How fast are you able to validate the signatures?

And then, finally, it's like the TX read and write, which is the UTXO.

Hey, I need to write this UTXO and I need to fetch this UTXO to be able to validate a transaction.

So, that is really slow. We're working on it. That is really slow. We're working on it.

But that is actually fast on BTCD.

And this has been work that's spanned over multiple years.

Stephen Roos in the back started this off.

And we've been implementing, we've been getting a lot better.

So, I don't have a lot of time, but this is validation, or benchmarks that I did against Bitcoin Core.

And BTCD is actually faster if you're not validating signatures.

And if you give a lot of hardware.

And this is even better. This is with the SwiftSync PR.

And we're, like, way faster.

But, you know, if we're validating signatures, we are way slower than Bitcoin Core.

So, that is something that we need to work on.

So, that is the commands I use. If you want to validate my work, you can do that.

That's the computer that I had to validate.

Finally, for the cons of BTCD was that there's not enough reviewers.

And there's been a lot of bugs.

And I do admit that.

Like, the quality of the code is not as high.

It's not as good as Bitcoin Core's.

But that's where you guys come in.

And you should review PRs on BTCD, so that we get better code across the Bitcoin ecosystem.

That's my slides. That's it. Thank you, guys, for attending.

Do we have time for questions?

Okay, one question.

One question from the audience?

These are my slides. If you want them, you can scan.

Thank you.

And you partly said it a bit as well.

I think the examples where you pointed out that you blame Bitcoin Core or core developers,

they were mostly issues with VIPs, I would rather say, right?

So, it seemed like there were things that were under-specified in VIPs.

And then it was implemented differently in BTCD than in Bitcoin Core.

And it felt like it wasn't really right or wrong, clearly, to make out.

So, wouldn't you say rather that there's an issue with VIPs than with Bitcoin Core in these cases?

And then that the VIPs should just be fixed up and it's like a broader conversation

rather than just blaming core for doing things differently?

Fair enough, yeah. We could say that.

It's under the same organization, right?

Right. Well, thank you, guys.

Thank you.

Thank you.

Thank you. I'm Andrew Toth. I'm a Bitcoin Core developer.

And I'm here to talk about parallel input fetching.

So, this talk is about PR35295 if you follow Bitcoin Core development.

And it took over two years to get merged, over a thousand review comments.

So, it was a really big effort from a lot of people to get this in.

But we can say happily that it's been merged.

So, we'll see this improvement in Bitcoin Core version 32 that is coming out this fall.

So, what is this change exactly?

It's a low-level plumbing change to Bitcoin Core specifically, the specific implementation.

So, it doesn't have any changes to the Bitcoin protocol.

So, it's not really relevant to any implementation.

We can't take this implementation and use it on implementations that don't have a UTXO set.

So, it doesn't apply to things like UTREXO or LibBitcoin.

But it speeds up IBD as well as steady-state block validation.

So, if you get a new block at tip from a miner, we can validate it a lot faster now as well.

For any user running Bitcoin Core and likely nodes that are based on Bitcoin Core,

like forks of Bitcoin Core, if they pull in this change in the future.

So, it's kind of a confusing name, parallel input fetching.

We're not actually fetching inputs.

We're fetching input prevouts.

So, I'm sure a lot of you are familiar with some of this stuff already.

But I'm going to go over it to build up to how we make this efficiency change.

So, every transaction has inputs and outputs.

Valid inputs, they must point to a previous out point, which we shorten to prevout.

Inputs are references, right?

So, the prevouts that are being spent are not included with the transaction.

It's up to the node's implementation to go look up this data from however it's being stored.

And so, in Bitcoin Core, we have what's called the UTXO set.

So, it stores all unspent prevouts or unspent transaction out points, the UTXOs, in a set.

And so, they're also referred to as coins.

So, you can say you're spending a UTXO or you're spending a coin.

And this is an optimization that Bitcoin Core does primarily for this optimization called pruning, right?

So, what we can do here when we connect a block and we get these UTXOs,

if we just store the UTXOs, we can discard the rest of that block data.

And that has all the information we need to then continue validating future blocks.

I mean, you might want that block data for other information to look up things,

but you don't actually need it to continue being a validating node.

So, that lets you run Bitcoin Core with a much smaller disk footprint.

So, it's easier to use it on smaller devices.

And even, like, big devices.

So, today, if you're not running pruned, you will probably not be able to run Bitcoin Core on a 1TB disk drive anymore.

So, pruning lets you do that.

So, this is kind of what it looks like at a very, very high level, right?

So, we have the chain state that is represented by the UTXO set.

So, we have in the chain state UTXO A.

And if we're going to connect this new transaction, spending input A and creating output B,

when we connect this, it does an atomic operation on the chain state.

So, it'll delete UTXO A because it's no longer unspent.

Now, it's just a TXO.

And it will create UTXO B.

And that's the new state of the chain state after this transaction has been connected.

And so, there's lots of these UTXOs, right?

There's billions, I think.

And we can expect lots more in the future, right?

Because anytime you receive a payment on chain, someone's created a UTXO, right?

And so, we expect more users.

We're going to get more UTXOs.

And so, there's way too many to store in memory.

So, like every block, like we can store the block index in memory because every block that comes in just has a small entry for where the block is stored.

And that's less than a million today.

But every block can also create tens of thousands of UTXOs potentially.

So, we have to store these in a database.

And then, if we're connecting a block, though, that's a lot of reading of those UTXOs, writing new UTXOs, and deleting UTXOs.

And we can't just do all that directly into the database.

That would be very slow.

It's like orders of magnitude, several orders of magnitude slower to write to disk than it would be to just do this all in memory.

So, we have this optimization called the UTXO cache.

So, when a new block is connected, we read through the cache first.

So, if this UTXO is in the cache, we don't have to go to disk.

And if new UTXOs are created by this block, they stay in the cache.

We don't have to write them yet.

And new UTXOs are marked fresh.

And that allows us to have another optimization.

So, this is kind of how it looks like.

If you just start up your node, you have this empty cache, and it's pointing to the database.

So, now, when we want to validate this new transaction, we don't actually read the database.

We read into the cache first.

So, we're like, do we have input A, UTXO A?

So, the cache will check that it doesn't have it.

So, it goes to the database, reads the UTXO into the cache, and then we can spend it and then create UTXO B in the cache.

But we don't do any writes here.

And so, this allows us another optimization that I like to call UTXO cut-through.

So, when the next block spends a fresh UTXO that doesn't exist in the database, we can just delete it from the cache.

We never have to write it to the database.

And this is a really big performance improvement here, right?

So, we have UTXO B as fresh.

It doesn't exist in the database.

And then when another transaction comes in that's spending UTXO B, we can just delete UTXO B from the cache and write UTXO C.

And so, we never have to touch the database here.

This makes connecting blocks a lot faster already before this new efficiency change we're going to talk about.

So, we do have to actually sync this stuff to disk at some point, right, to store all the UTXOs.

And so, when do we do this?

There's two times we do this.

Well, two main events where we will write to the disk, right, is when the DB cache fills up.

So, right now it's bounded by memory.

It's a gigabyte in size.

So, as we add more UTXOs to the cache, eventually we're going to get to a size limit.

And then we'll have to write everything to disk.

And then we wipe that cache.

And then if we haven't flushed the cache in a long time, we also sync all this data to the database every hour.

So, in that case, though, we don't clear the cache.

We just keep the unspent UTXOs in memory.

And that will look like this.

So, say we have this cache here.

We have a spent UTXO A and a fresh UTXO C.

And now we want to sync this to the database.

So, in order, from top to bottom, we'll have to go and we first delete that UTXO A from the database.

And then we can remove that from the cache so our cache gets lighter.

And then we write UTXO C to the database.

And then we have to remove that fresh flag from our entry C there.

And now our database and our cache are perfectly in sync.

And we still have UTXO C in memory.

So, next time we want to read it, it's going to be a lot cheaper.

And if you're interested in the code, this is in the coins header file.

This is the coins cache entry here.

So, it has the coin struct and the flags.

So, dirty flag means it's different from the database.

So, we have to write it.

And then a fresh flag means it's also new.

So, we can just delete it if we spend it.

And so, the validation code actually has an abstract interface to this UTXO set, this coins view.

We just call this the coins view, right?

So, the validation code doesn't know anything about this caching.

And this is all just a very low-level implementation of what we're doing here.

And so, it can just call to get a coin, see if we have a coin,

write the flush to disk if we need to.

But validation code, this is outside the scope of that.

This is just low-level plumbing stuff.

And so, this is some more C++ code where we have the coins view cache and the coins view DB

that are extending from the coins view.

And so, we have the coins view cache backed by the database.

And so, now, that's basically how our caching works.

So, how do we use this when we want to validate this block, right?

And this is where we're going to see these speedups.

So, first, when we get a new block from a peer, we have to do a context list check.

So, we check things that don't depend on UTXO set, like the size limit, the proof of works, and the Merkle trees.

And once we have that all done, then we have to move on to actually checking the context.

Like, do all these UTXOs exist?

And are they being validly spent?

And so, that's where we have this ephemeral cache.

So, now, we have a stack of caches.

We put this extra cache on top of the main cache before we call connect block.

And we do this because we don't know yet if this block is going to be valid or not, right?

So, as we're creating new inputs and spending inputs,

if we just did that right in the main cache for every block we got

and we found out this block was invalid right in the middle,

then we'd have to walk back every output that we created

and, like, find those spent coins and re-add them.

And that gets really messy.

So, we just have this, like, scratch space on top.

And it looks like this, right?

So, we have this new block coming in that we're going to validate.

And so, we have our empty overlay scratch space that backs to the cache,

and then that backs into the database.

So, if we're going to validate this block, we'll go through each transaction in order.

And we'll have to validate each one, right?

So, the first transaction is spending UTXO A.

So, we read that from the cache.

Then we spend it, and we create UTXO B.

The next transaction, we read UTXO C into the overlay, spend it, and create UTXO D.

Then this third one, we're spending UTXO D, but we already have that in the overlay.

So, we can just delete that and cut through.

So, we can cut through on the overlay too, and these will never even hit the cache.

Then we create UTXO E, and then this last one, the cache doesn't have UTXO F.

So, we have to do this really long lookup.

And this is what takes a lot of time, right?

Because we have to go all the way to disk, the database, read that into the cache,

allocate space in the cache for this, and then read it into the overlay.

And now, finally, we can spend it.

And so, that takes a lot of time, but now we have all this block validated into our overlay.

If this block was invalid, we could just discard this overlay.

And so, that makes it a lot cleaner because nothing in the cache was changed.

So, now, say it's valid.

Now, we want to write this new block data to our cache.

So, we'll have to go again through the block here.

We write that to the cache.

We write the new UTXOs.

We delete any fresh entries.

And then, now, we have all this written to the cache, and we can just get rid of the overlay.

So, that's how we do it today.

And we go through every entry in order, and we read them all from the disk or the cache.

And so, let's say our cache was empty.

This is where it gets really, really slow, right?

We have everything on database.

So, for every entry you want to get, you have to go all the way to the database.

And so, this read takes a long time, this one read from the database.

And we have to do that in sequence.

So, as we're waiting for that read, nothing can be validating at the same time.

So, this takes a long time, and this really slows down the block validation and IVD speed.

And so, that's a big problem, especially for high latency disks.

If you're running on AWS and you're running an EC2 instance, it takes a millisecond for each of those reads.

So, if you have 10,000 inputs, that's like 10 seconds just to validate a block.

And this is causing a lot of problems for users, right?

They're complaining about very slow IVD time, very slow block connections.

So, what we want to do is have something like this.

So, if we already know what the block is, and we know what inputs we're going to want to read,

we just want to do a full read of everything into our overlay at once,

and then we don't have to worry about all that round tripping, right?

And that's going to speed up things a lot.

So, then we can just put everything into the overlay at once, and then we have everything there, we can validate much faster.

So, say we have everything in the database, we can just pull everything in from the database into the overlay and go faster.

So, that's where this idea comes from, right?

So, before we enter the connect block, that's where we do the validation.

So, we already know all the inputs of the block.

So, we don't know if this block is valid or not, but we know all the inputs that it's going to be asking for.

So, we can flatten all those inputs into a list,

and then we have parallel worker threads going to the disk or the cache to get these UTXOs

and insert them into the order that the overlay is going to want them.

So, we have eight worker threads by default, configurable up to 16.

So, if you have a slower disk, you might want to configure even more worker threads.

So, they atomically each just fetch these inputs as we're doing the validation.

And they don't insert to the cache, they insert into the top-level overlays list.

And so, the validation code doesn't have to wait on any of these reads.

It can just keep validating and then just grab the next UTXO from the list and increment the tail.

So, it will go to the list on the main thread.

So, this is a lock-free, multi-producer, single-consumer queue.

Each entry has an atomic flag that gets set by the workers,

and then the validation code waits on that flag so that there's no data racing.

And so, it looks like this.

So, we have this block coming in, the overlay now has these worker threads and this input list.

And so, the first input it wants to get is input A, and that will be in the first entry of this list.

So, at first, it initially has to wait like it did before,

but all these workers are now fetching the inputs in parallel.

So, as soon as the first worker gets the first UTXO, it writes it into the first slot.

The overlay can just take that and start validating the code.

Meanwhile, as the overlay is working, the other workers are also still fetching this stuff

and putting it into the list here.

And so, as the overlay keeps validating and going through,

all the workers are done now putting all these UTXOs in the list,

and the overlay never even has to go to the cache or the database.

And this is a big performance improvement.

And so, this is all done in CoinsViewOverlay, also in the coins header file.

So, here we have this, if you want to check out the code,

input to fetch is each entry in that inputs list,

and then we have the head of the list and the tail,

which is how the workers and the main thread synchronize.

Process input is how we atomically fetch these,

so each worker is just calling process input over and over and over

until all the inputs are fetched,

and then the validation code is calling fetch coin from base

to fetch these instead of going and reading them from the cache.

And this is what we call when we get the block,

to kick off the workers to just call process input.

We flatten all the inputs of the block into the list and kick them off.

And so, this is a graph by Lawrence,

who was benchmarking this on all kinds of different platforms.

So, the three different quadrants here are different configurations.

The default one is on the left, though,

so if you're running, say, an M4 Max,

he measures it as over three times faster than a laptop,

which is a huge performance improvement.

It was like 100 minutes.

It's like an hour and 40 minutes to sync the entire blockchain.

Raspberry Pi 5 was 46% faster,

so big performance improvements there.

And then on network-attached storage,

so if you're running on AWS,

so a lot of nodes on the network are all running on AWS today.

You can see it from AS map charts, right?

And when you run a node on AWS,

you have network-connected storage,

which is very slow, very low latency.

It's like single-digit milliseconds per read.

And so, this is where we see a huge improvement.

So, the blue line is the read throughput of the previous version,

where we're doing it single-threaded.

You can see it never actually gets to read much,

and it takes forever.

And the first green line is running with four worker threads,

and so it finishes much quicker.

I noticed when I was benchmarking this that it finished so quickly,

and so I ran it again with eight threads,

which is the next one,

and that one finished at about the same time the original one did.

So, it was about five times faster running it on AWS,

which is a huge speed-up.

And what else is interesting about this graph

is that where you see this huge spike in read throughput,

that's where a lot of...

That starts at around block 800,000.

So, the first 800,000 blocks were already pretty efficient,

but what happened around block 800,000,

there was a lot more UTXOs being created on the network,

which really slowed down a lot of users running nodes.

Like, a lot of users were really complaining

about all the spam causing IBD to get really slow.

And you can see that from the chart, right?

Because 90% of the syncing time was just the last 100,000 blocks.

So, this change fixes that, right?

So, now we can write lots of UTXOs,

and spam is no longer really a problem for syncing your node.

And so, this will be going, hopefully, live in sometime this fall,

when we release version 32.

Yeah, thank you.

Thank you.

Any questions?

No? So, thank you so much.

We have a question.

I just wanted to ask you, I think you're not working on Bitcoin Core full-time, is that correct?

Yeah, I have a part-time grant from OpenSats.

Cool.

Thanks for doing that work.

I'm wondering what was your experience with that as a sort of like a part-timer coming into this gigantic codebase?

I noticed it was a two-year effort.

How did that go?

And are you working on multiple PRs in parallel?

Or was this like your core thing, your main thing you were trying to do?

Or do you, yeah, how did that go?

So, well, I disconnected, but I had a...

And how did you get roped into two years worth of work?

Well, so I've been working on Bitcoin Core for a long time.

I was always passionate and interested about it.

So, I've been, this is not my first change.

I've worked on performance improvements and caching.

So, a lot of the caching talk I was doing, I was built based on experience.

I have had, you know, improving that over the years.

So, this is just something that I noticed was a problem for a long time.

And it took a lot of convincing people to take it seriously and try and get it in, which was a lot of work.

But, yeah, I'm definitely very passionate about continuing working on Bitcoin Core.

We have more performance improvements in the pipeline as well, specifically around indexing.

So, right now, the transaction index is a very large database, and it doesn't let you use it in prune.

So, hopefully, in version 32, we'll also be able to shrink that considerably.

And then in future versions, we'll be able to run all the indexes in prune mode.

So, those are some of the things I'm working on as well.

Okay. Thank you.

Good morning, everyone.

Today, I will be presenting the ARK Round Signing Ceremony.

The ARK Round Signing Ceremony is the fundamental building block of ARK.

It's what makes the protocol what it is, and it is the source of the VTXOs, which you use to transact in the ARK.

It is the ARK Round Signing Ceremony, which builds the timeout tree.

And it is the ARK timeout tree, which grants you absolute self-custody of your VTXOs.

So, the system is not trustodial, it's not custodial.

You can always exit the system unilaterally.

And it is the first cause of your VTXOs, meaning this is where your VTXOs come from.

Almost everyone.

You can board directly into the ARK, which will get you a VTXO.

But most of the VTXOs which you will interact with come from a previous round.

The round is a three-phase process driven by the round state machine.

First, you collect payments of everybody who will be participating in the round.

Then, there is the signing ceremony of the VTXO tree.

And then, finally, the round is finished.

So, now we have three ARK implementations in the ecosystem.

We have Bark, Arcade, and Wavelength now by Lightning Labs.

And you'll notice that all of them use VTXOs.

So, this same shape, this same fundamental structure is present across all of these protocols.

They may use different language, but there is intermittent timeout trees which happen on-chain,

which require refreshes, and they all follow the same similar structure.

ARK rounds are powered by Taproot.

So, Taproot was activated in Bitcoin on Mainnet in November 2021.

It consists of BIP-340, BIP-341, and BIP-342.

And all three of these BIPs are used in ARK in these rounds.

This is a great monetary use case of Taproot.

So, you have a tree that happens for these off-chain outputs, and they look like Taproot spends.

So, this is a really good monetary use case of the Taproot update.

Now, we mentioned that the Taproot rounds happen intermittently, or periodically, better to say.

So, the tree has a limited lifespan, and you will participate in them periodically.

For example, an ARK round could happen once every hour, so you could have 24 rounds per day.

And you enter into a round in order to perform a refresh, because your VTXOs will expire.

Each round's tree has a finite lifespan, so when you construct a tree,

all of the VTXOs on that tree are all going to expire together on the same date.

But the VTXOs do not all have to refresh together.

The VTXOs from one tree, they can be refreshed in various different trees later on.

You re-enter the future rounds before expiry, and participating in a round is a good thing.

You want to participate in a round. It's what keeps your self-custody alive.

To walk you through this, I'm using the canonical ARK round from the Bark test suite.

The demonstration I'm going to show you today comes from a real file in the Bark library.

You can find it in testing, testbarkround.rs, so you can try this at home.

And it uses the Rust Bitcoin kernel project, which is Bitcoin Core's consensus engine,

to prove the tree is consensus valid in the test.

This version I'm showing you today is pinned to Bark 0.4.0.

That's the round we're going to showcase today.

There's three phases. Phase 1, Phase 2, and Phase 3.

In Phase 1, you're collecting participants.

The coordinator, or the ARK server, gathers everybody who is going to participate in the round in Step 1.

Then they all co-sign the tree together in Step 2.

Once the round is finished, this will broadcast into an on-chain transaction.

Hello?

Oh, we're back on the screen.

Very good.

I put these four dots between all of the three different phases

to show that each of these phases is transforming.

It has an input and it has an output for each of the phases.

I gave them four different images.

At the beginning, collecting payments, you take the round participant registration,

so all the old VTXOs.

These are VTXOs that came from various different trees.

They might have different weights.

They have different histories.

Some of them may have been transacted with many times, some not at all.

They're inconsistent.

They're irregular.

Phase 1 will transform them.

It takes that, receives all those old VTXOs, and creates an unsigned proposed tree.

Then Phase 2, the signing of the tree, it takes as an input,

it takes the unsigned tree, and then you get a signed timeout tree.

Once the round is complete, that gets broadcast as an on-chain transaction.

There it goes.

Phase 1 is bringing you from there to there.

Phase 2 and Phase 3.

Now, I'm going to use the three phases to construct a diagram of the round.

We have Steps 1, 2, and 3 at the bottom.

You have this pivotal point at the intersection of Steps 1 and 2.

After you've done collecting the payments and the registrants,

but before the tree is signed, this is arguably the most pivotal point in the round

because this is where the unsigned tree is proposed.

Everything that comes after this point is bringing this proposed tree into completion.

I use the analogy of consolidation up to this point and expansion afterwards.

It's like you're inhaling in all the inputs, and then you exhale out, and there's an expansion.

Periodically, breathing is a good thing.

You take a new breath, it's something that you want to do.

It's not bad to have rounds and intermittent refreshes.

This is beneficial for the system.

Here's one more diagram I show.

Step 1 is the inhale process, bringing together all of the previous participants,

gathering everyone, and then Steps 2 and 3 is exhale.

At the far left of this diagram, you see I have the old VTXOs coming in.

They're not coming in in a nice tree structure.

They come in irregularly, like you're getting this VTXO from here.

There, it's a little bit messy.

Then the signing of the tree happens, and then there's a proposed tree that comes out.

You have a root transaction at the bottom, which comes into a node,

and then you have the new VTXOs at the end.

At the end of the expansion, you have a fully signed tree that's ready to broadcast.

I'll remove the actual helpers of the three steps.

You can see here's the image.

You have old VTXOs coming in from different sources.

They may have come from previous different trees.

They come participate in the round together.

Then you have this new rigid structure of the timeout tree, which you can use.

Visually, here's a diagram that you would see.

That new VTXO, it goes, it lives its life, and then there is another tree waiting for it.

The destiny, the final cause of one of those VTXOs that's from the previous tree,

it will come to be an input of another future round.

You'll notice that the arc rounds is not a chain.

Arc is not a side chain.

You'll notice that there's not a linear sequence of rounds,

but rather they're scattered irregularly.

I really made sure to show that they're not all aligned vertically either,

to show these different rounds, they can happen in different orders.

For example, here at the bottom, in the third round from the top,

we have two VTXOs coming into this round from that one,

and then one from the top one, one from the middle one.

They can be arranged in many different configurations.

They can get a little bit messy if you start to map it out.

You can see this starts to become more complex.

But if I can trace a line, I can trace a green line,

and you can follow money through the system.

The VTXOs themselves are ephemeral.

They come and go. You know you forfeit them.

They get refreshed. You get a new, different VTXO in exchange.

But the money lives on through the rounds.

Here at the end, we have a new VTXO at the far right, highlighted in green.

If you follow that path all the way through one, two, three, four previous rounds,

you can see which VTXO you started off with in the very beginning.

Now there are sub-steps of these three phases of the rounds,

which I will be walking you through today.

I'm also going to highlight how these are all specific to Taproot,

and this was made possible through Bitcoin's latest consensus change.

In phase one of collecting the payments, the server opens up in a tent.

It mints a one-time co-sign key, and the round begins,

and it starts to gather all of the participants.

The participants submit their payments, and the server collects them.

This is all happening off-chain. This is the layer two part.

These are not on-chain transactions that the VTXO holders are making.

This is all happening off-chain.

They participate. They give their old VTXOs.

They submit. They get their place in the round.

Then phase one ends with the unsigned proposed tree,

which is proposed by the coordinator, or the ARC server,

or the captain that is putting this all together.

What are the parameters of the round?

At the beginning of the round, the expiry height is set.

All the different VTXOs gathered in that round, they all have a shared lifespan.

For example, 4,032 blocks.

Every VTXO in that tree, they will all expire on the same date,

approximately 28 days from now.

The exit delta is also set, and then also the server's pub key is there,

because when you're using ARC, you're using a particular ARC.

You cannot reuse the same VTXOs across different implementations,

but even within the same implementation,

if you have two different ARC servers, you're associated with a particular one.

What do the participants give the coordinator?

They're giving their input VTXOs,

the requests of which VTXO they will receive in the refresh,

their music to public nonces, and their participation mode.

Either they're participating in the round interactively, or this is delegated.

They can delegate their refresh to another party,

so that they do not have to be online at the specific time of the round.

I've created a little video demonstration.

It should appear here.

Here are 16 old VTXOs.

You notice I structured them in a way that's staggered,

so they all have different sources.

They may have come from different trees.

The payments are registered,

and they all come together,

and a tree is proposed.

There's an unsigned tree now.

All the participants at this level can see where they will be,

but none of the signatures have been applied yet.

How is Taproot used here?

The tree spec contains the nodes paid to Taproot output.

What's very important about this is that you have the key path and the script path.

Before Taproot, you had two different transaction types

for key spends and script spends,

and Taproot brought them together into a single transaction type.

That's how this is used.

You're constructing one transaction,

where you can do cooperative key spends together with the coordinator,

or you can also go uncooperatively.

You can broadcast an exit.

You can do a script spend to get your money out of the system.

The music, too, comes from BIP 340.

Phase 2 begins now.

We have the signing of the tree.

Each participant returns their partial signatures for their branch of the tree.

We're going to do another visualization of this for you to see as well.

They're forfeiting their old VTXOs in exchange for what they will receive,

and the server will then co-sign with them,

and a signed tree is created.

I'll load the next video.

I'm going to pause right here at the beginning.

You'll notice that each of these are the VTXOs at the top.

Everyone applies their individual signature to those VTXOs,

and then this node transaction of the tree has four signatures.

It has four keys because all of the participants,

they are signing their way all the way up the tree.

Down here, the root transaction has 16 signatures from the participants,

four on each of the nodes,

and then one on each of their individual VTXOs.

They're forfeiting their old VTXOs together as they're signing the new ones,

and you have in blue, this is the signature of the coordinator,

the ARC server or the captain.

ARC server comes and is the second one here.

It's the fifth and the 17th signature on all of them.

Now you have the signature aggregation,

so all of those different co-signatures come together,

and you complete this step with an unbroadcast but fully signed tree.

Now, how is taproot used here?

You can see the whole thing is BIP 340 Schnorr signatures.

We have the signature aggregation,

and these signatures authorize the key path,

so if I want to do cooperative things in the ARC,

like, for example, make a payment, an ARC payment,

if I want to do a swap and make a Lightning payment,

this all happens cooperatively through the key spend,

and if I want to leave the system,

I want to broadcast a unilateral exit,

that's coming from the script spend.

And finally, we have phase three.

The round is finished. Time to broadcast.

So first thing that happens is it persists,

so the rounds and the signed transactions

are written to the database before it's broadcast.

The VTXOs are formally created, so to speak,

and the transaction is signed by the ARC server and broadcast.

Play this video.

Here's it persisting. Individual VTXOs are finalized.

The on-chain transaction is signed,

and you'll notice it's only the signature of the ARC server here.

The individual participants are just signing their exit paths.

They're signing the tree itself, and the round is now complete.

It's broadcast on-chain, and users will receive their VTXOs,

and they can start transacting with them.

So how is Taproot used here?

BIP-341, we have the pay-to-Taproot output,

we have the Tapscript exit paths,

and here's a final image of what that looks like.

You'll notice that in the round transaction,

you have the zeroth output there.

That is the Taproot output from which the root of the tree is coming,

and the input, it's the CaptainD wallet.

This is the round's wallet.

This is the ARC server funding the round on-chain.

And then you have change, which could come from that as well.

And this is the final image of what's broadcast on-chain.

The round asserts your absolute self-custody.

Participating in a round is a good thing.

It's the act of claiming that self-custody.

It's not a custodial model.

That timeout tree, it has an expiry,

so you'll have to keep refreshing your funds through future trees.

And just like breathing, inhale, exhale,

each round is like one breath.

And this is evidence of a proof

of a true monetary use case for Taproot,

which is Bitcoin's most racist consensus soft fork.

Thank you.

APPLAUSE

So we have some time for questions.

Me again.

I'm wondering in practice right now,

these trees, are they limited by...

What size are they?

Are they limited by the number of participants you have?

Is there an upper bound to what the implementations are,

like the number of people?

You also mentioned sort of like a threshold

at which the round would automatically trigger.

Is that for a number of participants or for other things?

So the number of participants, this is implementation-specific.

And it's also a parameter which can be configured.

So the ARC server can set,

here's the max participants of a round.

They have control over that.

And for a round to automatically happen...

No, the opportunity for a round comes every hour.

So if there's no participants who want to come to the ARC server,

then the round could be passed on.

So let's say, OK, no round will happen now.

Let's try again in an hour and see how many participants.

OK, now the next hour comes and seven people are there

and they're ready to submit to participate,

then that round will happen.

But they're not forced into a round, per se.

If users come on early, they can delegate their refresh

and then somebody else is going to come on their behalf

and force them...

I don't know if it's right to say,

force them into a round, a particular one.

But they can walk away and they will be entered into one

that they're not actively in.

That's a non-interactive.

But I hope that answers your question.

And how big are those trees at the moment?

How many participants can you have?

I guess the expiry and the exit gets pricier and pricier

the bigger the tree.

In practice, what does that look like right now?

I'll get some empirical data to share with you.

Any questions?

The main limitation is that before we start the round,

we kind of need to ask nonsense from the users.

And depending on how many users will eventually show up,

we need a different amount of nonsense.

So we kind of limit it currently at 65,000 leaves,

just so that we know that we only have to ask for

four or eight whatever math nonsense from the users.

But we could just ask more, but it's like a trade-off.

Because the more data users have to submit,

the more likely they are to have bandwidth problems.

So we think currently 64,000 is fine.

But yeah, we can easily grow it.

It's not really...

The protocol doesn't bound it.

Can you talk a little about consensus proposals

that will be useful for Arc?

I understand that something like template hash could be useful.

Would other proposals or other capabilities also be useful

related to expiry or anything else?

Yeah.

One usability concern that people have with Arc is they say

it's inconvenient for me to come online

in order to participate in a round.

They don't like that they have this liveness requirement.

That they have to come participate either to delegate the refresh to somebody else on a monthly basis or themselves interactively participate in the round.

So template hash or CTV, what these covenant proposals would do is they would remove the need for the user to come online.

So a user would be able to put money into an Arc, participate into a round, and then they would be able to walk away and turn off their device for several months.

And then they would be able to come back later and find that they're still within the Arc.

That they have not been removed, their money has not been swept away from them.

So covenant proposals would eliminate the liveness requirements from Arc.

Hey, so just to understand from the server side, when you have those VTXOs and the round has been initiated with the tree, how do you deal with continuity issues if something happens to the server?

Continuity issues. So the server is doing live, real-time backups.

So if the server goes down, it has a database that exists off-chain which has backups.

So we can bring the server back online and it can continue where it left off.

So the file crashing would be able to, assuming there is a backup presence, you can pick up where you left off.

Thank you.

Just to be sure I got it, when you say participant, I guess you're speaking of Arc clients?

Yes.

Okay.

So an Arc participant, that could be you with your mobile wallet.

It could be a cashument, which is using an Arc client in order to power it.

It could be a mobile money gateway.

So the Arc server doesn't have conception of what are the different types of applications which are plugged into the clients, but be it an exchange doing payouts over Lightning, that's one example of a client, or an individual wallet.

The person who is driving that client would be the participant.

Yes.

Thank you.

Hey, how many transactions does it take to unwind the timeout tree, and then what are the timeouts of those transactions?

So how long does it take to actually fully exit from a large Arc?

So the amount of time it takes depends on how deep you are in the tree.

So refreshing in a round brings you back to this reset state.

You know, it minimizes your depth inside of the tree.

If after a round you go and you start to make out-of-round transactions, you start to interact within the system, that can increase your depth in the tree because the tree is actually extending.

And the deeper you are, the longer it'll take.

I did mention a timeout, which is set for the round.

I'm happy to refer you to some empirical exits which we've done that have some exact durations and costs.

Any other questions?

Okay, so thank you, Matthew.

Thank you.

Hi.

Yeah, so I'm going to talk today about a Covenant BIP proposal that I've made with two of my colleagues.

My name is Stephen Ruse, I'm at the bottom there.

Antoine Poinsot and Greg Sanders are co-authors of this BIP.

It's a Covenant BIP proposal.

We're at the consensus edition of Bitcoin++, I think.

You don't have to ask who knows what a Covenant is or who has heard of a Covenant, but who knows how Covenants work, has thought about them technically.

Someone, you can raise your hand.

Okay, very few people.

So I'm going to very briefly explain a little bit what are Covenants, why we want them, and then a bit of some history of some earlier proposals that have been made,

and then some motivation of why we decided to propose BIP448, which includes a few different opcodes that weren't proposed before.

So what are Covenants?

I like to think of Covenants in the following way.

When we define the coins or the spending conditions in our Bitcoin wallets, we currently have a few options of how we can constrain these coins, how we can protect them.

But there are always conditions that we put on the coins on what you need to fulfill to be able to spend these coins.

For example, you can say, I need a signature from this specific pubkey.

You can put time constraints.

Closer to my mouth? Okay.

You can put time constraints on your coins, like saying it can only be spent after this time, or you need to wait for a few months before you can spend them, stuff like that.

We have opcodes to enforce these constraints.

The model in which this works is usually that the inputs of the transaction always have witnesses that fulfill the policy of the output that they are spending.

So each input needs to make sure that they fulfill the output that they are spending.

But once this output is fulfilled, they can basically just take the money and do whatever they want with the money because they are the rightful owners of the money.

With Covenants, you can basically do a different type of check.

So instead of just expressing who or how you need to fulfill the coins, you can also limit in what way the coins can actually be spent.

So not just, like, you need to do the signature and then you can do whatever you want.

Also, like, well, you cannot just do whatever you want.

You can only do specific things.

So, for example, you can limit what new outputs can be created using the money that you are spending.

And in this model, the policies of the inputs of the transaction can actually encumber and limit all of the outputs of the new transaction that you are making.

Now, this might sound a little bit, like, abstract or a bit vague.

So I'm going to try and give an example.

At first, maybe, like, why is this useful?

So, like, primarily, obviously, Bitcoin is programmable money.

So if you can have more expressivity of what you can do with the money, obviously, you can be more programmable.

And this usually translates in better security, more, like, wallet policies that you can have.

Stuff like vaults are often discussed in the context of covenants.

Also, inheritance policies.

Basically, different ways to protect your wallet.

And then, obviously, also second-layer protocols.

So Lightning, ARC, BitVM, all these protocols kind of use the programmability that Bitcoin has to make them actually work.

And then have stuff that you can do off-chain without having to touch the block chain.

But using the primitives that the block chain has to make sure that these protocols are secure.

So with covenants, we can have better expressibility and better functionality in these layer 2 protocols as well.

So this might be a bit abstract.

So I'm going to use an example throughout my talk of a very specific covenant use case.

So imagine, like, you're a regular Bitcoin wallet user.

You have two kids.

They're named Alice and Bob.

Obviously, we will all name our kids Alice and Bob.

And you want to be able to use your wallet as a regular wallet.

You want to be able to just sign a transaction, send it to anyone you want.

But you also want to make sure that if you would die, that somehow your money would go to your kids.

Well, what you could do currently is you could have an additional key or a multisig of two keys, for example, that is activated after five years.

And then you put the keys of your two children there.

But for them to be able to spend this money, they would have to come together and agree on spending it.

Imagine your kids don't get along very well.

If you use the current strategy with a multisig key, then, for example, one of the two could say, well, I'm not signing.

So you cannot get your half of the money.

So with a covenant, what you can actually say, well, after five years, someone can just take this money and spread it into two outputs.

One for my one kid, one for my other kid, and no one can stop them.

So neither of them can stop the other one from doing this.

So specifically, what this means is, for example, you have a 10 Bitcoin UTXO.

You can just spend it by signing.

But also after five years, a transaction can be made that just takes this 10 Bitcoin UTXO, makes two new UTXOs, one for Alice, one for Bob with five Bitcoin each.

And anyone can do that because it's encoded in the output that the money needs to be spent into these two outputs.

So that's what a covenant could enable.

This is obviously a very simple use case, but it's a useful one to think about when we're trying to construct these kind of policies.

So OPCTV, or Object Template Verify, was a proposal made around the same time as Taproot, which is actually an opcode that would do exactly the thing that I just explained.

It's basically an opcode that allows you to encode inside your spend policy a template, quote-unquote, which is kind of a hash that summarizes the outputs of your transaction.

And then you encode it into the policy.

And then at spending time, this template is kind of compared against the actual transaction.

And then if it doesn't match the transaction, it's invalid.

So you can basically make a hash of the transaction that says five Bitcoin to Alice, five Bitcoin to Bob.

And then you put this in your output.

And then anyone that spends needs to actually fulfill this in order to be valid.

The way you do that is you hash this, you put it in your script, and then you use the opcode OPCTV.

And then this will compare the template with the actual transaction.

So how would we implement our example that way?

Very simple.

You would hash the template, like I said, five Bitcoin to Alice, five Bitcoin to Bob.

You put it in your output script, like in your tap script spend policy.

You put OPCTV so that it checks it.

And then you also check, additionally, that five years have passed since the UTXO was created.

But this is something that already exists today.

So I want to take a small detour.

Because I said right now in Bitcoin we don't have a way to encumber the outputs of the transaction.

But obviously if you sign a transaction and you want to send one Bitcoin to someone and get all your other Bitcoin in change,

obviously that somehow does encumber the outputs of the transaction.

Because you kind of don't want anyone to use your signature to do some other stuff.

So we actually do have an opcode or a mechanism to look into the outputs of the transaction

and make sure that they fulfill some conditions.

It's called the TREXIC opcode.

So if you sign a transaction, the signature actually is not a signature of any arbitrary message.

It's a signature of a specific hash that is calculated from the transaction that also looks into the outputs.

And then make sure that that signature matches what the transaction is actually doing.

So this is a visualization of all the fields that go into the signature hash.

This is the SIGHASHALL, which basically hashes all the stuff that you could possibly hash.

So most importantly, all the outputs are like here.

This is just a random data example.

And it also hashes a bunch of other transaction fields.

Now, what you could try to do, you could think,

OK, let's say I want my money to go to Alice and Bob.

Can I not already sign a transaction that goes to Alice and Bob

and then put the signature inside the spend policy, right?

Where you say, OK, the signature that I already defined needs to be valid for this transaction and this pubkey.

And because I signed it for the two outputs for Alice and Bob,

if I put it in there, I can actually enforce that the transaction needs to go to Alice and Bob.

Now, this obviously doesn't work because part of the signature hash is the TXID of the transaction that you're spending.

So you cannot put a signature that commits to something that you don't know yet inside the output that will create a transaction, right?

So this is kind of a dependency loop.

Because you need to know the transaction up front, you cannot create a transaction that commits to this.

So in this slide, this doesn't work because of that.

So in this slide, there's another relevant technical proposal that's been made even way before taproot.

Originally called SIGHASH no input, but currently called SIGNASH anyprevout or APO.

It's not a covenant proposal.

It's a proposal to introduce a different signature hash algorithm.

Originally, it was introduced or proposed part of the Lightning white paper.

So because people were trying to build these payment channels that eventually will have turned into Lightning,

they kind of want what you do in Lightning is use two parties that don't trust each other kind of create a joint UTXO.

And then they'll make sure that they can always in some way exit from this UTXO so that they get their fair share of the money back.

So if two people each want to put one Bitcoin in a UTXO, they then first sign an exit transaction, so to speak,

that gives them the money back in case their channel partner goes away.

But because you don't know the transaction ID of that transaction,

because back in the days before SegWit, Bitcoin had this property that was called transaction malleability that was an issue.

Because if I sign a transaction and broadcast it, someone could actually change my signature in some way that it's still valid,

but the transaction ID would change.

But it means that if we sign a transaction, like I said before, using the SIGHASH all, it commits to the TXID.

But if I'm not sure that the TXID will actually work, then this transaction could become invalid.

So the Lightning paper proposed to introduce the SIGHASH flag, which does not commit to the inputs.

That's why it was called no input, so that you could build this type of Lightning channels.

Now, we all know that APO was not activated, and instead the Bitcoin developer community said,

okay, this transaction malleability problem is not just an issue for Lightning.

It's actually a broad issue that we should kind of fix more generally.

So then SegWit was proposed, which alongside other technical benefits introduced transaction ID stability,

which kind of fixed the malleability problem.

And because then we had SegWit, we kind of didn't need APO anymore for Lightning to work.

So people started building Lightning using the stability, the TXID stability that SegWit gave.

And then APO kind of was still talked about, but kind of put on the long run.

Now, you might have heard of Lightning Symmetry, which is kind of a version 2 or an improved version of the Lightning protocol

that would reduce a lot the state that you need to manage.

It also improves the safety of your unilateral exit and stuff like that.

But Lightning Symmetry still requires what we call rebindable signatures,

which are like signatures that you can put, that you can replug even if another transaction actually creates your UTXO.

So how does APO, using APO work? It's the same.

You have the same check stick with a pub key, but here inside the signature,

you basically add a small flag that says, okay, I'm using an APO sig, and I'm not committing to the inputs.

And this would then obviously get new consensus meaning.

So this is the same diagram.

Just the only difference here is that this prev outs in APO are not committed.

You do commit some other stuff about the inputs, for example, the amount and the output scripts,

so that you make sure that only a UTXO that was created between you and your counterparty could actually use the signature.

So going back to my small covenant example, what we could actually use this APO trick for is we could actually,

like I suggested before, pre-create a signature that actually signs a transaction,

that takes the money and gives five Bitcoin to Alice, five Bitcoin to Bob.

We put it into our output policy using the APO flag so it doesn't commit to the prev outs,

and then together with the pub key, the check stick op code, and the same five-year relative time lock check,

put it into our wallet policy, and actually we can achieve the same goal.

So even though APO is not a covenant proposal or a covenant op code,

we noticed that we could actually use it to emulate or to achieve the same functionality that covenant op codes are actually doing.

So there is some kind of technical equivalence,

because it's possible, like we just showed, to implement CTV-like behavior using APO.

Now I'm going to show that there's also a reverse technical equivalence,

but before I do that, I'm going to introduce another really small op code that many of you might have heard of.

It's called check stick from stack.

Like I just said earlier, the check stick op codes or any other signature check in Bitcoin

doesn't really check any arbitrary message that you can specify.

It always looks at the transaction, creates a message from the transaction,

and then checks the signature against that message.

With check stick from stack, you can actually do arbitrary signature validation.

So instead of just giving a pub key, you give the pub key and the message,

and then the signature is checked against that message for that pub key.

So how you would do that in practice is you put the message and the pub key in your policy,

and then the user that spends provides a signature, and this signature needs to be valid for this specific message.

It's a very simple op code.

It's been live on the liquid network since it's on mainnets, which is definitely more than six years ago.

So it's a useful building block.

It's been discussed for a long time, but it's never been a priority to be discussed for consensus upgrades.

But using this additional op code, we can actually also emulate APO,

so rebindable signatures, using the CTV op code, so the reverse of what we did earlier.

How does that work?

Well, because the CTV is actually a hash of the transaction that commits to the outputs but not the inputs,

it's kind of similar to the SIG hash that any prep out specifies.

So what you can do is you can actually let the user provide a template,

which is the hash of the transaction without the inputs,

then use the op code CTV to make sure that what the user provided is actually the correct template hash,

and then use this op code check stick from stack to make sure that the signature that the user also provides

is the correct signature for the template of the transaction.

So this is basically, like I said there, checking the signature of the template,

but the template is kind of similar to a SIG hash value without the inputs.

So we have this situation where there's this covenant proposal CTV,

there's this old SIG hash proposal APO, and both have use cases, right?

CTV is an explicit covenant proposal.

APO is like rebindable signature, so it's useful in the lightning sense.

And you can kind of emulate one with the other and other with one.

So in the community, there has been a lot of discussion about,

okay, should we want to upgrade both?

Should we want to include both in Bitcoin?

Should we just pick one and then have the people that want to do the other just emulate using this roundabout way?

And it's not really clear which one is the best one to do,

which are the use cases that people most want to do.

Those are really hard things to estimate or predict.

If you look at the cost to use this, it's also not really clear.

I mean, CTV obviously is very efficient for doing CTV, right?

But then it's quite expensive to use it for rebindable signatures,

and then APO is kind of in the middle of that for both.

Also here, we don't really have a clear winner, quote-unquote.

So this is where the BIP that I want to propose or I want to talk about comes in.

It's an explicit BIP.

It's a BIP that explicitly wants to enable both rebindable signatures

and this commitment to a next transaction, like templating, in an optimal way.

And we're trying to do that by introducing three opcodes.

They're only introduced in the TabScript context,

which is relevant, we'll see, in the future.

But obviously APO was defined or specified even before SegWit existed

and CTV kind of before TabRoot existed,

so they are like slightly older protocols.

So we're also trying to kind of make use of the latest protocol system

that we have for TabScript and kind of make them a little bit more modern.

So the first, like the major new opcode that we're proposing,

it's also specified in BIP446, is called TemplateHash.

And TemplateHash is actually a very straightforward opcode.

Similar to CTV, which checks your transaction against the template,

TemplateHash will just calculate the template and give it to you on the stack

so that you can do with it what you want.

We can do this in TabScript because in TabScript we have Opsuccess.

You might be aware or have already heard people talk about it

that before TabScript, when we did soft forks,

we always have these opcodes that end with verify.

And that is because we cannot change the stack with upgrades for opcodes

because if you change the stack, it's actually often a hard fork.

So the only upgrades that we could do before TabScript

was create opcodes that would check something

and then fail the transaction if it's incorrect

and then do nothing if it's correct so that they don't change the stack.

That's why it's called CTV, CheckTemplateVerify.

It just looks at the template, checks it.

If it's okay, it will do nothing.

And if it's not okay, it will abort.

In TabScript, we can actually do more stuff.

So we can actually change the stack.

So we can have an opcode that calculates the template,

calculates the hash, puts it on the stack,

and then lets the user do something with it.

So how do you do next transaction commitment with this?

Very simple.

The user provides a template.

It uses the opcode to calculate the template again,

and then you check that they're actually the same.

So this is basically CTV using template hash.

But if you're doing rebindable signatures

the way we would emulate them using CTV,

you no longer have to have the user provide the template here.

You can just calculate the template

and then make sure that the signature matches the template

that is now on the stack using CheckStickFromStack,

which brings us to the second opcode

that we included in our BIP448 package, CheckStickFromStack,

an existing opcode that's been defined for a long time.

So, yeah.

Now, I say that template hash just brings the template,

quote-unquote, on stack,

similar to how CTV checks, quote-unquote, the template.

But the templates that we're talking about

are not exactly byte-for-byte the same.

Conceptually, they're the same.

They're trying to commit to the outputs of the transaction mostly.

But we also commit to some additional stuff,

mostly because one of the goals for this templating construction

is that we can somehow fix the TXID

given the prevout that is spent in this transaction.

So if you have a transaction with one input,

and the input is the one that contains the covenant policy,

then any transaction that passes the policy

should have the same TXID.

That's useful for various off-chain constructions.

So that's just the goalpost that CTV had

and that we also want to have.

So for that, we can make a few changes from CTV.

So one is that in taproot,

scriptseqs are no longer allowed.

Scriptseqs is kind of an old legacy field

that we used to put signatures,

and currently we use the witness for that.

So we don't have to commit to the scriptseq

because in taproot you simply cannot have a scriptseq

that's already invalid.

So that's one of the changes from CTV.

And then, because I explained to you

that the template hash is actually very similar to a SIG hash

and we already have a lot of machinery inside BitConcord

to calculate the SIG hashes

for all the signature checks that we're doing,

we thought, okay, let's see if we could reuse

some of that machinery that taproot introduced

to calculate the SIG hashes.

And what we did is we actually looked at SIG hash all,

which is the default to sign everything,

and then we took out some things,

but then we could reuse most of the calculations

for SIG hash all.

So one thing that we don't have that SIG hash all has

is the hash type and the spend type

because they're basically irrelevant.

They have to do with something with signatures,

so we don't really have this.

It's irrelevant in this context.

Obviously, we don't commit to the PrevAs, right, which SIG hash all does. That's kind of the whole point of this.

And then a last one that SIG hash all commits that we decided to not commit is the amounts.

This was a bit of a trickier decision because there's good arguments to be made to include them, and there's arguments to be made to not include them.

Eventually, we settled on not including them, mostly because if you include the amounts and then somehow accidentally send a different amount to your policy,

you would black hole all your funds, basically, and to avoid that foot gun, we kind of thought that any of the other more, like, fringe benefits that on the other side you would get would kind of, yeah, that this one was more important, basically.

And then, lastly, the last difference is that template hash also commits to the Annex. This was another one where we went a lot of back and forth.

CTV obviously was defined before the Annex, so it didn't touch the Annex at all.

We'd eventually, I mean, it's relevant to point out that no formal, no use of the Annex has been formally proposed so far, so it's very abstract and hypothetical to talk about the Annex.

But because the SIG hashes currently commit to the Annex, we decided to just also do it so that any proposal that might be proposed in the future to use the Annex that is compatible with SIG hashes is also compatible with template hash.

Again, there were some arguments to be made to not do that, but eventually we decided to stay as close as possible to the SIG hash calculation of taproot.

So this is basically the calculation of the template in template hash in a nutshell and how it differs from CTV.

Well, I hear a lot of talks about spam and all that, so it seems that people care a lot about block space, so I kind of made a comparing table about how much block space you would use to use all of these constructions.

So these ones, these four we saw before, the template hash plus check SIG from stack construction uses one byte more to do the next transaction commitment, but then it's equally efficient as APO to do the rebindable signature.

So it kind of finds a good middle ground here.

Now, I said that there was three upcodes, and we've only seen two so far.

So when we go back at the constructions we saw before, we looked at this, and you look at this 32-byte pubkey here, right?

And like I said, we only proposed the introduction of these primitives in tapscript context, and for those of you who understand tapscript, you know that when you do a tapscript spend, your witness already contains your internal key.

Like the way taproot works is that you have an internal key and then a commitment to some scripts, and if you want to use the scripts, you need to show the internal key, and then you can use the scripts.

So that means that every time you spend a tapscript, there's already in your transaction like a pubkey there that you need to show, and then with this construction, you would have to use another pubkey that you would also have to put there that is for this policy.

So we thought, why can we not just use the same pubkey, right?

So we introduced another really simple opcode, another push opcode, and it's called internal key, and all it does, it just looks at the control block, the taproot control block, it takes the internal key, and it just puts it on the stack.

This means that you don't have to specify a different key for your rebindable signature.

You could do that, obviously, if you want a different key than the root key, but then if you want the same key as the root key, you can just use one opcode and get the key on the stack.

So that means that to do a rebindable signature using our construction, we can basically use our three opcodes in a row, the template hash to create the message, the internal key to get the pubkey, and then check from stack to basically check the user signature in a very elegant three opcodes script.

This turns out to be just 68 bytes, so it kind of, for fairness, I also gave the other proposals the internal key benefit, but still, we're as efficient as APO for doing rebindable signatures, and we're just one weight unit, which is a quarter of a virtual byte less efficient than CTV for doing the next transaction commitment, so we feel that this strikes a really good balance for doing both constructions and functionalities in a single proposal.

So, yeah, that kind of sums up BIP448.

It's trying to do rebindable signatures, next transaction commitments, both in a single proposal with three opcodes.

The opcodes are specified in individual BIPs.

We have a website which brings you to GitHub where there's a list of different projects of people working on proof of concepts, also the BIPs you can find there.

So what's next for this proposal?

Obviously, people need to learn about it, so I'll go to these websites.

I might have accidentally broken the redirect, so I might fix that right after this talk, but it might also work.

I'm not sure.

Yeah, it works?

Nice.

And obviously, we need to build proof of concepts.

We need to show that this is a useful proposal, that Bitcoin gets better if it would adopt this BIP, right?

That's how BIPs always work.

So that's what we're doing.

And one proposal that would benefit a lot from this BIP is the protocol that I myself work on, that Matthew also talked about in the previous talk.

ARK actually was originally designed based on the idea of CTV, but because it seemed unlikely at the time that CTV would activate,

the companies that were building implementations of ARK kind of built a different version that kind of emulates some of the CTV properties using signed rounds,

which Matthew discussed to you earlier, which is a very interactive process where all the users kind of need to pass messages with the server at the same time,

sign a bunch of things, and basically be online for an extended period of time.

And this is really hard for mobile wallets.

So we have built-in different trade-offs where you can kind of be less secure to have less interactivity.

But with a covenant opcode like CTV or TemplateHash, ARK could have full security without having any interactivity between its users.

So as a proof of concept, I kind of implemented TemplateHash support in Bark.

It's live today.

So you can go to this website, templatehash.com.

You will find the URL of a server and a branch that you can check out.

So you can build Bark with TemplateHash support.

You can connect to a server.

And then because the server has a Lightning channel with our second Signet faucet, you can actually go to our faucet, request with Lightning a payment,

and you can actually get Lightning coins in with a TemplateHash ARK on the Inquisition Signet right now.

Then I have a few colored slides.

Most of my slides were black and white.

These are borrowed from a talk that unfortunately we will not see today because Greg Sanders, my colleague, was going to talk about some other work that he's been doing,

but his flight got canceled and he unfortunately cannot make it.

So I kind of took two slides that I really liked from his presentation where he's basically plotting many of the off-chain Layer 2 constructions in some kind of spectrum

from someone can take your coins to no one can take your coins.

Basically a custodial to fully on-chain trustless.

And ARK has kind of the different modes, like I said, because we felt like the interactivity was kind of impeding mobile usage.

The interactivity was impeding mobile usage.

We kind of introduced different modes where people can choose to be either fully trustless but need to do interactive work regularly,

or people can kind of have a slightly less trustless trade-off, but then have the ease of being able to do it on mobile.

So there's a few different modes in ARK that go from more or less, well, you kind of trust the server to do right stuff,

to like, I'm totally safe, but I need to come online and co-sign stuff.

And with TemplateHash or another covenant opcode, we can kind of be fully trustless in all the modes with the full UX that is mobile-friendly.

So, yeah, thanks, Greg, for the slides.

Hopefully you guys will be able to see his full presentation at some other point, because it's also really, really nice.

So, yeah, you can visit this to try it out, and this kind of sums up my talk.

BIP448, definitely check it out.

We have a website.

We have some proof of concepts.

The BIPs are there.

Thank you all.

I hope you have some questions.

APPLAUSE

Okay, we have some questions.

I'll start from here.

Come back.

Just a quick question.

So, every single time when you have one of these introspection to match up for CheckSig from Stack and CTV or any of that stuff, right,

are you feeding in that same transaction hash or DX hash or whatnot every single time?

Because on BCH, on Bitcoin Cash, I think it's the same CTV kind of mechanisms, right?

We have something called CheckDataSig, which is essentially the same thing as CheckSig from Stack, if I'm not mistaken.

And what we've seen is that with some of these covenants that we've made, the more of the introspection that we need to do,

the more times we need to feed in that entire signature and whatnot and do that data check, right?

So, I was just wondering, because later on on Bitcoin Cash, we developed native introspection,

which is very similar to the idea of the internal key, right, where we're able to pick out all the inputs, all the outputs, amounts, so on and so forth.

So, yeah, I was just kind of curious.

Is it the same kind of data?

Like, how big would it be if you have a lot more of these introspections to match up?

I'm not sure how to answer, but yes, the CheckDataSig, I think, is the same as CheckSig from Stack.

I'm not sure if you had CTV on Bitcoin Cash early on, but if you have CAT and you have CheckSig from Stack,

you can also do really complex constructions to somehow look into the different pieces of the transaction

by basically deconstructing the SIG hash and then reconstructing it and then checking the signature.

And that's, like you said, it takes a lot of data in your transactions, but it's kind of a roundabout way,

and this is not the type of constructions that I'm talking about, because that's exactly what template hash or CTV kind of gives you.

It gives you, like, one opcode that can look at a bunch of relevant information condensed together,

and you don't have to do, like, CheckSig from Stack CAT shenanigans to be able to do that.

So, yeah, obviously, direct introspection opcodes, like this one.

This one is a very simple one that gives you only a summary.

Liquid, for example, has, like, give me output one, give me output two.

It is, like, very fine-grained introspection opcodes.

They're obviously also useful.

There's a lot more bike-shedding to be done, though.

So this is a very simple proposal.

The primitives are very easy to reason about.

They're very safe.

So, like, we feel that this is a good first step, and then hopefully in the future maybe enable more fine-grained introspection,

like either the direct introspection opcodes or something like TxHash or something like Optx,

where you can actually say, I want to know this about my transaction and give it to me.

But, yeah, that's definitely future work.

More questions?

I have a question.

Kind of a small question, I suppose.

How did you decide on the name TemplateHash?

It's a very canonical name.

I can imagine in the future we might have other opcodes for other templates.

Well, that's a good point, that there could be multiple templates.

I mean, we borrowed the name from CTV, right?

The word template kind of got introduced using CTV.

You do check template verify, so, like, you have a template, you check it.

We just calculate the template.

We think just a summary of all outputs plus a version, the log time, it's kind of you could see of it as a transaction template.

You just don't know how you're going to fund it yet, right?

It's definitely just a random name.

I know that CTV was earlier called Secure the Bag, and then earlier version was called Check Output Hash Verifier,

something like that, so, like, there's definitely been backshedding over the name.

We just settled on this because the word template was kind of already used, so.

Thanks.

You mentioned that one of the main differences between CTV and template hash was that CTV commits to output amounts, whereas template hash doesn't.

Is that right?

No.

CTV doesn't commit to the amounts.

Sorry, yeah, that was maybe a confusion.

So, here I said that we looked at the Cache All machinery, and then these were the differences from the Cache All machinery, but not necessarily from CTV.

Okay, thank you.

This is a difference from CTV, though, so we commit to Annex, and CTV doesn't.

Mostly because I think at the time the CTV was specified, the Annex didn't exist, so, like, they couldn't have made that decision,

so then we were like, okay, should we do it, should we not, and eventually we decided to do it.

Yeah.

Any other questions? Matthew?

I understand that one of the differences between template hash and Tx hash is that you're not selecting individual transaction fields.

I was wondering why return to taking a template, taking a hash of the entire transaction rather than just selecting the fields that you want.

Good question.

I think the answer is twofold.

Mostly bike-shitting.

Like, if you want, like, so maybe some introduction.

So, Tx hash is another proposal that was originally coined by Russell O'Connor, who I saw here yesterday, but then authored by myself as a bib,

which is similar to template hash.

Like, it hashes some stuff from the transaction and puts it on the stack,

but instead of template hash, which gives you only one option,

Tx hash basically gives you a variety of methods on how to specify which exact fields of all the stuff that you can see here,

plus some other ones that you want to get hashed into your hash.

And obviously, with all the things that gives you options and choice, there's a lot of bike-shitting.

So, like, well, which ones should we allow, which ones should we allow to be hashed more efficiently than others, right?

And then the second argument was mostly, like, code simplicity and code review.

The template hash, because we're reusing the SIG hash machinery, it's actually a very small amount of lines of codes,

because all of these hashes are already pre-prepared for the SIG hash.

We just take a few of them from the SIG hash and then hash them together, and it's, like, that simple.

So, it's, like, very simple, very easy to check for bugs.

But the code that I wrote for Tx hash is definitely, like, maybe one or two orders of magnitude more complex.

It has, like, bit fields that allow you to, like, specify and select different fields.

And it's also because one concern with this kind of construction is denial of service.

Like, if someone would put a whole bunch of these different Tx hashes, it could cause you to hash, like, a lot and a lot of data.

So, it's important that the implementation has proper caching strategies.

So, the caching strategy that I implemented for Tx hash was also a little bit complex.

More complex, definitely, than the SIG hash cache strategies that we have in BigConcord already,

because there's only a handful of different options, so it's easy to just pre-prepare them.

But for Tx hash, the options are kind of infinite, so you need to have some kind of at-runtime caching

to make sure that when a user is just smashing you with the same hash, you don't go do the work all over again.

So, yeah, it's definitely a combination of backshooting, and just, it needs more time and more review.

It seems that this is something that is very safe and very straightforward that we can get consensus on,

while Tx hash might take a lot more time to get, like, right.

Yeah, I was also wondering about, like, Tx hash versus template hash.

And you mentioned backshooting is, like, the main difference, and also the implementation or the review difference.

But I feel like if you have a very specific template, you mentioned multiple times that it's not clear which template is the correct one,

or you might have someone who wants to build something else, which is not ARC, but they would need a slightly different template.

So I feel like when you think about it like this, it's much more complicated to come to consensus on one specific template

instead of having this general option to just choose which fields you're interested in.

Yes, that's true. I mean, there's not much I can say about that.

Tx hash is another proposal that does exist.

It doesn't have as much momentum because it needs a lot of work to be done,

and it doesn't seem that people are very interested in doing that work.

I myself am building ARC, so I don't have time to dedicate time to implementing and refining Tx hash.

So these are opcodes like these two kind of already existed as ideas.

This one existed as an implementation for a very long time.

Internal key, the implementation is also that simple.

And then template hash is actually also very simple.

So this is something that, like, the code has been there.

It's been merged in Inquisition.

There's a PR ready for core or already published or not yet, but definitely in the pipeline.

And it just happens so that it can do almost everything that we want.

I mean, the only, like, real use case that people are looking at today that is hard to do with template hash,

I'm not sure if it's still impossible because people always find ways,

is the BitVM bridge design for the latest version of BitVM.

They kind of wanted a slightly different template that is kind of just really specific for BitVM.

Unfortunately, you can't do everything.

This is just a template that makes sense.

It's kind of everything that you need to keep your TXID stable plus the annex.

And, yeah.

Thank you.

I definitely feel encouraged to look at TX hash, look at the codes,

replace the branch because it's a few years old, review the codes,

propose potential changes, and maybe, like, it can happen,

and it can be either a next soft fork or it can replace this one.

I mean, we never know, but it seems that this one has a path towards consensus

way earlier than something that includes TX hash.

Any other questions?

No, so thank you, Stephen.

Thank you.

Thank you.

Thank you.

My name is Calvin.

I work on—well, I'm prominently known for working on the UTREXO project.

Nowadays, I also do a lot of work on BTCD as well.

These are both Bitcoin node implementations that are not Bitcoin core.

If somebody is already running a Bitcoin core node at home,

they usually think, like, it's either, you know, I run a core or I run not.

In what scenario would somebody end up running BTCD or even UTREXO?

Okay, so with BTCD, it actually used to be pretty performance,

and it had all these features.

It was very well-maintained back in 2014, 2015.

It sort of went a little bit unmaintained, a little downhill,

but then now it's starting to pick up again.

And so, like, in 2017, why would you use BTCD?

If you like Go, if you like developing on it, you would.

But nowadays, I guess with BTCD, there's going to be features that Bitcoin D doesn't have.

Namely, well, address index has been there forever.

We're working on Electrum servers.

We're working on a bunch of performance improvements

that are going to land before Bitcoin core, and so I'm excited about that.

And so, like, we're hoping to make it more cutting edge, more feature.

I guess lots of more features,

and those are probably the reasons why you would probably want to run BTCD.

Well, I associate BTCD with LND.

If I was to be running an LND node at home, would there be any benefit?

Like, it works better if I have it with BTCD?

So it used to be that LND only supported BTCD,

but now it supports Bitcoin core as well, and so now there's no difference.

Like, that used to be one of the reasons why you would run BTCD,

because you want to run LND, but that's no longer the case.

So, if you do run an LND node, right now I don't think it matters,

but the code that is used by LND is part of BTCD.

Like, BTCD is very modular, and you can take different packages from it

and use it in other projects as well,

and so LND uses a lot of the same code from BTCD.

So, if you're using LND, you're using a lot of the BTCD code.

Correct me if I'm wrong,

but I believe that when Barack took down the Lightning Core,

it was related to BTCD.

That was entirely BTCD, yeah.

Tell me the story. Who is Barack and what happened?

Oh, Barack, well, he's most known now for being the creator of the ARK protocol, right?

But before, he used to be more into...

I guess, at the time, he was working on...

Shoot, what's the... like, liquid stuff?

Covenant stuff, I believe, at the time,

and then he was looking into all of these things,

and I think he just found this bug on BTCD,

because maybe he was working in Go at the time,

and so he found it, and he was like,

well, let me just crash everything.

So, yeah, that's how it happened.

And that took down the LND node?

That took down all the LND nodes, yep.

And now, Lightning Labs launched their own ARK?

Yep, they just announced it like three days ago, right?

What's the difference between BTCD, Utrex-OD, and Floresta?

Okay, so all these node implementations.

So, yeah, Utrex-OD is...

Well, let me explain BTCD first.

So, BTCD is just a completely alternate implementation of the Bitcoin protocol written in Go,

and that's BTCD.

Utrex-OD is a fork of BTCD.

We were using...

So, we just took BTCD, forked it,

and put the Utrex-OD accumulator in there,

and that is Utrex-OD.

Floresta is a completely alternate implementation,

and while the library itself was something that I was heavily involved in,

the node itself, like the Floresta, the node,

is completely done from the scratch

by Davidson, Sousa, and a lot of the guys from Vintium.

So, there are these three alternate implementations,

and I guess that's how they relate.

Floresta and Utrex-OD relate because they both implement the Utrex-O protocol,

so they can talk to each other,

but there's no code sharing in between them.

Cool. Thank you.

All right. We are at the center of Bitcoin. Bitcoin is governed by consensus, not authority.

So, that much you already know because you're here today. So, node runners collectively

steer the future of Bitcoin. Node runners are human, but how do we know what's good for Bitcoin?

And what if the main attack vector is actually education, meaning access to information?

Because most Bitcoiners want what's best for Bitcoin, but decisions are made with often,

or sometimes incomplete, emotional, or biased information. So, how do we know what's actually

best and good for Bitcoin when a new consensus change arrives, when a new soft fork arrives?

How do we know? How do we have access to relevant information? When information is scattered

on GitHub, mailing lists, podcasts, YouTube, we can listen to big voices that cite the technical

information and mix it with emotional things, we can say. Here we can see education is the bridge,

or a bridge, between users and consensus. That's why we built JustAskBips to help

non-technical node runners understand consensus proposals and their second order of implications

that are often technical. And here, today, we're going to demo you our two main features,

which is how we let non-technical users talk directly to the Bips through an ILM interface,

and our sentiment analysis market on each Bip built on Nuster, thanks to Shakespeare AI.

I'm going to let you give the demo.

So, as Hugo said, we built an educational tool whose main goal is to explain to non-technical

people what is a Bip, how a specific Bip works to make a very informed decision. So, we took

the whole Bip repository, we filtered for those changes that are consensus-related, so any soft

fork that we could had, we had during our history, and that we are going to have probably in the

future. And we put them here in this very nice view where you can see all the Bip that we have,

all are divided by whether they were closed, deployed, whether they are complete or still in

draft, and you can see for yourself, and you can decide that you want to know more about a Bip.

For example, you want to know more about Bip 54 consensus cleanup. You ask the Bip, and we are

linked to an LLM that will give you a very plain explanation of what the Bip does, what the Bip is,

and what is it all about, what actually changes, so that you can actually understand from the main

source what it's all about. In this case, the answer was cached for simplicity and speed.

Here you have the whole Bip, so you can actually read the whole Bip itself, so you don't have to

really trust the LLM to do a real summary, but you also have the whole thing here. And now I'll leave

the floor to Miguel for the last part. Oh yeah, we also have another feature, sorry, where you can

actually ask more questions about the Bip, so you can ask him, for example, who are the authors.

I hope it goes fast. And it will give you, yeah, here we tell you, yeah, Antoine Ponceau and Matt

Corallo are the authors, so you can chat with the AI. And final step, Miguel.

So the purpose here is for non-technical people like myself, once I understand what is this

proposal, what is the change, is this good for Bitcoin, then I would like to go and say like, okay,

how is the network feeling about this change? And what it's doing right now is going to Noster

and assessing all of the different posts to understand who is for, against, or neutral,

and that will help me also make my informed decision. And I can even vote myself as well,

so that it can help me share more about my point of view. The other thing too is that

in these last 30 seconds, the goal of all of this is we are democratizing access of

technical information for everybody, so that everybody can be part of consensus. Thank you.

So if there is any question, we will be very glad to answer.

Given that you're using AI to go summarize Nostra sentiment, if I understand correctly,

have you put any further thought into how you could go and prevent civil tax on Nostra?

Not yet. Honestly, the idea is to have an LLM scrape the relays for Nostra,

not yet. Honestly, the idea is to have an LLM scrape the relays for actual sentiment of a

note, for example, and see what the note really says about the BIP if it's positive

or negative sentiment. But we had no further thought than this.

So not to relay only on the Zaps, which can be faked.

Great job, team. Just ask BIPs.

Thank you, everyone.

Now I'm going to talk about Bitcoin Kernel, MCP. If you've ever asked an AI agent to reason about

consensus validity for you, then you probably have seen that it takes quite a long time.

It's slow. It burns a lot of tokens. It also likes to hallucinate often. And that's because it's,

of course, not a very straightforward answer, because it basically needs to build its own

tools in the background and pull in a lot of information to give you an answer. And, of course,

in order to improve what agents can do, we give them tools. One of these standards for these tools

are MCP servers. And we really already have the tool that we need for giving these answers

correctly. And that's, of course, the Bitcoin Kernel library. So what I did is I wrapped the

kernel in an MCP server that agents can use, install, that makes them fast, cost efficient,

and gives the correct answers. So the capabilities of this MCP server are very simple.

So the capabilities of this MCP server are 17 tool calls that are reaching directly into

the kernel library. What is provided for the context-free answers, it can give them almost

instantly. Then it has a sandbox mode where it allows it to mine a local chain in rec test and

then reason about changes across blocks with that. And it can also access the local data there if

you give it to that to pull in context. So we'll jump straight to the demo. I have a couple of

prompts prepared here. So we're playing in hard mode. This is Heiko 4.5, the cheapest and stupidest

model that you can get access to in code. And at least it can do the ASCII art it told it to do.

So now we will ask it to tell us if a block header is valid. This is a block header from a

recent block. It's calling the tool here, the kernel, and it should give us an answer

that this is a valid block and it extracts some information. So this is almost the same prompt,

but it has one bit flipped. And that makes the proof of work invalid. And we ask it again,

and it's going to call the tool again. Hopefully it will tell us that this is not valid. No.

So the proof of work is invalid. It's information that otherwise it would have probably taken quite

a long time to collect that. Now I'll show a transaction. And for additional, making it a bit

more challenging, this is a coin-based transaction. So if an agent would just build some kind of

basic transaction parser, it would probably stumble over this, that this is a coin-based

transaction. And so this, of course, should get it correct. You can see the tool calls here because

I've configured it to confirm that. So yeah, this is correct. And it should tell somewhere

that it's a consensus valid transaction, et cetera.

So here I have a raw block. This is block 170. The block famously where

Satoshi sent the first transaction to Hal Finney. And this should also tell you that it's a valid

block. What is funny there is this model is so stupid, it still manages sometimes to hallucinate

some stuff. So actually, like yesterday, it told me this was actually block 100. And when I asked

it why, it said, like, I don't know. Yeah, but it can tell us this is a correct block.

And then I'm not sure if this is going to finish in time, but I wanted to show the sandbox mode.

So I'm going to ask it to use sandbox mode, mine a couple of blocks, and then tell us what the

heights, what the coinbase amounts are between heights 149 and 150. So because it's reg test,

there's going to be a halving between these blocks. And so this just shows how it can use this local

reg test chain to reason about certain changes and give answers to certain questions that are not

with these completely context-free calls answerable for the kernel library. So this is

going to take a little bit of time. Maybe it will finish now or when I answer the questions.

But yeah, I don't really have anything else to say. I can already start answering questions,

and maybe we'll see the answer while I answer the questions. Oh, there it is.

What's next for the project?

I really don't have that much more to add right now. It can make it a little bit more efficient

and convenient, of course, to get things right all the time. You can always add more better

instruction, better documentation, of course, for the agent to use it more effectively.

But especially what I saw there is that the kernel library still could use a few more things,

a few more features. There's new PRs open there all the time for new calls. But some of them have

been kind of like, OK, maybe let's see if they actually need it for the community. But with this

more versatile usage of the kernel library, I think I, for the first time, felt like, OK,

there's this thing that I would want the library to do and this other thing that I would like it to

do. So yeah, I think the most excited I'm for this tool is when the kernel itself adds more

capabilities as well. Great job, Bitcoin Kernel MCP. Thank you.

Hey, everyone. I'm Connor. For people who don't know me, I am researching the Corverse

Nods debate. And my number one complaint when trying to translate that into a properly academic

paper was that, man, I really wish there was a nice, organized way to discuss consensus with

other verified node operators. And so it got me thinking. And also, when I started Node,

I always got so excited when I found out our peer connection. So I wish there was a way to, like,

say hi to these guys and, like, hear about them and, like, especially, like, hear about, like,

what they're signaling for or what their beliefs are, like, what that got them into Bitcoin,

just socializing with them. And there's simply just no way to do it right now on the Bitcoin

blockchain. So welcome to Node Signal. So here is a demo of what it's supposed to look like. It's

pretty much just I wish it scaled better to the screen here, but it is a node map where you can

see all your connections, what their implementations are. If you hover your mouse over,

it'll show you what they're signaling for. So, like, this example node is signaling for

bit 110, for example. This one's not signaling for anything. This one's at bit 324. And you can go to

the messages tab, go through, and, like, it's all encrypted. I use that term lightly, of course. It's

just a four-digit pin. But you can see, like, just fake messages. You can text back and forth and say

hi, and you'll get, like, random messages back. What was really cool, though, was figuring out

how to actually connect it. So this blinking one down here is actually my Bitcoin node connected

to this program. So I can click on this and send a message back and forth. And when I presented

this yesterday, there was a big problem. There was simply no way to actually do this over the

Bitcoin blockchain, right? Like, Bitcoin does not allow for this. So the big solution was pretty

much redesigning the entire program and installing it directly using a tail scale onto my Bitcoin

node all the way in Tuscaloosa, Alabama. And that is what I managed to do last night at about

3 a.m. This is my actual node and my actual peers. And that green line you're seeing with the

blinking live is the demo program that I was just showing before. So I can now go here, text on this,

and it shows our entire chat thread, including when history was made at 2.39 a.m. And I was really

happy, as you can see. And even shows when things aren't delivered. So it confirms it goes to sent,

delivered, not delivered when it was simply just off earlier. And, yeah, and it still allows you

to send it back and forth. And I know it says my internet's not connected. I can assure you it is.

It's just a weird gray hall of Wi-Fi here. So I wanted to explain this a little bit more.

And so I had this little quick slide show for the last two minutes here, where this is essentially

what it is. It's got a nice pretty AI-generated logo and everything. A peer-to-peer social

networking that essentially piggybacks off the connections that you already have on the Bitcoin

blockchain through your peers, and uses that information to then send messages and have its

own WebSocket on top of it. So here's how it actually works. So the hello, where you get the

signaling from and everything else, is still normally just port 8333. On top of that, though,

is the peer-to-peer messaging through port 8788. And then the WebSocket UI is port 8789 on your

server with your Bitcoin node on it. So it all just is on top of it. It doesn't really mess with

Bitcoin blockchain, all besides from just saying hello, which your node does anyway. So here's what

was actually happening in that messaging that I showed you there. So it goes from here in Toronto,

encrypted, again, use that term lightly, then it's through my TailScale VPN. That's how I

managed to install everything, get it to work. It receives and decrypts, and then you can see it on

the WebUI again through TailScale on either side, and then it just goes back the other way.

So obviously, there's some still big things to address here. Some big disclaimers. It obviously

opens up a huge attack surface in its current form. You can just IPv6 bomb them, essentially,

and crash the entire node. So I would not recommend installing this yet until we figure that out.

And obviously, as I represented earlier, the identity can be faked if you just set it up so

that can happen. That was intentional because I wanted to be able to test this because this

laptop does not have a node on it. Encryption is definitely not secure at all in its current form.

Take a CPU like nine minutes, I think, to crack a four-digit PIN code. And obviously, as proof of

this conference, they're a way better way to make friends through Bitcoin than texting random nodes

that you don't know. But yeah, that was my presentation. Thank you guys so much for listening.

I have a question. What was the hardest part about making this project?

Definitely getting it to actually be a messaging system and not just a cool proof of concept.

Getting the proof of function was a major challenge, but once it finally worked,

it was extremely satisfying. The hardest part now that I think is going to be the most difficult

part is going to be seeing if I can even make this truly secure for not only just the node itself,

but for the messaging system, and just in general, just safe, which on a trustless network is pretty

difficult to do. Great job, NodeSignal.

Hi, everyone. I'm presenting compact block filters in Bool. Basically, Bool is a wallet that is available

on mobile and is dedicated to privacy, self-custody, and we are working on it in coordination with the

Bool Exchange. I'm one of the maintainers, and this is my profile when I had hairs.

This is an open-source repo, because obviously a wallet should be open-source.

We are a Flutter, Dart-written wallet, so we are available on mobile mainly for now,

so iOS and Android, and we are using the BDK bindings that were presented on the first day

of the conference. On the second day of the conference, they presented the compact block

filters, so I wanted to give it a try, because as of today, I don't know if you are aware,

but if you use a wallet and that relies on Electrum, and it's not your Electrum server,

when you sync your wallet, you take the risk of revealing your address to this third-party Electrum.

Obviously, in Bool, you can already set your own Electrum server. You can also use Tor,

but it doesn't mitigate that much the problem, because your IP is switching only every 10 minutes,

so you can still be clustered by the third-party Electrum server. It was interesting to me to

learn about compact block filters and to experiment to integrate it in Bool.

Unfortunately, I don't have an emulator on my laptop, because RAM is expensive, so I have a video

that I showed yesterday. This is basically the flow that I presented in the first APK yesterday

to the jury. So, this is a wizard of BoolBitcoin. Sorry, it went a bit fast, but

you can customize some stuff. You can customize the theme, language, and currency, but

it's not why we are here. You can decide to participate in the report program, and I encourage

you to do so, because it helps us to prioritize the issue. Here, we have the new screen that I

added to the wizard, which basically allows the user to enable the compact block filters.

And here, we can recover the wallet, and here the screen will go dark, because we have a screen

protection that is enabled by default to avoid people taking screenshots and stuff like this.

So, I have to fast forward. So, here is the start of the synchronization through

the block filters. So, we are querying in the peer-to-peer network. We are trying to find

peers to request to first sync the block heights, and then collect the block filters.

Because it was yesterday, and my Wi-Fi is not so good, and we are syncing from the Genesis block,

it will be super long. So, here we are connected to the peers, and now we see the chain height

starting to increase. So, what I changed between yesterday and today is to improve the user

experience. I let the user add a wallet birthday, and we sync only from this period of time. So,

if you know at what date you create your wallet, we will not sync from the Genesis.

Unfortunately, the UI is a bit broken on the latest APK, but I can show it to you if you want

to try. And for new wallet, obviously we shouldn't sync, because we are setting the wallet birthday

ourselves. So, the trick was a bit... So, the wallet birthday is a date, and we need to find

which block is close to that date, because the API of Kyoto is taking the block 8 and the block

hash. So, to find a solution to this problem, I'm using the mempool API that we used to propose to

the user the fee estimation. So, that's the way I found to properly sync from the wallet birthday

date, basically. And that's it for me, I think.

Do you have a rough idea how long it takes, and maybe more importantly, how much data it consumes?

So, I guess it was told during the speak of the compact block filters, but I think it's

something like 12 gigabytes. I didn't try to fully sync, because I don't have that much

data on my contract, on my prepaid SIM, but it should be something like 12 gigabytes in the

worst case. But with the wallet birthday thing, we can reduce this problematic. Also, we can imagine

that in the future, we would sync in the background to let the user navigate in the wallet before,

like, instead of making him stuck on the UI, because it's very frustrating.

Great job. BDK compact block filters in bold.

So, can you hack Bitcoin? Can you? Anyone? No? Yeah, it's unhackable right now. We won't go into

the whole quantum computing stuff. That was yesterday's question. Today is, in this current

state, can we hack Bitcoin? And the question is, no. But why? Try to find someone and explain it

to them. Why can't you hack Bitcoin? It's hard to explain. It's a bunch of math, a bunch of

encryption, a bunch of cryptography. It's complicated. No one's going to understand it.

But what if there was a fun little game that made it really easy to understand

why you can't hack Bitcoin? And that's exactly what I'm going to be demoing today.

So, let's see if together we can hack Bitcoin. We're going to start with the easy level,

shrimp. And what we're going to do is we are going to get a number, for example, 93,

and we have to figure out what two prime numbers multiply to make 93.

I'll give you a little hint, it's divisible by three, so you know one of the prime numbers already.

Let's figure out the other one. Let's say math is foggy, let's say it's 12. Let's see, is it right?

Now, 3 times 12 is 36. Really nice, they tell you how far off you are.

Let's try again. Fundamental math trick, 9 divided by 3 is 3, 3 divided by 3 is 1.

31, let's see if we crack it. And look at that, access granted. Turns out we can hack Bitcoin.

Now you can claim your SATs. So I have my wallet here, wallet of Satoshi.

Put it on the QR code, receive, and as you can see, SATs are live.

This is in production. I just won one SAT. I'll try not to spend it all in one place.

And it's also integrated with Wavelength, so it is on Cygnet, not real money,

and it's 1,000 SATs instead since they don't allow dust, but it generates.

So this is the easy version. You can get a bit harder. Now it's three digit numbers,

definitely increase in complexity, but let's try the hard one, the Satoshi one.

Let's see what we get here. Wow, that's a big number.

If you can shout out the answer right now without using a device, I will personally send you a Bitcoin.

But if you can't do that, we can cheat. What is cheating? Well, you can buy the answer.

So it will cost you double the reward, not the most profitable, but you can do it.

I'll do it. I've got my wallet ready. Let's see. Scan it. There we go.

I'll pay the six SATs. Great demo on Lightning Network 2 at the same time.

There we go. We bought it. Both primes are now filled in. Look at that.

We figured it out. Let's double check it's right. It is.

Now the most exciting thing is that this also is on the real blockchain with open timestamps.

So now everyone here saw that I was able to hack Bitcoin even with such a big number

because the blockchain doesn't lie. So it's obviously true.

Now a little bit of disclosure on this. This is sort of the basics of RSA encryption

rather than elliptic curve cryptography. So not exactly Bitcoin.

But a game for Bitcoin and ECC was a little bit more complex.

So I thought I'd keep it simple because the idea is the same.

The reason we can't hack Bitcoin or any encryption based on cryptography

is that the math is really easy going forwards. And once you know it and you have the answer,

but going backwards is practically impossible at the level of computation that we have today.

So that's my presentation.

What was the most difficult part about shipping this project?

I really wanted to make it based on Bitcoin and ECC.

So I spent quite a bit of time trying to think about a nice game with proper progression.

Didn't find that in the right time frame. So stuck to the good old fashioned RSA.

Great job, team. Can you hack BTC?

Thank you.

All right. Hello, everyone. I'm Curtis with Template Watcher.

So in 2,000 blocks or so, BIP 110 is going to activate.

And the thing everybody is watching is the signaling percentage from miners.

And there's resources where you can look at this, such as this open source one from Kilombino.

But I believe that the signaling percentage is not the right thing to be watching

in the lead up to the activation.

The right thing to be watching is the number of miners or the number of blocks

on a per miner basis that are compliant with BIP 110 but not signaling.

So I created Template Watcher.

And yesterday, the data was based on Kilombino's website, pulling from his API.

But I have ported it over to my own node, so it's pulling the data from my own node now.

And when you go to the website, you will see a watch feed,

which currently says no positioning detected because no miners are positioning,

no mining pools are positioning for BIP 110 yet, if they ever do.

But when any blocks come out that are positioned for it, they will show up here.

And then I have the pool matrix, which you can sort by pool, blocks, block number,

block signaling percentage, compliance percentage, and then compliant but not signaling.

And I believe that this is a good indicator because it's harder to become compliant

than it is to signal for compliance, and no miner is incentivized to do that.

But they will start becoming compliant on the lead up to the activation date if they're going to flip.

And then down here, I have some charts, which show on a pool by pool basis.

And there's some block ranges here.

So these are difficulty adjustment periods, and you can sort it by that.

And so on the far right, you'll see the mandatory signaling deadline.

And so I would expect if any mining pools are thinking of switching or are planning to switch,

you'll see these lines that are flatlining at the bottom, or there's very little variability,

you'll see those start to climb very close to that line.

You can also see which ones are signaling, and as you can see, there's none except for ocean right now.

And then, of course, I have some information about the compliance rules.

So this is a neutral, non-opinionated data source, fully on my own stack, and it's live right now.

So you can go to templatewatcher.curtisheinen.com and you'll see exactly what I'm presenting here.

On the back end, there's an indexer and an API, and the indexer just pulls from my own node,

and the front end just pulls from the API and displays the data.

The front end is doing all of the analysis here.

Yesterday, everything had been fully vibed with Shakespeare, which is by Soapbox,

but since yesterday, as I ported it over to my own stack, I used a lot of Cloud Code as well.

So this is fully vibe-coded.

And yeah, this will be up until after activation day, so if anyone wants to follow along,

they can just go to this website and it'll stay up.

That's good. Thank you.

APPLAUSE

Have you considered making test transactions to validate if the compliance rate actually reflects transactions

in the mempool that could be mined, rather than just random luck?

I've considered it, but I haven't done it.

Great job, team TemplateWatcher.

APPLAUSE

Thank you.

All right, that concludes our finalist presentations.

Can we get another big round of applause for all of our finalists?

APPLAUSE

Thank you.

MUSIC

Hi, my name is Jerry.

I'm the founder of OptinLabs, and we're building out a lot of the user interfaces

to help users control covenants, introspection, and just better guardrails for their funds.

Right now it's on Bitcoin Cash, but hopefully Bitcoin soon.

Yeah, I noticed you have a Bitcoin Cash shirt on.

Can you tell me a little bit about why you like Bitcoin Cash?

Yeah, I mean, I won't go into too much detail, but for the context of this conference,

a lot of it, quite honestly, is just down to the covenants and the introspection capabilities.

There's something that's very similar to, I would say, CTV and CSFS on BCH,

and a lot of issues with that implementation, I guess.

But yeah, I just wanted to share some of the insights with people

and see how exactly we can incorporate covenants and introspections on BTC later on.

I heard this line that Ethereum is like the Bitcoin testnet.

Do you think that Bitcoin Cash has been like a Bitcoin testnet for trying out different stuff?

I mean, same underlying tech?

I think right now a lot of the companies are really just defaulting to Ethereum

because they're looking for the smart contract capabilities to better control their funds.

We were just at the Blockchain Futures conference earlier this week.

There was a Bitcoin Cash booth, and most people didn't even know that

there's all this programming capabilities, tokens, all this kind of stuff.

We have DEXs, stable coins, and whatnot.

So I think it's a good stepping stone into getting more of that programmability

into something like Bitcoin itself, just because the architecture is way more efficient

than anything like EVM or Solana or whatnot.

And just to say, Jerry, you're a true Toronto Bitcoin OG.

You've been part of the Bitcoin community since I first met you many years ago.

Tell me about your origins of Bitcoin in Toronto.

Yeah, so I started out with organizing Bitcoin meetups, Bitcoin Bay meetups.

Unfortunately, in Toronto, it's a birthplace of Ethereum,

so very, very quickly exploring other things.

But yeah, no, it's a lot of meetups that we were doing.

We try to get people to come out, show up, do their demos,

talk about some of the new emerging things that are coming out,

and really just try to keep the community spirit alive.

So yeah, that's basically the main thing.

And I'm glad that a decade afterwards, when I started in 2014,

there's you guys doing all these meetups.

There's everyone else doing all their meetups.

So it's good to see that.

Excellent. So you're not, despite being a B-cashier,

you're not actually against Bitcoin.

And if Bitcoin had the functionality that you wanted,

you would come over to Bitcoin and build your projects here.

It would make bridging a lot easier, right?

So we can do things like, but yeah, like at the end of the day,

like all this covenant introspection and whatnot.

Like I was in OpNext in 2024, and the energy was great, right?

It was a lot of talks about all these covenants and whatnot.

And then one month later, everything got derailed.

So yeah, we're hoping that maybe by 2027, 2028,

some of these capabilities can come in.

Because as I said, there's a lot more of these interoperability.

I describe covenants as kind of like programmable checks,

whereas right now everyone is essentially just signing blank checks.

So a little bit more guardrail would be nice.

Thank you so much, Jerry.

Awesome. Thanks so much.

Hey, everyone.

We are starting again after the hackathon finalists.

Right now, our next guest is Paul Sztorc,

and he's going to talk about stuff he's working about.

So please give him a huge welcome. Thank you.

Thank you, guys. Thank you very much.

That's the actual title.

That's the stuff we're working on.

But I think you guys will get a lot out of it,

because I have a lot of unconventional views,

and I'm working on a lot of stuff that's actually pretty cool, I think.

So I thought it would be like 15 minutes to just sprint through.

This has barely been enough time to touch on a few of the things that we're doing.

And then I thought we could do Q&A.

But, you know, we'll see.

I normally rehearse the talk to death, but I didn't really time it.

So we'll see how these times end up going.

The first thing is this idea of drive chain that you probably have heard of,

which is BIPS 300-301.

And it creates this layer 2 side chain that was coined by Blockstream.

And the idea is it's a separate blockchain,

and it's merge-mined, and this is key.

When you withdraw the funds back,

it's a slow withdrawal that is acted by miners.

So the idea is that the miners farm up the chain with merge-mining for money,

and this encourages them to keep the withdrawals honest,

because the net present value, the fees they earn,

is always higher than the total amount of coins on the chain

at any time that you could withdraw.

So if you're interested in this idea, this is the drivechain.info is the site.

But really, this idea, even though it's from 2015,

it's much better than the state-of-the-art.

It's much better than many other ideas.

So, for example, Lightning, if you use it as a scaling solution,

it has this onboarding problem that's unfixable.

It has this liquidity channel rebalancing problem.

It has a problem where the HTLCs cannot be enforced if the L1 fee rates are too high.

And it has this routing problem.

But none of these things happen in drivechain.

You can onboard people directly to the L2,

and you can do as many transactions as you want over there

without requiring any more L1 bytes.

So it's better than that.

ARK, it seems like ARK has been changing a lot,

but when I look into it, usually there's this idea that ARK has to be over-collateralized,

where there's a lot of transactions changing hands,

and you need transactions for every open payment.

That is far in excess of the coins that have actually been in use at any one time,

but we don't have that problem in drivechain.

There's no merge mining in ARK.

I suppose you could try to add it some way,

but the merge mining is key for a reason I presented up next,

which is that you don't want there to be a conflict of interest between the L1 miners and the L2.

So it's also much simpler.

And even stuff like snarks, which are kind of like they have these magical properties,

like super compression, but because of the data availability problem, it doesn't even matter.

And even snarks have this idea where maybe miners could theoretically steal from the drivechain,

but in the snark they could not.

It ends up not mattering because the miners don't want to steal.

They make more money by not stealing than they make from stealing.

So even if there was some kind of glitch where they accidentally stole, they'd get the money back.

So that's just a tiny thing for that.

And drivechain doesn't just do scaling, it does all this other stuff.

You can do whatever you like.

You have EVM chain.

We have a chain based on Namecoin.

We have a z-side privacy chain based on the Orchard Rust crate.

We have a prediction markets thing.

So you can do anything.

We've got the Elements Plus.

We have a bunch of stuff.

So it's actually a pretty cool idea.

The other thing is this Qsift, the core untouched soft fork.

The soft fork is this really great idea, but we can't do it anymore.

And so the question is how can we get the soft fork back?

And the answer is use soft fork Bitcoin without changing any lines of code in Bitcoin Core.

So this requires a second piece of software, which is the soft fork activator.

But it does basically what the lines of code would do.

Oh, I think maybe this got cut off a little bit.

But I think at the top, the left one.

Okay, no, I did it like this.

So Qsift is the left part.

You have a separate blue square.

And then in Bitcoin Core pull request, you'd have like some lines of code that throw invalidate block in the Bitcoin Core.

But in this, you have a second piece of software that checks the soft fork rules.

And then it calls invalidate block.

So it requires a second piece of software.

It requires 51% hash rate.

There is a little site, BIP300Qsift.com, although it's not limited to BIP300Qsift.

And, in fact, we have a new one made by Hunter Beast in part that has quantum resistant signatures to the L1 of Bitcoin.

And we're also going to add like OpVault and like OpCat to that one.

That will be like an experimental one.

But this has lots and lots of benefits over the core pull requests.

So you can just – one is that you can have competing benevolent dictators.

You just have different people just make one.

And now they don't have to go through the Bitcoin Core review process.

You don't have this kind of monopoly process.

So you have just one benevolent dictator on the right there.

Another weird thing is that the activator could be in any programming language.

It could be in Rust or it could just be in whatever you like.

Whereas if you do the Bitcoin Core pull request, not only do you have to go through the gatekeepers at Bitcoin Core,

but it has to be like C++, it has to be whatever the style guides are, CamelCase, whatever, et cetera.

So the idea is that we could reclaim the Qsift thing like this.

And then this other thing we have is called BitWindow.

This is pretty cool because this is very similar to Qsift really where it's like a different front end to Bitcoin Core.

Bitcoin Core right now, it has this Qt front end.

And I know there's some other – people have been talking about having a different front end for a really long time.

I have no idea what the status is of that, but I assume that it's taking forever and it doesn't quite exist.

So no one really likes the Qt front end.

And even it's a mainstream view that it should be ignored or not paid very much attention to.

So the cool thing is you have a different front end to Bitcoin Core.

You can put in whatever you want in there.

And it just pilots Bitcoin D and Bitcoin CLI under the hood.

And so we put a lot of cool stuff in there.

We have this thing, Multisig Lounge, user-friendly Multisig.

You have different wallets of different types.

You have like a BDK wallet, Electrum wallet, custom wallet.

You can put like a block explorer in there.

So I actually have a picture on the next page, which is that this is an example.

This is actually an old example.

We've added many, many things since this version.

But if you just see just from this alone, you have lots of different things.

So deniability is like a thing that sends your own coins to you a bunch of times.

So this is kind of like a move fast and break things type of idea where it's like you can just do whatever you want with this.

This is a cosmetic optional front end to Bitcoin Core.

So you can do whatever you like.

And if you want to do new things, this is the perfect place because it doesn't touch like actual Bitcoin D.

It doesn't touch consensus.

So, yeah, a lot of these things were in like Satoshi's original client or like old clients.

And then I think that the Bitcoin Core front end has gotten worse over time.

A lot of the stuff we did was just undoing what people did.

This is a very simple one, literally.

Simple pool.

So we were kind of asking, you know, why isn't there any open source mining pool software?

And we looked for some, but we didn't find any.

So we made some.

And we also have this idea, this pool hopper system where if you have SHA256D hash rate,

you just go to the pool hopper and it will just give you whatever gives you the highest PPS.

It will just do it for you.

It will just connect you to whichever pool is paying you the most.

So I'm a huge supporter of PPS, and I can explain why people are interested.

But if – and also the pool hopper will theoretically do something where if every – it doesn't really work yet.

But if it's like if every pool is bad, it will automatically create a new pool.

The reason why no one – because most of the pools today do a very good job,

and they don't do anything really bad, so it hasn't really been a priority to work on that part.

But the idea is that there would be this common project.

We have some people from Stratenvy 2 originally who are working on this.

And actually, if you use BIP300, it will pay people out on the L2,

which means that you could have 8 billion different miners, in fact, in theory.

Because they'd be paying out on L2, and so there's no actual bottleneck there.

And that's at this URL.

I'm a huge skeptic of Stratenvy 2.

I don't know if anyone wants to ask why, but I think the idea of the job selection is a huge mistake

and is a pointless and counterproductive objective.

And I also think of the pools as brands.

So I think it's very desirable that there be a small number of pools where everyone knows the name.

Because a brand is like a hostage that you can execute if the pool does something wrong,

whereas if instead you have the giant pie chart with lots of slivers,

then there's not as much accountability.

So that's – okay, this is good. It's going pretty well.

Yeah, I've been a huge shill for prediction markets on Bitcoin since the year 2012.

That's when I first started yelling about this.

And I have this site, bitcoinhivemind.com.

People can check out. There's lots and lots and lots of stuff there.

And, in fact, my name on Twitter is Truthcoin.

That originally comes from this paper I wrote in 2014 about a peer-to-peer oracle for Bitcoin.

Because there really weren't that many altcoins at the time.

And so this is a huge interest of mine, and I especially favor what are called these multidimensional prediction markets.

These are very cool.

You ask a question like which CEO would most increase the stock price,

or maybe which hard fork to BTC would most increase the exchange rate or something like that.

I have a lot of thoughts on this, and I think I have some.

These are old screenshots.

On the left is Bitwindow. It has its own sidechains tab.

You can add a new tab whenever you want.

And then this is downloading the L2 software and starting it up.

This is an old screenshot, so it doesn't even have the prediction markets software in the list over there.

And then even this is an old screenshot of the old.

This was from 2015 or something.

This is the old test prediction market software.

But we have new software, and it's not a great screenshot of it now, but you can download.

If you go to layer2labs.com download and you click all the buttons,

you can find your way into the new prediction market software.

I'm very interested in that.

Now, of course, I'm doing this infamous hard fork of Bitcoin next month,

but what I wanted to emphasize about this is that there's no real technical change to the software.

My proposal at the top here is this is the drive chain soft fork that has nothing to do with hard forking Bitcoin,

it's very collaborative and very conformist.

So that's just saying let's take Bitcoin Core and we'll add this Q-SYS activator for BIP-300-301.

So not changing any lines of code in Bitcoin Core.

We have BIP-300-301, and then these green boxes are the L2s.

So these are the L2s, you know, Thunder is the scaling, it's a high throughput scaling sidechain, then Bitnames is like the Namecoin style sidechain, and then you got Truthcoin DC is the prediction market sidechain, and there's a bunch of more.

So up top is the actual proposal that has nothing to do with hard forking Bitcoin at all. But beneath, the hard fork is just basically changing the name, dropping the difficulty artificially, which is what triggers the hard fork, and reassigning 500,000 of Satoshi's coins. But other than that, it's near identical.

And so there's no like technical reason to hard fork, it is really just intentionally to split off the community and get a little more competition injected into the community. My view is that competition, you know, which is a reward for error correction, that cures all ills, so that the idea is that we have been very complacent in BTC for a long time.

I wrote this article in July of 2025. So a whole year ago, called the derangements of Bitcoin, which is a long list of like weird things that the whole community is wrong about, and has been wrong about consistently for months or years. And we just cannot, we can't break out of, even though we're all wrong about everything, we can't break out of it. So the question is, are we doomed is a dramatic, dramatic question.

And okay, so I basically got it in basically 14, 13, 14 minutes. So that was the plan was to do 15, and then do Q&A. And then I'll be on this panel at 345 also. So thanks very much. I know that was kind of bizarre, but I really have my, I'm doing a lot of different things. So I thought that would be a cool thing to just briefly go over a few of them. So there you go. So I look forward to anyone's questions. But thanks a lot. Thanks for paying attention for that part.

Thanks very much.

Well, thank you so much for that. That was great, Paul. I wanted to hear more about what you don't like about Stratum V2, if that's not...

Sure, yeah, we can go back. So Stratum V2, I did write an article about this, but I think the main problem with Stratum V2 is, okay, it bundles a lot of things that are not controversial at all, such as you should have a lot of basic improvements and you should have more authentication and stuff. So all those things are fine.

But the main selling point of Stratum V2 is this job selection thing, which is that instead of the pool being able to choose what's in a block, the individual miner should be able to choose. And my question is, how could this possibly ever be desirable in any way? And also, it's not actually enforceable, because the pool is the one telling everyone else what to do.

So to me, the only thing it adds is the ability to actually sabotage the pool and get away with it, because you could join the pool with a tiny amount of hash rate, submit some terrible job where no one is earning any money, and then the pool says, well, listen, because of some guy, we have to do it. And then instead of being able to blame the pool, the pool can just push responsibility onto the...

So it's really this job selection thing that I have a problem with. I think it's actually fine for the pools to be... since we already need them to aggregate for the variance problem, I think it's perfectly fine to give... and if you have PPS, the pool is just saying, we'll pay you... they're bidding up the hash amount.

They're saying, we'll pay you this much for the hash price. So you kind of just leave it to them. You say, you pay me as much as you possibly can, and I'm not going to ask too many questions about what you're putting in the block. And I think that's actually best for everyone, because the individual hasher can just pick. So I don't know, does that make sense?

The job selection thing, I don't think... but this is a very controversial point for some reason, among some people. But I don't know if you agree or disagree. I think this job selection thing is a misconceived idea, especially because if you talk to real miners, they have no idea. A lot of them have no idea. Many of them are not even Bitcoiners, and they just have cheap power.

They just plug the thing in, and they just set it off, and they're trying to make money. So I don't know if you or anyone else feels very strongly that this job selection thing is... it's the only thing standing between us and transaction censorship or something, which has basically never happened, because there is very, very, very little... miners really don't misbehave. So they don't re-org blocks, they don't censor transactions. So I don't know if you think that.

I thought a while ago there was one of the miners in the United States was starting to do OFAC address filtering for transactions they were putting in their block templates. That seems like something that you would want to have at least a protocol that can route around.

Absolutely, 100%. But the thing is, it wasn't like we had this problem, and then Stratum V2 solved it. It's just already there's an incentive. If you pass on picking up the transaction fees, someone else will pick them up. And so I think it's another example of the problem having already solved itself, and that it's not that we need Stratum V2 to manipulate the pie graph and shard it into all these tiny little slices.

Which I actually think would be bad.

I don't know if anyone... yes? Great.

Thanks. I had a question. When you were talking about you have a soft fork and you have a hard fork on that slide.

So from the way you were talking, it sounded like the soft fork is somehow a lesser big deal or something than the hard fork, but I'm a bit confused because wouldn't they both cause chain splits? What's the difference here?

The up one is my proposal, which people have declined to accept or not even wrap their head around. So that's like the status quo today is the top. So it's kind of like I offer this for free, and it's like take it or leave it. So does that make sense? Whereas the lower one is different. The lower one is trains leaving the station.

You're not doing both of them, like activating both of them. They're just one proposal.

Yes, that's better. That's more clear. Yeah, they're kind of just like two, I guess, philosophies or something. So that's right. Yes.

Hey, Paul.

Yes.

So maybe there's a selection bias with the podcast that I listen to or so, but when I listen to interviews of you on eCash, I felt like you mostly talking about kind of the friction points with the crowd that is here, for example, and there's less information on the kind of different drive chains that you built.

So you mentioned a couple of times that there's a long list of drive chains and they enable all of these capabilities, but I never really heard or saw you actually like talk about them in detail and what it would enable.

So it felt like there's not so much like focus on the features in kind of your presentation of what you're doing, but more like focus on the potential stuff that will be controversial.

Well, that's an interesting thought. I would almost flip it around and say, like, it doesn't actually matter if there's this long list of really good stuff. It kind of doesn't matter if that's true or not, because if it actually is good, then obviously everyone would just adopt it.

So the actual story is about why are good things not being adopted, I think. So that's almost what I would think that has to be more relevant. You know what I mean?

Like, imagine if we tried to switch it to a different context and say, like, some corporation is doing something wrong and they're losing a bunch of money and another one wants to start a different company.

You know, like, I don't know what would be the most relatable example, like Amazon replacing Walmart or something. I'm not sure how to make this analogy work.

But the story would be more about, like, oh, the CEO is giving all the good jobs to, like, his cousin or his friends or something. Like, that's the real story is what went wrong before.

In my opinion, this is what went wrong. We have this bad culture in BTC, which, because we've been number one for so long, there's a culture of complacency and overconfidence, and it has just kind of settled into everyone kind of just it's becoming a bureaucratic.

So that's why I think that's more interesting, because, you know what I mean? Like, if I was right about all this stuff being much better, then it would just automatically, like, everyone would just take all these ideas.

So I think the real question is why, and it's not, I hate to make it all about myself, like, we can't even get something like Opcat, which is basically harmless and was in the original client and has all these people from

the Stark people all wanted it, and all these op-nop, op-success, op-cos are opt-in, reversible, and ignorable. So I think that's the bigger story is why is everything so deranged. Does that make sense, or no? I don't know.

I guess, like, an example would be, like, if people want, like, something like Namecoin or so, like, they have the need for this, they want this, then it would make sense for you to get these people on board that you talk more about something like, we have this Namecoin thing.

And, like, maybe it's fine for these people that you're stealing Satoshi's coins, like you say in the article there, but, like, since you, it feels to me like you're more talking about, in the front, about, like, stealing Satoshi's coins, and, like, it's more of an afterthought that this enables Namecoin.

Well, you know, I really don't think so, because I didn't think that this was actually a very relevant point, and actually I think it's quite a clever and ingenious idea, but that was, like, something that people got a lot, got a big reaction out of people, so that's kind of why I wrote the, I see it as mostly as me reacting to other people's, but I think if people actually download the software and whatever, they'll just see what it does for themselves, and so then I think that part will eventually take care of itself.

I'm not sure if, here's the thing, I've been talking about, you know, the idea of sidechains for even long before I had, even long before DriveChain existed, so even back when the Prediction Markets project was going, that I was interested in sidechains in this way of getting prediction markets on Bitcoin, so I've been talking about cool sidechains on Bitcoin for a long time.

And I don't think, you know, that got a certain distance, but now, and it's not just that we don't have sidechains, it's that we can't do anything right, I think, I don't think we do almost anything right in BTC.

I mean, right? I mean, who's, I don't know, I guess it's obviously an outrageous thing to say, but a lightning arc is always a waste of time, the treasury companies is always a waste of time, even, like, a lot of this stuff has become very academic, very convoluted, pretentious, nerd, this is all nerd sniping, you know, a lot of what people do.

Okay, here we go.

I have two questions.

One, I think, would be a follow-on to this comment.

If we're doing everything wrong, how can we do it better?

Competition is better.

More competition.

Oh, more competition being, like, from the merge mining stuff that you're proposing?

Things are just a little too much, like, a little too much 100% consensus kumbaya, we need, like, factions, and we need, like, one person to cheer and the other person to cry tears of sadness, we need, like, turnover, you know?

You know what I mean? Like, we haven't had a lot of, we need more, we need, like, something a little bit like that, where sidechains would help with that, because you have different L2s, you can escape the L1 onto an L2, but even if all the L2s suck, you can make a different L2.

So we have some competition, but, you know, it's hard with Bitcoin Core, because, so anyway, you were going to ask other things.

Oh, yeah.

So it sounds like you're championing the Coliseum, so to speak?

Yes, yes.

And then the second question was kind of just going back to your comment about Stratov2 stuff.

Sorry to keep digging into this.

But, like, see, one of the comments that you made is that you think that Stratov2 giving miners more choice about what goes into blocks isn't necessarily, like, a useful exercise.

Yeah, and possibly counterproductive.

And counterproductive.

Then maybe I don't have a great concept of how BIP300 with drivechains works, but isn't that giving more choice to miners?

To some extent, but only if it's pre-designated to them by the users.

And because of the way Bitcoin is already designed on L1, you have, like, to some extent, your transactions can already be reorg'd out of the blockchain.

So there's a certain amount of trust we all place in miners, even on L1.

And it's really, you can transpose it exactly into the L2, the drivechain withdrawal idea, because it's really a very similar thing.

It's like you're trusting them to pursue the most amount of money for themselves.

And if that's the case, they will process the withdrawals.

So, in this case, the alternative is almost nothing, because we don't have these other L2s that can do similar things.

And in the case of the Stratov2, the alternative is to just keep it with PPS, like we already have, which works just fine.

Because if the pool, the pool can't pay out any more money than it brings in.

So the pool already wants to fee-maximize.

So they're already fee-maximizing, then they pay out.

So that's why I think it's bizarre for Stratov2 to distract everyone by focusing on the job selection, which I think is a mistake.

And I don't even think it makes, you know, it doesn't even make any sense.

If the pool really disagreed with someone, the pool would win, because the pool could just ignore them.

So I don't even know, you know, it's a very strange thing.

Of course, if you talk to people, that's what they will talk about all the time.

They'll talk about how great it is that we've removed power from pools, and it returns control to the little guy.

So it may even be the case that people working on Stratov2 agree with me,

and that the whole thing is just a weird meme or something that has spread.

But I don't know.

But yeah, I don't think very highly of Stratov2.

Any other questions?

We have like two or so minutes, or if there are no questions.

Is that Thunder?

Sure.

It's basically, Thunder is just a BIP300 chain, but the performance has been optimized.

So we just, we tested it with, like, you can go online, you can go on GitHub and see the tests on GitHub.

And you just test it with larger and larger and larger blocks.

We have a big script that makes, like, tons and tons of transactions.

So it will just make a ton of transactions, and then attach, you know, connect all the blocks and time that.

And then we optimize that.

We did a hackathon last summer to see who could improve the performance the most.

And at the end, it became very optimized.

So it's, I have a, it's much easier to just understand how BIP300 works than Thunder specifically.

Because the way drive chain works is the, when you deposit coins from L1 to L2, that's the transaction on L1.

But then on L2, you can onboard new people there without touching L1.

Of course, you have to merge mine, the block.

But that is a constant number of bytes in the coinbase transaction.

So on L2, it's just how many transactions can the L2 process without collapsing.

And I have a, I have an article about this, which is about, if you go to, like, truthcoin.info slash blog slash thunder or something like that.

It's, I go through some of the math of this, where in the real world, many economies, you know, the world would be, like, partitioned into, like, you have, like, North America, Southeast Asia, Europe, continental Europe, and then, like, maybe, like, Africa and the rest of the world.

So you do have to split it about 14 ways.

So you have four, it would be, like, Thunder 1, Thunder 2, Thunder 3.

They wouldn't all come online at the same time, because you'd just have one, and you'd wait for it to fill up, and then it would kind of split, and it would be, like, West Hemisphere, East Hemisphere.

But it would kind of end up, so you can split it a little bit.

And the point of bringing up the regions of the world is that there are many splits that would really not interfere with the, what you might call the liquidity at that point, I suppose.

So you say, oh, I only have coins on the Europe one, because, so then you get a free partitioning into 14 pieces or so, and then from there, you just test, and it just has, like, giant, you know, has large and exponentially growing block size.

But there's a night and day difference between having large blocks on an optional L2 that everyone can ignore and having it on the mandatory L1, where everyone has the same data availability problem forever.

So there's a completely night and day, because this is often misunderstood as being just merely a large block project, which is absolutely not the case.

And in fact, the large block project has this exact same problem where Bitcoin SV and these other people have to, Bitcoin Cash had to wonder, like, okay, it shouldn't be one megabyte, but it should be, like, some other magic number.

And then they'll just hard fork again, and they, so that's obviously a huge downside.

And then for Bitcoin SV, it's kind of like it's just unlimited right off the bat, and then that has its own enormous problem, because you have this endless growing data availability problem.

So when you have competing different L2s, that's very good, because you can push the envelope on some of them, and maybe one or two will actually fail and die off, and that is actually healthy.

So, but yeah, if you had, the point is with the software that we have, if it was deployed the way I suggest, it's currently up to, like, 50% of 8 billion people using it every day, but the point is by the time it was realistically adopted, it would be up to 100%.

So you can check all that out on GitHub.

You can find, you can look up the hackathon last year, and a lot of very cool people entered to optimize the software.

Thank you.

Anyone else?

Okay.

No?

Okay, so thank you so much.

A huge applause for Paul.

Okay, welcome back from coffee break.

Our next guest is one of the most vocal proponents of BIP110, so please welcome Chris Guida.

Hey, guys.

Welcome to my talk, BIP110, How Bitcoin Wins.

My name is Chris Guida.

I am a Bitcoin medium of exchange researcher and BIP110 reviewer and cheerleader, and here's where we are and when we are.

Okay, so a little background on BIP110.

It was a proposal introduced by a developer named Dathan Om in October of 2025.

It is now a wildly popular UASF with about 15% of the network running it.

It's about to activate its first stage on August 8th in a couple of weeks, and the second stage will be later in September.

I've helped with reviewing, testing, and promoting it, and I'm extremely bullish on its activation, and that's why I'm here today to kind of explain to you guys why I'm excited.

Okay, so BIP110 is how Bitcoin wins.

So what does it mean for Bitcoin to win?

NGU?

ETFs?

Bank custody?

Government reserves?

Well, in my opinion, when Bitcoin wins, what that means is it's the end of the infinite money printer, also known as the separation of money and state.

People like to say the separation of money and state commonly in the Bitcoin community.

I think this is an admirable goal, but I think we need to be more specific about what we mean when we say that.

What it means is the global reserve asset can no longer be created at will by connected elites.

The problem is not that central bank money exists.

The problem is that central bank money exists, and it's the world reserve asset.

It's the thing that everybody has their savings in, so this is an especially pernicious form of central bank money.

Bitcoin wins when people voluntarily choose it over fiat.

Basically, we need to out-compete the dollar.

That's the goal, so that people choose to use Bitcoin instead of the dollar.

And it does this by maximizing along three axes.

Universal, decentralized, money.

Okay, so a little background on the infinite money printer.

It robs from the poor to feed the rich.

It causes a lot of systemic injustice, and most people understand that there's systemic injustice,

but a lot of people don't identify the source, and I think Bitcoiners are way ahead of the curve on this.

We understand that it's this infinite money printer.

How does this cause bad things to happen in the world?

It rewards bad behavior while punishing good behavior.

It finances war destruction and injustice.

It protects banks and corporations from the consequences of reckless behavior.

It causes all sorts of malinvestment.

It lets connected elites to create the global reserve asset at will.

So this is what we said before.

And humanity is really headed over a cliff unless we fix the money.

So just a little background on me, I got kind of excited about Bitcoin once I saw the failures

of some of these early attempts to, these were all right after the 2008 financial crisis.

Actually, Bitcoin sort of came out of the same financial crisis.

There's a famous thing in the Genesis block that says a chance are on the brink of bailout,

second bailout for banks.

So it points to Bitcoin's purpose and also does a proof of no pre-mine.

Anyway, so all of these other movements came out of that financial crisis, and I was really

excited about that and got caught up in that energy that sort of like, let's have a revolution

against Wall Street, against the big banks, against the money printer.

Everybody can see that the system is corrupt and the mask has really come off.

So we're going to win.

But what happened?

They depended on the goodwill of the fiat money system.

They depended on having a lot of funding.

And so when you depend on having a lot of funding and your opponent can print money,

you're at a disadvantage.

And so the money printer can fund institutions, hire their leaders, redirect their anger.

It can smear them in the media.

It can make them look like they have no purpose.

They have no principles.

I would read interviews of people from Occupy Wall Street, and they're like, what's your

movement about?

And they're like, we kind of don't know.

And it's just like, I'm sure if you really talked to the Occupy Wall Street people, they

would be like, yeah, we think this system is corrupt and we're trying to reform it.

But it didn't even need to do that.

All it needed to do is print money and buy it, basically.

So Bitcoin is different.

It does not ask the system to reform itself.

It creates an exit from the system.

It operates without permission from the elites.

It can finance the people and infrastructure replacing fiat because Bitcoin itself is money.

We are not reforming the system.

We are replacing it.

And so that's why I would consider Bitcoin a true revolution, and it will succeed where

these other movements failed.

And the UASF mechanism is Bitcoin's teeth.

In 2017, when Bitcoin 48 happened, I got really excited about Bitcoin because I was like,

Bitcoin actually can ward off attacks from the money printer in a decentralized way.

This is really cool.

A lot of sort of decentralized or anarchic systems struggle with collective defense.

And the UASF is how Bitcoin does collective defense without a central authority.

And this was successful.

And in my opinion, that's actually why Bitcoin went up a lot in price in 2017.

So, yeah, basically you have some developers propose it, businesses choose what to accept,

the users validate, it forms into a movement, and then it's really, really hard to stop.

These are the blocks that we will recognize as Bitcoin. Other blocks get rejected. And

it limits the danger even from a centralized mining industry. That's why it's still important

even today. And it shows that the nodes are in charge, not the miners. And this is just

an objective fact of the system of Bitcoin and how it works. And also, we really don't

want a centralized mining industry to be in control of Bitcoin's rules. That would be

really bad. And just a side note, filters and temporary UASFs are kind of like elements

of an immune system. And actually, I really like Brandon Quittam talking about how Bitcoin

is sort of like a mycelium, and it has a little bit of an immune system. And there's these

things called mushroom scientists, which are sort of like the filter or the UASF developers

who manufacture these novel molecules in response to novel attacks. And then the instructions

for how to build those molecules propagate throughout the network, and then the network

defends itself against a new attack. So mycelium operates chemically, and Bitcoin operates

with software. So it's pretty much the same mechanism.

Okay, so as we already said, Bitcoin must be preserved and improved in three ways. Universal

decentralized money. So Bitcoin has three sort of principles that define its identity.

We must preserve and improve universality. We must preserve and improve decentralization.

We must preserve and improve Bitcoin's monetary quality, or moneyness is another word that

people like to use for that. Anything that improves these qualities helps Bitcoin win.

Anything that harms one or more of them can be considered an attack on Bitcoin. And if

Bitcoin loses, humanity loses. So this is a very important subject, I think, I hope,

to most Bitcoiners. Bitcoin must work for every human being, not

just banks, governments, funds, and wealthy investors. Ordinary people must be able to

spend, earn, withdraw, self-custody, and verify. This is something that we have to continue

working towards because it's something that Bitcoin does not scale to a global user base

and remain decentralized as it is now. But with improvements in technology and Moore's

Law, we should expect this to happen in the next few decades, probably. But all we have

to do is keep our eye on the goal, right? We can't forget the goal. The goal is universality.

Custodial exposure and payment processing is not enough. These are choke points where

authorities can come in and take control of the system. And the old financial system must

not be rebuilt on top of Bitcoin. Otherwise, we've failed.

Bitcoin must remain decentralized. No developer group, miner, custodian, or government can

become Bitcoin's ruler. Influence is not authority. It's much harder to control hundreds of thousands

of small node runners and pleb merchants than to control a handful of large nodes.

Decentralization is what makes Bitcoin neutral. A lot of people say BIP110 is anti-neutrality

or something like that. And our response is no, it's pro-neutrality because we're trying

to make sure that Bitcoin stays decentralized. Decentralization is what makes Bitcoin neutral.

Bitcoin's particular consensus rules are actually not neutral. They are geared towards Bitcoin

being better money. Decentralization prevents the money printer from returning in another

form. And as we've just said, we want Bitcoin to be better money over time also.

Bitcoin has not yet out-competed the dollar. So we know that generally speaking, the U.S.

dollar is considered to be better money than Bitcoin. As Bitcoiners, we know that this

is not true, but the rest of the world does not believe us yet. So we have to continue

improving Bitcoin's moneyness. That's its unique purpose.

Universal decentralized money. It's not a good database, image host, token platform,

or permanent file server. Other systems can perform those functions better. Bitcoin's

consensus and policy rules should serve its monetary mission. This is what I was saying.

Bitcoin's rules are actually not neutral. The enforcement of the rules is neutral because

of Bitcoin's centralization. But the rules of Bitcoin themselves are not neutral. They're

pro-Bitcoin. They're pro-money. They're pro-decentralization. They help Bitcoin improve and fulfill its function.

Again, Bitcoin defeats fiat by becoming better money.

Bitcoin's principles should not be for sale. The only way we win is if these three principles

are not for sale. Not for short-term fees, speculative demand, institutional approval.

Not even for a much higher Bitcoin price. Of course we know if we succeed, eventually

in the long term, Bitcoin's price will be higher than it ever could be if we sell out

our principles. As I said earlier, NGU is great, but come for the NGU, stay for the

actual monetary revolution. As a thought experiment, imagine you're an infinite money printer,

you have an infinite money printer, and Bitcoin is coming after you and trying to out-compete

you. How much you try to stop Bitcoin from doing that, or to kill Bitcoin, or stop it

in its tracks. Well, you can print a bunch of money. You could print Bitcoin's entire

market cap. You could say, hey, Bitcoiners, I have $1 trillion, or $10 trillion. And I'll

give this to you if you make Bitcoin small and unscalable. So what would your response

be if somebody offered you $10 trillion to make Bitcoin small and unscalable? This guy.

This guy says no. Yeah, I agree with that guy. Yeah. No. We should say no. We should

not sell out our principles. We want Bitcoin to overtake the money printer and replace

it. If they offer us $1 trillion to make Bitcoin centralised, should we do that? No. If they

offer us $1 trillion to make Bitcoin something that isn't money, should we do that? No. Exactly.

If we compromise any one of these principles because someone offers us enough money, we

have sold out. We have sold out our principles, we have sold out Bitcoin, and we have sold

out the future of humanity. We must not sell out.

Bitcoin does not fix itself. Consensus rules do not interpret, enforce, or repair themselves.

Bitcoin survives because people understand its purpose. Its principles are not protected

by mathematics alone. They survive because node owners value them and enforce them. Culture

is therefore part of Bitcoin's security model.

So another thought experiment. Imagine there's an inflation bug in the software that somebody

accidentally introduces. Would we say that inflation is legitimate now because consensus

allows it? Would we call fixing the bug censorship? No. I think the answer to those questions

is obviously no. We would just fix it. We would consider it a bug and we would say let's

fix it. And if Core refused to fix it, node owners would route around Core with a UASF.

The rules exist because we enforce them. The $21 million limit is protected by node owners.

If the culture stops caring, the rules can decay with it. So again, if there's an inflation

bug and the culture says, oh, that looks fine, then what happens? The bug doesn't get fixed

and now Bitcoin has arbitrary inflation and now Bitcoin is terrible money. So again, culture

is part of the security model. We have to make sure that our cultural values are solid.

If the culture stops caring, the rules can decay with it. If Bitcoiners forget that Bitcoin

is money, inflation and double spends can eventually become acceptable. Bitcoin does

not protect itself. When Bitcoin breaks, it is up to us to fix it.

Many developers understandably treat Bitcoin as a profession. But for many node runners,

Bitcoin is a way of life. Running a node is closer to censorship than consuming a product.

For many of us, preserving Bitcoin is a duty to humanity. There's this notion that, oh,

you just run a node because you're selfishly running a node. And that's kind of true, but

that isn't everything there is in life. We want to feel like we're part of something

bigger than us. Bitcoin is not about us. Bitcoin is about, you know, our descendants and the

rest of the world and the future of humanity. We are providing a valuable service for humanity

by running a node and making Bitcoin function properly.

So how did core 30 threaten us? It changed what Bitcoin officially treats as legitimate.

It moved large file data storage toward normal supported use. Policy defaults send a cultural

signal which has a real effect on Bitcoin's actual purpose. Core developers may say otherwise,

but actions speak louder than words. There's three categories of transactions. There's

invalid transactions, there's valid but abusive or unsupported transactions, and there's valid

and legitimate or supported transaction types. Invalid just means the consensus rules say

your block is invalid if it includes a transaction like that. So you literally cannot include

that transaction in a block. Otherwise you're not participating in Bitcoin.

The second category is the domain of standardness or default policy. Satoshi deliberately left

category one very, very broad because if it's too narrow, then we have to hard fork to loosen

the rules and add more functionality. So he left it very broad, and then within that very,

very broad scope of consensus, he disabled pretty much everything. And that was his standard.

That became the standard rules. So that's category two is where relay policy works.

And that dictates what things are valid but we don't support, or we consider to be an

attack or an abuse. And then category three is just valid and legitimate or supported.

These are payments, right? Because Bitcoin is money, it's supposed to be used for payments.

So payments go in category three. Before core 30, data spam was valid but abusive. So it

was in category two. It was considered nonstandard. Core 30 reclassified it to valid and legitimate.

So it reclassified it from category two to category three. Core 30 says Bitcoin now officially

supports storage of large arbitrary files. There are two officially supported formats.

We're still quoting core 30 here. There are two officially supported formats, operaturns

of up to 100 kilobytes and inscriptions of up to 400 kilobytes. And there may be other

formats that are implicitly supported. So this is sort of the statement that core 30

as a software, as a piece of software was making. Again, core developers themselves

may have said, well, you know, we don't think that data storage is a legitimate usage of

Bitcoin or we don't think that data storage is recommended. But there's nothing we can

do about it. And so although their words said yes, their software, sorry, although their

words said no, their software said yes. And so the software of core 30 said yes to large

file data storage. And so as core 30 started becoming broadly adopted, this caused a redefinition

of Bitcoin from money into a database. Data storage would not remain a harmless side feature

or an abusive feature that is not supported and kind of difficult to get confirmed. It

would compete directly at an unfair advantage with Bitcoin's monetary use.

Bit 1.10 converts core 30's yes back into a no. So there's four different attacks that

data spam attacks, that data spam, four different vectors that data spam opens up against or

official support for data spam opens up against Bitcoin. The first one is this kind of ugly

topic that nobody likes to talk about. But just because something is ugly to talk about

doesn't mean that we should just ignore that the attack vector exists. That's not going

to make it go away. We have to actually make the attack vector go away. So we'll talk more

about that in a bit. UTXO set and blockchain bloat is attack number two. High fees are

attack number three. Cultural decay is attack number four. Each attack damages universality,

decentralization, or moneyness. This is the ugliest one. Sorry, again, that I have to

talk about this. But again, this is a real attack. We should consider this a serious

attack vector and do something about it. In the block size wars when the big blockers

would call us, oh, you're negative Nancys. You think that if we make the blocks bigger

then that's just going to run off a cliff. It's going to be a slippery slope. We think

you're worrying too much. And the small blockers said, no, we think adversarially. We try to

imagine if I had an infinite money printer, what are the ways that I could try to attack

or discredit or destroy Bitcoin. So we have to think about these things and do something

about them. So arbitrary storage allows attackers to place abhorrent or illegal material on

the chain. What this does is it discourages ordinary moral people from running nodes.

And the problem with this is that running nodes is already kind of hard. Barely anybody

runs nodes. Actually, raise your hand if you run a node. All right. So that's about

maybe a little more than half. Maybe about half the audience. And this is about as technical

of a crowd as you can get in Bitcoin. So that's a problem. We should make running nodes as

easy as possible. So oh, I just have a this is a tweet that Nick Sabo put out that I think

sort of encapsulates what the danger is. Having a feature that looks like it's intended

for nonfinancial content may be a much larger legal risk than having a feature intended

for financial transactions that is subverted to post nonfinancial content. It's not all

just bits in the eyes of the law. Caveat, I am not a lawyer. A feature that looks like

it's intended for nonfinancial content also sends a strong social signal that nonfinancial

content is welcome on Bitcoin. So this is what Core 30 does. And then here's an actual

lawyer saying Nick is, of course, right here. It goes to intent, which is the baseline consideration

for all crimes in the U.S. and many other jurisdictions. Storing or relaying financial

data, the intent of Bitcoin node runners is attacked by nonmonetary use cases, but currently

those are exploits or bugs. Exploits of bugs. Right? So you can argue that, you know, if

somebody, like, does some steganography and, like, hides an image in your computer, that

was done without your knowledge or consent. And so you didn't intend to do that. That's

what Ian is saying here. Core v30's efforts at changing the intent of Bitcoin through

intentional modifications to allow file storage arguably guts this no intent defense and puts

all Bitcoiners and node runners at much higher risk. So, again, we don't know how big of

a threat this is because there's lawyers that disagree about this. But, again, Bitcoin is

conservative. It doesn't just, like, arbitrarily impose new risks on itself and just kind of

hope to cross its fingers and hope for the best. Right? We don't want to leave these

things to chance. We want to actually fix these problems. Okay. Now that that ugly topic

is out of the way. Yeah. So this directly harms decentralization. Right? So that's one

of the core principles of Bitcoin. Bitcoin needs to be decentralized. As many people

need to run nodes as possible. This is a direct attack on that. UTXO set and chain

bloat. Basically the UTXO set increased from 4 gigabytes to 12 gigabytes during the spam

attacks, the ordinal attacks of 2023 and 2024. And this is another thing that hurts decentralization

because it slows down IBD. Bitcoin must survive for centuries and not just today. Hardware

improvements and Moore's law should make running nodes easier. And actually, Moore's

law is exponential and I don't think this has actually stopped yet. Although recently

the costs have gone up a lot. But I expect the exponential trend to continue. Spam attacks

could be orders of magnitude worse next time. So the UTXO set is actually limited by one

52 gigabytes per year of new UTXO set data. And the amount of new UTXO set data during

the spam attacks was I think it's like 1.5 gigabytes per year. No, it's like 3 gigabytes

per year or something like that. So the worst case is like more than ten times worse than

what actually happened. And what actually happened was really bad. So we should definitely

be thinking about this vector. And it should be noted that skipping validation, assume

UTXO or pruning are suboptimal and centralizing solutions. Those are not ideal. The ideal

solution, the low-hanging fruit solution is just filtering spam. Which is what we

did from 2010 until recent years. Okay. Another thing is high fees. Payments compete against

speculative data schemes. A payment user experiences the fee as a direct cost. A token issuer can

subsidize fees by selling speculation to new buyers. High fees cause a chilling effect

on real merchants selling real goods and services because of more expensive on-chain operations.

So we're looking for real L2, i.e. unilateral exit protocols like Lightning and ARK. And

I say unilateral exit because those are the L2s that I consider to be real L2s since they

are directly, you can withdraw without permission from an L2 to an L1. So the Bitcoin in a unilateral

exit layer 2 can be considered Bitcoin as such. Whereas these other L2s that require

trust I don't think should really be considered L2s. That's another controversial opinion,

I guess. But anyway, Lightning and ARK, we should try to make these things way better

because they make the pleb merchant experience much better. And they make Bitcoin a lot more

decentralized and better money. And high fees, of course, push users towards custodians and

we don't want that. That's also centralizing. So high fees impact all three principles but

especially money. And the last attack is this cultural decay. Basically Core30 teaches

Bitcoiners that arbitrary storage is legitimate. Anything paying a fee is legitimate. All valid

transactions are equal. These ideas erase the distinction between monetary use and abuse.

Once the culture forgets Bitcoin's purpose, future attacks become easier. So again, just

to kind of round this out, we have to remember that Bitcoin is money. And we have to remember

that Bitcoin needs to out-compete the dollar as money. And we need to remember that because

Bitcoin hasn't done this yet and is actually very far away from doing this yet, that our

work is very far from complete. We have to continue making Bitcoin better and better

and better money. If we just give up now and say it doesn't matter whether Bitcoin is money,

then Bitcoin dies. So we should not do that. And the four attacks kind of reinforce each

other in this sort of synergistic insidious way where it drives away NodeRunners, raises

validation costs, pushes users into custody, and teaches everyone to accept the result.

And the outcome is that all three principles, universal, decentralized, money, those are

all injured by officially sanctioning spam. So what does BIP110 do? It surgically targets

formats that make arbitrary storage look officially supported. So anything that could

possibly be argued that this format is an officially supported way of storing arbitrary

data on Bitcoin, it limits those as much as possible. BIP110 is airtight against the first

attack that I mentioned, the CSAM attack. It vastly diminishes the attack surface of

the other three attacks. And it does this by restricting all methods of arbitrary data

storage as small as possible. So it restricts the two main arbitrary data storage methods

that were legitimized by core 30, which are large operatrons and inscriptions. It also

restricts all methods of storing files of more than 256 arbitrary bytes in a single

contiguous data field. This is to limit image storage specifically because it's hard to

store an image in smaller than that. Most of the restrictions are formats already nonstandard

just last year. So these are basically policy rules and, like, converting the policy rules

into consensus rules. The exceptions to that are the OPIF and TAP script rule, the 34-byte

limit on script pubkeys and the 256-byte limit on data pushes. It disables all these formats

for one year and it grandfathers existing outputs. Oh, let's actually look at spec.

So just really quick, there's seven rules. So script pubkeys are limited to 34 bytes.

Data pushes are limited to 256 bytes. Undefined witness versions are invalid. TAP root annexes

are invalid. Control blocks, larger than 256 bytes, which is, sorry, 257 bytes, which allows

you to have depth of seven. So depth of eight or larger is invalid. And op success is invalid.

This is an upgrade hook. And OPIF and NOTIF are invalid. And as we already said, UTXOs

are grandfathered. What it doesn't do, it does not try to read people's minds and see

what their intent is. It does not claim that hidden data can be made mathematically impossible.

It does not stop all spam. This is a shockingly, surprisingly popular misconception or strawman

about VIP 110. It doesn't try to make spam impossible. Of course, it doesn't. I mean,

so of course, as a Bitcoin protocol developer, you want there to be some kind of permanent

change that you can just make that makes data spam impossible. But of course, with

data spam, that's not possible. With something like inflation, like an inflation bug, that's

something that's much more sort of directly addressable in the rules of consensus. But

with data spam, yeah, you can't know how people are intending to use something. And the more

you restrict it, the more they're going to hide it. But it does turn out that the more

hidden data spam is, the less harmful it is. So it makes sense that we should try to limit

the most obvious forms of data spam and the most popular forms of data spam. It does not

censor or limit neutrality. I hope it should be obvious why it doesn't do these things.

As I said, Bitcoin is decentralized and it uses proof-of-work mining, so censorship is

not possible and this actually increases Bitcoin's censorship resistance by allowing everybody

to run a node and increases Bitcoin's neutrality by allowing everybody to run a node. It draws

a practical line around scalable, explicit, arbitrary data publication. So, you know,

if something is, there's a few different, like, people are like, what is spam? And it's

like, okay, well, you know, just because you can't draw a clear line between which things

are spam and which things are not spam doesn't mean that the categories of spam and not spam

don't exist. There are things that are definitely spam, like BRC20, and there are things that

are definitely not spam, like pay-to-copy-hash or something. Or going to a, yeah, making

a payment at a shop.

It removes the guarantee, so BIP110 removes the guarantee that Bitcoin will preserve storage

schemes, thus making arbitrary data storage unreliable on Bitcoin, making other file storage

schemes comparatively much more reliable. And so we don't need to make data storage

impossible on Bitcoin. We just need to make it less favorable on Bitcoin economically

than it would be to use Ethereum or Nostr or BitTorrent or something else to store the

files. And again, we've done this. In 2014, there was a war against the spammers and Bitcoiners

committed to escalating until the spammers went away, and that's what happened. They

went away. And Vitalik was like, all right, I'm just going to make Ethereum on a different

chain. And in retrospect, that's actually the good outcome. So we should be going for

that.

Payments receive guarantees because Bitcoin is money. Arbitrary files do not. BIP110 does

not block covenants or do anything to inhibit LN symmetry. This is a very confusing strawman

or misconception about BIP110 that I've seen recently. I have no idea where this came from.

Actually, there are many BIP110 proponents that are in favor of adding covenants once BIP110 expires. So that would be perfectly acceptable, in my opinion.

So BIP110 sends a clear signal. Arbitrary data storage is abusive. Bitcoin does not officially support permanent file storage. Storage formats may be broken at any time. Data projects cannot depend on Bitcoin as stable infrastructure. Bitcoin's consensus exists primarily for money.

Fees are not enough. They just put a price on spam. Spammers may happily pay when speculators subsidize them. A fee market tells them how much the next block costs. It does not tell them to leave.

Money fees can become a marketing expense. Or could help with marketing. Fees are not an actual deterrent. There's a lot of developers that say monetary transactions will outprice spam transactions. I don't see that happening.

If you look at Bitcoin's history, what it looks like to me is that when Bitcoiners' hostility towards the spammers maximizes, the spam minimizes. That's actually what you're seeing right now with the movement of BIP110. Because there's a lot of angry node runners that are saying, go away spammers, the spammers have gone away.

I don't know if you've seen, but the fees are really low now. There's still spam here and there, but it's not a DDoS on the network and preventing people from using Bitcoin as money like it was in 2023 and 2024. Cultural hostility is stronger than fees. Bitcoiners must commit to escalating until the spammers leave. This is what worked in 2014. Storage projects need dependable formats. BIP110 tells them those formats will never be dependable.

The goal is not just to make spam expensive. The goal is to make clear that Bitcoiners will never accept it as legitimate. Or said another way, we don't want to make spam expensive, we want to make spam unreliable. The reason why they like spamming Bitcoin is because Bitcoin is forever. So if we just say this isn't forever, then that breaks the guarantee and that breaks the incentive for them to use it.

BIP110 is not a petition. It's not a request for permission from core or miners. It's a commitment by node runners. These are the blocks we will recognize as Bitcoin. The rules gain force when users actually run the software.

There's no leader who can sell the network. There's no headquarters to close. There's no institution that can surrender on everyone's behalf. The money printer can buy companies, politicians, media, and developers, but they can't force you to run any particular software. And so they can't force you to accept a block that you choose to reject.

Why BIP110 will activate. BIP110 uses the same basic mechanism as BIP148, which successfully activated in 2017. Software incentives push miners towards the stricter chain. Legacy miners risk producing blocks that may later be wiped out. And miners are risk averse. They don't want to be working on a chain longer and longer and longer and then suddenly all of that whole chain and all of their earnings get wiped out.

So signaling protects the value of Bitcoin and avoids unnecessary chaos and also avoids miners getting their earnings wiped out. So there's very, very strong incentives on the miners to resolve to a single chain very, very fast. And this is why it's very unlikely that there will even be a chain split. That would be basically an attack by the miners.

Ignoring is not a defense. Even limited hash power on the stricter chain creates continuing risk for miners on the legacy chain. I already said this, but it's worth repeating. The longer it gets, the greater the risk for the miners. Ignoring the UASF does not make the stricter chain disappear. This is another thing that's important to point out, is the shorter chain does not actually have wipeout risk. As long as the nodes that are running the UASF say, this is the real Bitcoin, then it's not a risk.

Then that chain continues indefinitely. So it never gets wiped out by the other chain. So the risk is very asymmetric. All of the incentives point towards converging on the stricter chain. An actual defense would require an explicit URASF. And since there is no good reason to reject Bitcoin.10's temporary restrictions, there is no reason for anybody to make or support or run a URASF.

For some developers, this looks like a relay policy argument. But for node runners, it's a defense of Bitcoin's purpose. Bitcoin is systemically important for humanity. Its survival is more important than short-term convenience or profit. That commitment is why the UASF has force. We're in this with our lives. This is our life mission. Running a node and being a member of this and making this thing work. We really, really care.

And the people on the other side don't seem to care as much. Most of them are sort of speculators and they see Bitcoin as like BTC. They see it as like this ticker that they can invest in. But there's all these other tickers of other cryptos that they can invest into. And, you know, it's like we're all in on this thing. We need it to work. And the other side doesn't. So it doesn't make sense that the other side would win.

We just care more and we're more correct. For some developers, let's see, what did I say? Yeah. So Core 30 gave the money printer an opening. Short-term fees, speculative demand, institutional approval, the promise of a higher price. All in exchange for redefining Bitcoin as something other than money.

Bitcoin's purpose is not for sale. Node runners will not accept every attack because someone pays a fee. The dominant implementation does not control Bitcoin. Users have the right and responsibility to correct attacks. Bitcoin remains universal, decentralized, and money.

The money printer's greatest weapon is its ability to purchase opposition. Our greatest weapon is the ability to say no. No to cultural surrender. No to unnecessary centralization. No to turning Bitcoin into a permanent file server. No to anyone who thinks enough money can purchase Bitcoin's principles.

Bip 110 protects Bitcoin's mission. Bip 110 proves that users remain sovereign. Not miners, not developers, not corporations, not governments. Bitcoin must remain universal, decentralized, universal, decentralized money. Bip 110 is how Bitcoin wins. It is currently our best weapon against the money printer's influence over Bitcoin.

Let's use it.

Thank you.

Do we have any questions from the audience?

I have eight minutes left.

Or if there's no questions, then...

Hello. Hey. I'm to your left.

Oh, Alex.

Can you explain the temporary nature of the soft fork? This is the first time I've seen a change or a fork that was temporary.

Yeah, so there actually is precedent for a temporary soft fork. There was one in 2013 to limit block sizes to 500 kilobytes. And it was when there was that problem between 0.7 and 0.8 where they changed the database format and the old version was limited to 500 kilobytes. So they just soft forked temporarily to give everybody enough time to switch over to the new version.

So there is precedent. Specifically in Bip 110, it's ideal for what Bip 110 is trying to do. It's trying to make a strong statement of rejection of data storage. We don't need permanent changes to the consensus rules in order to set a precedent in the culture. In order to send a signal that we are going to keep escalating to protect Bitcoin.

What makes you think the spammers will stay away when the rules change back to allow spam again?

Number one, I don't expect the rules to stay exactly the same. I expect the community to converge around some kind of more permanent solution for this.

The reason why I expect spammers to go away is because if we make a strong statement that data storage is not allowed, then what that does is it basically requires or incentivizes popular node implementations to implement data filters and filter spam at the policy level, which is where data spam should be countered.

The point of Bip 110 is not to filter out all the spam or prevent all the spam. It's just to make a strong statement of the nodes must be respected. The nodes are in charge. This is increasing our costs and increasing our centralization.

It's the node runner's job to enforce the consensus rules, but it's really popular node implementations' job to enforce policy rules. Core 30 has been falling down on that responsibility.

What the hope is is that in order to avoid another situation where data spam becomes a standard again, in order to nip that in the bud, Core and other popular node implementations will simply decide to filter spam, which is what they always did.

They always filtered spam from 2010, starting with Satoshi, until 2022 or 2023 when Ordinal started coming out is when they stopped doing their job.

Thank you.

Anyone else?

Thanks for the talk. I'm just kind of curious. What exactly is stopping someone from, let's just say, spinning up a whole bunch of machines last minute, trying to influence the voting and stuff, or the signaling?

Because it's not exactly the miners, you're not putting in the hashing power and whatnot, it's just nodes. So what exactly is stopping people from just spinning up these nodes like that?

Well, I mean, we might be seeing that, right? There could be fake BIP-110 nodes, there could be fake Core nodes. I'm sure there are some sort of Spurious or Sybil nodes on both sides. I would be very surprised if there weren't any.

But it does seem like the growth of at least the BIP-110 nodes, it looks like it's at organic levels now, based on the growth pattern that we've seen since the activation client was released several months ago.

There were some spikes where there were obvious spoofing, but those have resolved now. Those nodes were shut down.

We have other heuristics, right? If a bunch of nodes get spun up and nobody claims responsibility for them, that looks kind of suspect.

But if a bunch of nodes get spun up and a bunch of people, like actual real-life human beings that I've met in real life, are saying, yeah, I'm running a BIP-110 node, that's a pretty strong heuristic that this is actually popular within the community.

I did actually compile a list of businesses that are running BIP-110, and so there is a significant amount of economic weight behind the soft work as well.

The way I would answer it is, our side has conviction, and we know that we're right.

Objectively speaking, if you look at the arguments against BIP-110, they're just kind of frivolous and unserious, in my opinion.

Let's be clear, I guess there are some objections that are serious, but mostly are due to misunderstandings or misinterpretations of what the BIP is actually doing.

This is the age-old question, how do you measure consensus? We kind of don't really know, but what we do know is that BIP-148 worked.

And BIP-148 was like 500 nodes. So if BIP-148 can work, BIP-110 can definitely work. It has like 15,000 nodes.

I guess, you seem very confident, and I find it a little bit concerning, because basically all of the proposals I've seen in the past and gone into,

that I've interacted with, are full of trade-offs and reasonable disagreements, but people find consensus on those things anyway.

You say you're right, and your side has more conviction, but how do you know that you're so right, I guess, is my question.

I don't really know how to phrase what my concern is.

I mean, just thinking about the arguments objectively, the argument tends to be that. It tends to be, well, why this? Why not some other set of consensus rules?

Or how are you sure that miners are going to listen to you? Or how are you sure that other people are going to listen to you?

And it's kind of like, well, that's not how Bitcoin should work. The side that has the best arguments, those arguments should be evaluated in public, in the open.

And if those arguments are not defeated, then the movement will not stop. I think the only way to stop the movement is to actually defeat it with good arguments.

And that's how it should work, right? Bitcoin is a big truth machine. It's constantly evaluating different claims, and every Bitcoiner is responsible for evaluating those claims independently.

That's what's beautiful about it.

Hey, so in your presentation, you noted that it, correctly, that it is impossible to fully prevent all spam.

And from your answers to the other questions, it sounds like the intent behind BIP110 is more so as a political statement of hostility towards a specific vector of attack.

Right. With BIP110, node runners are saying, we do not accept arbitrary data storage as an official use case. We consider attempts to store arbitrary data on our nodes abusive.

So this would be a technical change to Bitcoin motivated by sociological ideation rather than based on technical merit.

Now, do you have any evidence on the sociological...

Well, it also has technical merit because the technical changes support the motivation in the strongest possible way.

In order to make that argument, you would need to prove that the technical changes would have the sociological outcome that you claim to. Can you back that up with any evidence?

That the technical changes have the sociological...

You're claiming that this change will disincentivize people from using Bitcoin for spam. Can you claim why that would be true?

I mean, because it's a clear statement of hostility against spam. And there's a historical precedent for if we show clear hostility against spammers, the spammers leave and go to other chains.

Can you back that up with any evidence? Because the reason you wrote the document is because of the...

Sorry, I can't really hear you.

I just have to push back on that because that's just objectively not true. Actually, what blew Ordinals up was all of Luke's criticism. It enlivened the Ordinals movement.

It's what made people care was the fact that it was controversial and click-baity and engagement-y. No one gave a shit about Ordinals until Luke Dash started...

No, so the reason why Ordinals blew up is because Core refused to filter it. If Core had just come in and been like, this is spam...

That's just historically completely inaccurate. Core didn't have anything to do with Ordinals when Ordinals was blowing up.

It's not historically inaccurate to say something that didn't happen didn't happen because it didn't happen.

I think it's very objectively factual that Ordinals was a market that was completely running up. There was a huge Ordinals bull market and Core wasn't even paying attention.

No, when Ordinals was first announced, Core could have come out with the inscription filter that Luke ended up eventually writing.

They could have come out with that filter right away because it was their job to filter new token spam.

I won't argue, but I will point out this idea that Ordinals only matters and became relevant because BIP-110 adjacent crews were the opposite.

The BIP-110 people is the reason why Ordinals died is just absurd. There's no evidence for that whatsoever.

It is demonstrably true. That is what happened.

It is not demonstrably true. Ordinals died when BIP-110 started going down.

We culturally rejected the shit-coiners.

There's no evidence for that.

The shit-coiners tried to insert themselves into our conferences, onto our platforms, onto our stages, take over our meetups, and we pushed them out.

We said, no, we don't accept this. That's why it died because we rejected them.

Ordinals are literally getting more attention right now in Mindshare because of BIP-110 right now, this month even.

Leonidas and Udi are crushing right now because of this conversation.

If we just let them take over, then it's not like the shit-coins would just go away.

There's a whole long tail of other crypto projects that are basically immortal. They never die.

We have a knob, which is the amount of hostility.

We turn it all the way to the right, that's maximally hostile.

We turn it all the way to the left, that's maximally friendly.

Core turned it all the way to the left.

They were like, we're going to just give them all sorts of places to spam.

That sent a signal of cultural friendliness towards spam.

That's what increases spam.

Then BIP-110 happened, and that turned it back to the right.

Just for clarity.

If you look at the incidence of spam versus those time periods, it exactly correlates.

Core specifically expanded the limit to enable a BitVM use case.

Do you consider that also spam?

Because that is why Core did not.

No, that rationale was bullshit.

You think Core just said that, but they were just full of shit?

Yes.

They actually just wanted the JPEGs to move from the witness into the operator.

I don't know what the real reason was, but I do know that the explanation they gave was not sufficient.

They basically said, we're worried that there's going to be 64 bytes of UTXO set bloat that may or may not happen,

because this Citria fraud-proof transaction, which is never expected to happen,

might produce 64 bytes of UTXO set bloat.

Do you not believe them that they didn't want people using private mempools?

Let me finish.

Meanwhile, Ordinals caused 8 gigabytes of UTXO set bloat,

and the reason why that happened is because they didn't filter it.

Core's decision had nothing to do with instruction.

They're saying, we're so worried about UTXO set bloat,

so we're going to prevent 64 bytes of spam that will never happen,

but we're going to pretend the 8 gigabytes of UTXO set bloat just didn't happen or didn't matter.

To this day, if you talk to Core devs and you say,

my Raspberry Pi doesn't sync anymore because of all the spam that happened and all the UTXO set bloat that happened,

they'll just laugh you out of the room.

They're just like, ha ha ha, this guy's an idiot.

I've talked to dozens of people that have this exact experience.

It's just like the conspiracy theory levels around the Core thing are really...

It's not a conspiracy.

No, no, you're saying that they're lying about their stated reasons

when they gave very strong technical reasons in support of the security of the network for why they made this decision.

Their technical reasons were bullshit.

Do you think the reason that they didn't want people using private mempools

to execute Layer 2 transactions is bullshit?

Because that's actually something that does matter for decentralization.

Those things only happen when the spammers are invited in.

If we show cultural hostility against the spammers,

then they go away and private mempools aren't an issue.

I encourage you guys to take up the conversation later.

We've got one more question and we are out of time.

Very brief.

Quick question.

You mentioned that, of course, it's not possible to get rid of all spam

and that the goal here is to create hostility towards spammers.

Why BIP-110 as opposed to a code comment or something that signals hostility?

Because BIP-110 mitigates the CSAM vector.

No comment would do that.

Secondly, a consensus change is a consensus change.

Every consensus change is a cultural moment for Bitcoin.

It sets a precedent that affects Bitcoin's culture moving forward.

The block size war was a culturally defining moment for Bitcoin.

BIP-110 is a similar moment.

Could we soft fork with a comment that you have to send to a node

in order to connect to them or put in a block header?

I don't think that would work.

When we say we're willing to escalate until the spammers go away,

we're willing to use technical means to do so.

There's way tighter restrictions that we could make on the consensus rules

that BIP-110 doesn't do.

For instance, script whitelists.

If somehow the spammers decide to come back,

or there's another thing called P2SH2,

where you have to prove that every piece of data in your transaction

is actually something financial or monetary.

It's like a key or a hash or something like that.

There's other technical means that are much more restrictive

and much stronger that we could do if Core continues to fail

at filtering data spam after BIP-110 activates.

Just somebody writing a comment somewhere is not authoritative.

Thank you, Chris.

Thanks, guys.

BIP-110.

I guess I'm monitoring this.

I'm not sure exactly...

I can sort of see a theme here.

Maybe, given your talk, there's a little bit of a similarity

in that you're not...

Are you...

Look at the hat.

He's the devil's advocate.

I thought it was inflation for it,

because you're not really pitching that.

He's like the null hypothesis.

Everyone has to fight.

He's the gatekeeper.

I guess I'm here to try to keep it civil.

I don't know if that'll work.

But I'm not pitching any...

I guess technically...

U3XO is cleverly not a fork.

Not a fork.

I guess the talk I gave was stuff that would be a soft fork,

but I'm sort of advocating...

BIP-54 helps with U3XO, right?

Does BIP-54 help with U3XO?

The BIP-30 stuff, yeah.

The BIP-30, yeah.

We've got decades before.

That would be nice.

I guess first we'll just each...

I'm Taj.

I'm not advocating for a consensus change.

We can each go around and say our names

and what the consensus change we're pushing for, I guess.

Hi, my name is Chris Guida,

and I am a tester and reviewer and cheerleader for BIP-110.

Yes, I'm Paul Sztorc. I propose the soft forks, BIP-300 and 301,

and I propose a hard fork for Bitcoin at the end of next month.

Go to eCash, eCash.com.

I'm Peter Todd. I, in this conference, propose that someone else in the future

propose tail emission demurrage. I don't want to do the work myself.

And I've also got a proposed op expiry, which fortunately another guy here in the audience

wants to propose another version of it that might work, too, so he can do the work for me, too.

This is great. I can just sit here and talk on panels.

Okay, I want to do... Did someone already do the show of hands for 110 support,

like four against indifferent or just deciding? You know what I mean?

Did someone do that at some point? Because wouldn't that be helpful for the 110

to just see what is in the room for...

BIP-110. Let's do BIP-110.

110. More panels.

Okay, so if you're in favor of 110, is that what that was going to be?

Let's do indifferent first. If you're indifferent or you haven't decided yet on 110.

Raise your hand if you're indifferent.

We have one... We have two people, right? Maybe?

Okay, what about... Oh, we have three people. Okay, great.

What about if you're in favor of 110?

Favor of 110.

We got two maybe trolling.

And we have maybe five, but maybe two of them are trolling. I don't know.

Okay, now if you're against 110, raise your hand.

It happened to me.

But are you doing a URSF? Who's URSF-ing BIP-110?

None of you are opposed.

So if we did that, we have to also do that with BIP-300.

That's true. We go on and on.

I wasn't trying to smuggle that in. I was just trying to...

Although I'm curious about it now that you asked, but I wasn't trying to smuggle it in.

I guess not going to run BIP-300 or against BIP-300.

Well, okay, I put out BIP-300 and it's kind of like...

Without enthusiastic support from users and miners, it wouldn't work anyway.

So it's not... It hinges on a little bit more than just maybe what 110 does.

Hence the desire to demonstrate it with its own thing, I think.

So maybe we could talk about that a little.

So you proposed BIP-110 a while ago, right?

BIP-300 is a little... BIP-300 is years old.

It got the BIP number in maybe 2018, I think. February 2018.

And BIP-110 is fairly recent, right?

And we should also point out for the audience that BIP-300 is a complete redesign of all the incentives in the Bitcoin system.

And it's a massive change. And BIP-110 is a tiny, surgical, totally common sense...

Well, I don't agree with that.

You just take an unused opcode and use it to count to 13,000, basically.

That's all it does under the hood.

And as far as the miners, it asks them to basically accept more money for merge mining,

which is something that we've had since Namecoin in 2010, 2011.

I am much closer to agreeing with Chris on this, just for the record.

But I think we probably shouldn't talk too much about the details of what the forks are,

even though I know people want to, because we did sort of just have...

You talked, and then you talked, and now we're all...

So I think most of the people here are at least somewhat familiar from the talks.

But I think the difference is, yeah, you're sort of saying, I'm going to do a hard fork, right?

I think it's actually the polite thing to do under the circumstances.

It's sort of like people are not... They're not lapping it up, basically.

But it did take so six or eight years.

So for eight years, could you say just a little of like,

okay, so for eight years, were you sort of hoping it would be a soft fork

and trying to pitch it in the same way?

Well, I was very open-minded to like...

I actually proposed the idea in form of writing in 2015.

So it's super old.

And I was just kind of shrugged like, whatever, maybe we won't need this.

Over the last ten years, what's really happened is I've seen how terrible everyone else's...

You know, how lightning has not worked,

and it seems like actually everyone has no idea what they're doing.

So my idea kind of stayed the same, and then all these other ideas collapsed.

And I thought, well, actually, my idea is actually the best idea.

And it's very, very misunderstood.

There are basic things about it that are easy to understand

that people have trouble grasping.

So I kind of just thought everything would be fine.

You know, the price of Bitcoin has gone up a huge amount.

So overall, there's been a lot of success for Bitcoin.

But I think I worry about how do we go up from here,

both in terms of adoption and in terms of price.

You got multiple people fighting, chasing the customers away at the front door

where people are saying like, you know, we got the treasury companies,

we got 110, we got people saying, oh, it's not a good thing to use Bitcoin.

So we got all kinds of weird stuff like that.

Okay, so in this case, the 300, you have a hard fork,

there's a difficulty adjustment, there's all this stuff,

it's going to run, and you're going to have a sustained chain.

With the BIP-110...

Something will happen.

Yeah, there's no, at least from my understanding,

there's no plan for a hard fork or difficulty adjustment at this time.

Is that something people have talked about in BIP-110 at all?

I mean, people always say like, what happens if the miners ignore it?

And it's like, well, they're not going to ignore it.

That would be an attack on Bitcoin.

It would be an attack on the node network.

There are other things we could do.

So what if they do, and then the response is they won't,

isn't really a response, right?

Right, exactly.

I mean, if the entire mining industry is malicious,

we have to have some kind of stronger escalation to that.

The next move would be a proof-of-work change.

Would you call the majority of the people in this room malicious?

It's a little tricky when they're in the room with you, right?

Because you only have three votes, really, four, right?

Well, I mean, but the people in this room are not running mining pools.

I mean, maybe there's a couple of people running mining pools.

Yeah, I mean, you know.

We have a marathon over there.

But yeah, I mean, well...

I wouldn't say they're not malicious.

Do you acknowledge that you might be in a minority position here?

Or are you like, no, of course we're the majority.

There's no way we could be a minority.

But again, so VIP-148 had a minority position, too.

And it still forced the activation of SegWit,

and it still forced its own activation.

Some people will say, oh, well, VIP-91 made it do that,

but it was compliant with VIP-148,

and obviously that wouldn't have happened if VIP-148 hadn't happened.

So I agree it's hard.

It is a hard question.

How do you measure consensus?

With the SegWit, though, it was sort of a basic...

As far as I know, every developer working on Bitcoin Core

was like, yes, SegWit.

And much more than just developers.

You know, in an equivalent conference like this,

you would have had essentially everyone saying SegWit's a great thing.

Although there were some people, like I remember...

There were some.

I remember in Hong Kong, Sipa gave the talk.

Right, Core was on the good guy's side in the block size war,

and they're on the bad guy's side this time.

So, you know, we have to work with what we've got.

I don't think we should do good-bad,

but I do remember in Hong Kong,

Sipa gave the sort of mic drop talk

of how you could do SegWit as a software.

Everyone was clapping.

I remember sitting next to...

I was standing next to Joseph Hoon,

and he was like, oh, great.

And I was like, oh, no, look.

Look at Roger Ver over there.

Like, there were people who were not happy about that.

And I sort of feel like that's when

the sort of Bitcoin Cash stuff started.

But anyway.

But it is a hard thing to measure,

but it does seem that like...

I don't want to say objectively,

but it's like if you're going to run VIP-110,

it seems like you should plan ahead of like,

okay, what do we do if it is minority hash rate?

I mean, basically, yeah, it's like,

what do we do if actually the nodes

are not in charge of Bitcoin

and the miners are actually in charge?

It's kind of like, okay, well,

what do we do if Bitcoin is dead?

You're saying that you even said

that it was like wildly popular

and had 17% right now?

Yeah, 15% to 17% is the sort of...

But that's a minority, right?

So what do you mean the miners are in charge?

That's the people who are like

rabidly in favor of it,

or maybe not rabidly,

but like, you know,

enthusiastically in favor of it, right?

We don't need...

In order to change Bitcoin's consensus rules,

we don't need everyone to be enthusiastically

in favor of the consensus rules.

We just need a vocal minority

that's really in favor of it

and nobody that's willing to do a URSF,

which is how it works today.

What if you're in a position where it is true

that the majority of users

actually disagree with you?

What then?

They have to run a URSF or it doesn't matter.

But isn't that actually not true

because of the mandatory signaling?

What?

Isn't that actually not true?

If they just don't signal,

then they will automatically URSF?

No, because there's very, very

crushingly huge incentives

to not do that,

because that's the legacy chain

and it has wipeout risk.

It might get wiped out.

Look, you believe that,

but if we wind up in a month

and there's 1% hash power

mining the Bitcoin 10 chain

and I think this is true,

the majority of Bitcoin nodes

and Bitcoin users

are going to say,

well, we don't agree with the Bitcoin 10 chain either.

Then what do you do?

Another way to put it...

Again, the incentives are for the miners

to just converge on one chain.

The miners need Bitcoin to be one thing.

If Bitcoin is two things,

the miners can't sell their coins

and pay for their electricity.

If you're in a minority,

that's bad for you

because they're going to want to converge

to one thing,

which would be the non-Bitcoin 10 chain.

It doesn't matter though

because even a minority chain

can catch up and win.

If there's a non-zero chance

that the minority chain will catch up and win,

then the miners have a strong incentive

to switch to the stricter chain.

What if there was a minority

of very vocal, zealous people

who said,

we need KYC in Bitcoin

and said,

we're only 5% of the nodes,

but we need this...

Then there would be a URSF.

It needs to be...

A URSF.

What if it's 1%?

I'm running a node.

I don't even pay attention.

If you think that change

is going to be harmful for Bitcoin,

you have to do a URSF.

So any minority,

no matter how small,

commands my attention

to do something about it?

Or can I just ignore it?

How small does it have to be

before I can ignore it?

Any minority that's at least as big

as BIP-148

demands your attention

because BIP-148 was successful.

I know,

but didn't we discuss

there was the SegWit2x...

There was a table

with people's opinions in SegWit.

And then SegWit had another quality

where other than the 4MB block size increase,

if you put that aside

so that we don't trip over that,

but other than that,

it basically just was like

a Pareto improvement

where it just said

you can do everything

you were doing before

plus you have this new option.

So it would be kind of bizarre

to go down the road

of opposing something like that

because you're just saying,

oh, we're just giving someone

another option for their transaction.

So these were things that SegWit had.

But you're saying

restricting is the difference?

Is a meaningful difference

versus expanding?

When you do the software

to add a new opcode,

you actually are adding something.

You're adding functionality.

So like, oh,

check lock time verify,

like Peter did.

It theoretically invalidates,

it theoretically shrinks some things,

but it actually,

since it takes the unused op-nop too,

I think.

It would be a weird progression

of like SegWit was a big change.

Tons of people liked it.

Companies built on it.

And then Taproot,

people were talking today

about Arc and all these Taproot things.

And then, you know,

and it takes forever, right?

It's like SegWit 2016

and then Taproot 2021.

And then the next one is BIP 110,

which is like, well,

it's kind of,

it's pretty different, right?

Like it doesn't enable as much.

Yeah, it's different

because it's the first time

in a long time

that we've done

a sort of defensive soft fork

that is basically rectifying

some unintended consequences

from previous soft forks,

namely SegWit and Taproot.

There have been forks like this

in the past, right?

There was a soft fork to eliminate the,

there was an emergency soft fork

to eliminate the inflation bug in 2010.

And there was also some hard fork

and soft fork stuff

around the 2013 accidental hard fork.

So let's just skim through this for a second.

So in this scenario

where you have 1% hash power

mining BIP 110,

let's just say hypothetically

that one day after that,

we have one day worth of blocks

on what we'll call the core chain,

which has 99% hash power at that point.

And then miners, you know,

quote unquote, wake up.

Now, hang on a second.

Why would it ever get that far?

Hang on a second.

They'd have to be asleep.

Hang on a second.

People sleep.

They can literally be asleep.

I mean, this is not a,

they're not sleeping.

They're talking,

the miners are talking about it.

You see mining disrupt,

they're all talking about it.

Hang on, just for a second,

let's just say

we wind up in that scenario.

I would argue very strongly

that the moment

the core chain comes out ahead,

there's very strong reasons

for people to say,

yeah, we're just going to

keep mining this

rather than have the PR disaster,

which is, you know,

100 blocks get wiped out.

That's crazy.

But why would you keep mining a chain

that might get wiped out?

All of your earnings are going to

disappear.

I mean, because you disagree

with that direction,

and then it looks like

it doesn't get wiped out,

and very quickly it's,

well, shit, we better not

wipe this out.

Yeah, but how do you trust

that all the other miners

aren't going to start moving over

because it's safer for them?

So you can collude

with the miners

to go and attack the node network?

Look, miners...

You can get your centralized

mining pool buddies...

Well, hang on, hang on,

you're saying miners

colluding to attack nodes,

but we've already established

that it seems like

the BIP110 nodes

are in the minority anyway.

I mean, it seems like

they're in the minority

in the technical community.

So, I mean, it is reasonable

to say they're in the minority.

Right, but again,

the same situation

happened with BIP148.

It was also a minority

and it also succeeded

in being a minority.

But it wasn't a minority.

BIP148, I was in rooms

where you could do hands.

We didn't bother to do hands

because every developer

other than...

Like, not every.

There were people

and this was sort of

the beginnings of Bitcoin Cash

because that did come

a year or two later.

But it ended up being

the same people

who did Bitcoin Cash.

But there were a few people

who were like,

no, I don't like this.

But it was pretty small.

Yeah.

In fact...

I mean, if you don't like it,

do a URSF.

Again, there's a clear

strategy for...

I don't think we're going

to do a URSF.

Do you guys think

that BIP110 is going to harm

Bitcoin?

Do you guys think

that BIP110 is going

to harm Bitcoin?

Yes, I do, yeah.

Why?

Because I think it's bad

to have nonsense

affect Bitcoin.

I don't know.

Wait.

How about we do...

These are the arguments

that we're dealing with.

This is our opposition.

How about we start

with just a poll.

Was Bitcoin Cash beneficial

to sort of Bitcoin

in the large sense?

What do you think?

I would actually say...

I don't think so.

Just like...

What's the question?

I missed the question.

Was Bitcoin Cash...

Was Bitcoin Cash, you know,

being developed,

splitting off from Bitcoin

or whatever we call it,

beneficial for both sides?

Well, can we say

compared to what?

Compared to not.

Compared to this,

they just didn't do it.

Compared to just staying

and continuing

to advocate for...

Sure, yeah.

I would say

that it is beneficial.

I mean, it kind of makes sense, right?

They wanted bigger blocks,

but they rejected SegWit,

which actually was bigger blocks,

which was, like,

just completely indefensible.

So, I guess,

what's interesting...

What I will say

is interesting about BIP110

is that it is

a potential minority

hash rate soft fork,

which has not been

attempted yet, right?

Because with Bitcoin Cash,

they said,

no, it's a soft fork

mainly because...

It's kind of weird.

They took the SegWit

SIG hashing stuff

and put it into theirs.

As the deadline approaches,

I don't expect it

to still be a minority.

Okay, so...

But that's, like,

what, a couple weeks, right?

So that's, like, real soon.

Okay, so...

So, we'll see.

So, we won't have to wait long.

But again,

if there's a whole bunch

of people who are

really, really for it

and nobody is strongly

against it,

that should activate.

And that's actually

how Bitcoin works.

Isn't everyone

strongly against it?

No, nobody is

strongly against it.

Right now, if people run...

Then write a URSF.

Right now,

if people run a client

that does not signal,

they just won't signal

on August 8th

or whatever it is.

So, isn't that...

You will fork off of that?

If someone mines blocks

on those networks,

that will be the fork.

So, that is the URSF.

If that has majority hash rate

and is not...

That's not a URSF.

So, a URSF is different

because you have

to coordinate around

how to reject

the soft fork.

So, you have to coordinate

around how to reject

the soft fork.

So, you have to coordinate

around how to reject

the soft fork.

If you don't do that,

the legacy chain

becomes incoherent

because it might just

continue disappearing.

It might get wiped out

a bunch of times.

One second.

Just for the audience,

let me just make sure

people realize

what the heck

you're talking about.

You're talking about

a user-rejected soft fork

where people decide

to come up with

some way of rejecting it.

One of the simplest

technical possibilities

is simply miners

and users

maybe some exchanges

just run the command

and validate block

on a block

in the BIP110 chain.

Simple as that.

Just to make sure

that even if it

somehow comes out ahead...

Right, so a few

large mining pools

decide that

the decentralized

node network

of BIP110 runners

the 15,000

plebs out there

that want to protect

Bitcoin's monetary purpose

that they're wrong

and those five

large mining nodes

are actually

in control of the network.

I hate to say this

but again,

this bit about

say 15,000

agreeing with BIP110

that sounds like

minority to me.

Everything I've seen

going to conferences

and all this

is they're actually

in control of the network.

If you have an

enthusiastic minority

that wants a change

and you have no

serious opposition

then the change

is happening.

There isn't any

serious opposition.

There's no URSF.

There is no

meaningful attempt

to resist this.

It feels like

Bitcoin Cash

was an enthusiastic

minority.

It just feels a lot

like 2017.

It just feels

a lot like that.

What do you mean

Bitcoin Cash

was an enthusiastic

minority?

Oh, they were trying

to hard fork Bitcoin.

That is a completely

different situation.

What's the difference?

Let me revise.

If an enthusiastic

minority wants to

restrict Bitcoin's

rules in a way

that nobody

actually thinks

is going to

harm Bitcoin

they should be able

to do that.

If somebody thinks

it's going to

harm Bitcoin

they have to

URSF.

Otherwise,

there's no defense.

If it's a hard fork

that's a completely

different situation.

Restricting Bitcoin's

rules in a way

that people don't

think will seriously

harm Bitcoin

but without a good

reason,

that doesn't

make it a

harm to Bitcoin.

Especially for this

kind of reason,

it's a social

precedent thing

that itself is

really ugly.

We actually did

rock, paper, scissors

and the person

next to me

asked the question

and I was going

to ask you

in the previous

talk was

let's say

that Bitcoin

Core had

in fact

responded to

inscriptions

by trying to

go filter them.

Probably what

inscriptions would

do is

go to

Bitcoin

Core to

just keep

on...

Spammers never

did that.

But we never

went down that

path.

The reason

why

inscriptions

became a

phenomenon

is because

there was a

shelling point

that formed

around that

particular

format.

But they

changed it

multiple times

for various

reasons.

There's a

lot of

people

who

are

trying to

get

their money

off of

Bitcoin

Core.

But

there was

never a

serious

attempt

by

Core to

actually

counter it.

But

obviously

if

Core had

it

would have

been...

We have

historical

precedent

that

there

was a

degree of

programmable

money that

was never

suitable to

put on

Bitcoin.

Ethereum is

very different.

Inscriptions don't

have

programmability.

They're just

pure assets.

They're pure

collectible

assets.

Don't give

them any

ideas.

It's a

different

problem.

It seems

like we all

agree that

if Bitcoin

had a

higher

hash rate

then that

would be

basically a

loss for

110.

You seem to

be saying

they will

come around.

We don't

have them

now but

they'll

come

around.

Is that

right?

It would

be much

more of a

loss for

the

miners.

The

miners need

to be

able to

collect

their

assets.

I mean

there's no

replay.

There's no

replay.

There's no

replay protection.

Replay

protection,

I guess,

in this

scenario,

if there

is a

split,

would be

on the

core

v30

side to

put a

big

opportune

in every

case.

If it has

majority

hash rate.

If there's

a minority

hash rate.

There's

very strong

incentives for

that.

Everything hinges

on that.

It becomes a

self-fulfilling

property.

You have a

little bit

of hash

rate.

Why not

have a

signaling

that requires

90%

like all

the other

soft forks

have?

Those were

minor

vetoable

forks.

That's

one

philosophy.

Yours is

also

minor

vetoable,

right?

Isn't that

what you

said a

moment ago?

It's not.

It activates

regardless of

whether there's

any hash

rate.

It looks

like BIP

110 is

in the

minority

in terms

of people

voting

for it.

It's

going to

become the

majority.

The same

way that

mandatory

signaling

in BIP

148

was 100%

signaling

after

August 1st.

The

majority

liked

SegWit.

They

thought it

was a

great

idea.

The

majority

did not

like SegWit

unless

you have

majority

mining

support.

You are

saying we

will activate

with a

minority hash

rate.

We hope we

don't.

You hope it

is the

majority

hash rate.

You are

saying it's

in the

code.

If we

enforce this rule. You explicitly are saying we will still enforce this rule with minority

hash rate. Right. The BIP 110 chain is Bitcoin. It's going to be the same as the SegWit chain

because it has the same mechanism. In order to avoid activating BIP 110, whoever is against

it is going to have to fork off. Let's say hypothetically that SegWit had in fact ended up

activating from the perspective of people running SegWit nodes with minority hash rate. That is

really the scenario I think we're trying to get at here. Say that again? There is a scenario

where SegWit could have activated with minority hash rate but majority node support. SegWit had

20 or 30% leading up to the UASF. Core would not have followed that. There was a UASF. I never

ran any software that would have gone on. I want to talk about replay protection real quick. In

this case you are saying this is Bitcoin. There will be no fork. There will be no split. There is

no replay. Although two op returns is a good idea because that's smaller. In the BIP 300, there is

a fork. There is sort of replay protection. You can opt into it. By default, there is not. By

default, if you are indifferent, then I say you haven't picked a side, which is fine, but your

transaction will be on both chains. You may lose out on the e-cash part if maybe that doesn't

matter to people if they are indifferent. If you wish, you can make a special transaction that

splits them permanently and then there are other ways of splitting.

What is the simplest possible transaction that would achieve that?

We changed it so the end lock time, if you do one less than the 500 year one or something, it's

like maybe 1,000 years or something. I'm not sure. That one will be mysteriously valid on e-cash

immediately. That will just cut the rule and return true for that one. That is the way. That is

the easiest way. We have an arbitrary backdoor.

You have to make a transaction on the e-cash side that won't be replayed on the Bitcoin side.

You couldn't make one. You can't really make a Bitcoin one that won't be replayed on...

I'm sure it must be theoretically possible, but I wouldn't say that would be the way to do it.

You would anticipate then there is going to be trading between these different things.

Absolutely. Of course. Yes.

But it is still SHA-2.

SHA-2 with D6D, yes.

I have a question for you guys. If and when BIP-110 gets 100% signaling and it looks like

it's definitely going to succeed, will you hard fork like the B-cashers to reject BIP-110?

No, it's temporary, right? So it's all good.

Right?

I don't understand.

Totally common sense and harmless.

If it actually got 100%, that would be an interesting discussion.

If, however, it gets, say, 50%, then this is a curious thing.

And if it gets, say, 5%...

Why would Binary do that?

Hang on. Hang on.

If it gets less, then maybe there's some discussion.

But I suspect if it gets 100%, it would say, yeah, you guys won.

I mean, I personally would not change any of my transactions, because I don't make inscriptions or...

But the tree depth, that's kind of like, ooh, I don't want that.

Okay, but you can have it once BIP-110 expires.

If this happens, I would be a lot less interested in working on Bitcoin further,

because what this would tell me is that the Bitcoin community and miners are fucking crazy

and are willing to go and do things that are a bad idea.

I agree completely with that.

But if Bitcoin Core just does its job and filters spam, then none of this has to happen.

Well, look, we fundamentally disagree on how technically feasible that is.

He said it in his talk that you said that there's no way to stop the spam.

You said it's a straw man and stuff.

No, you can't stop spam.

But they constantly equivocate on this basic point that is at the heart of the matter.

They say, oh, sure, we can't do it.

We are completely powerless to stop spam.

I didn't say completely powerless.

You're just making that up.

It's like saying, can you stop people from breaking into your house?

Well, of course not.

But are you just going to get rid of your door and your fence?

In practice, I have stopped people.

No one has broken into my house.

Okay, but you just get rid of your door and your fence because somebody got in one time?

Well, if they didn't work at all, this is the heart of the matter.

You keep dancing around.

You want to have it both ways.

You want to say, yeah, sure.

It's just a serialized set of bytes.

It's interpreted as an image later by whatever reads those bytes.

These are fundamental.

This is like a knife to the heart of your argument.

It kills it instantly.

It's a bullet to the head of your argument.

And then you say, well, sure, that's true.

But we can do it.

And I wrote down some of these comments.

Not that it should be like a quote-off or whatever.

But basically saying it's not possible to stop spam.

More hidden, better.

Hostility is the deterrent.

Then some other guy, that guy over there, he said, hey, is it code or is it hostility?

There's more equivocation on that.

It's just constantly going back and forth.

It's code as hostility.

Filters are, it's like your immune system, right?

You can't prevent all pathogens forever.

But you can put up a defense against them.

So is relay policy enough hostility?

What if Core said, you know, version 33, we revert back to 80 byte max data carrier,

whatever.

Would that remove the impetus for VIC-110?

Or is it like, no, we're on this track.

They'd also have to filter inscriptions.

They'd also have to filter inscriptions.

OK.

But like, why is this happening now?

Because inscriptions sort of are dead.

I mean, they're not dead.

But like, 2023, it was like, whoa.

But there's still a kind of could be argued that they are an officially supported way

of storing large files on Bitcoin.

And that's the problem.

People did it, and then it didn't.

Well, they're still doing it.

Can I ask you this?

I actually don't know how common they are now.

Runes are more popular or whatever.

Isn't a transaction a file?

Is what?

Is a transaction a file?

Is a Bitcoin transaction a file?

I mean, technically, no.

There's block files.

There's .dat files.

You can export it to a file.

As file, yeah.

So you just say, then, it's the exporting that changes the set of bytes into a file.

I mean, you could interpret arbitrary data as a file.

And that's what they're doing, right?

They're saying, this is a format.

And if you just read it as a common file type, then it is a file.

We're speaking a different language here.

It's impossible.

This is a very interesting question.

Let's just say, hypothetically, Core went and added all the filtering rules that you want,

and so on and so forth.

What would happen if a tiny minority continued to run LibreRelay, and basically, it just

ended up being all of the stuff you don't like went through LibreRelay, and blocks were

still full of it?

I mean, there's more technical defenses that we can keep escalating.

Wait, wait, wait.

Remember.

Like, in terms of mempo files.

Yeah, what would those be?

Like, would you say, no, we have to do a consensus change?

What I'm saying is, at that point, especially, well, you're saying after Bit.10 activates,

or if Core puts in filters?

No, no, no.

I'm saying, in the scenario where we say, let's just say Core had implemented all of

these filters, all of the mempo filters.

Now, in a scenario like that, where, let's just say, hypothetically, 90% of nodes are

running Core, they filter all this stuff, but the small minority running LibreRelay

go and mean that blocks are still full of this stuff.

What would you say?

Yeah, so the miners that are working with LibreRelay are malicious, and they're attacking

the network.

They're doing something that the nodes consider to be antisocial.

So, do you want to fork them off?

Like, would you say, in that scenario, that we should do some kind of consensus change

to force off the miners that are doing that?

Like, do you just get back to consensus changes still?

It depends on how much damage is possible.

Right?

So, the thing about intentional...

Let's say 25% of blocks are this.

What?

Let's say 25% of blocks are by miners who do this.

I mean, the biggest factor is the toxic data factor.

Right?

Like, does Bitcoin look like it intentionally stores large files or not?

Right?

That is the vector.

Here, like, 90% of nodes, you know, quote, unquote, don't allow this, et cetera, et cetera.

Like, do you just allow this situation to go on indefinitely?

It depends on how much damage is being caused.

I would say, like, the UTXO set went from 4 gigabytes to 12 gigabytes pretty fast, and

if it had kept going to 50 gigabytes or 100 gigabytes or 200 gigabytes...

Well, I mean, that's not related to putting data in transactions, though.

What?

In fact, the operaturns, those don't bloat the UTXO set, so it's actually helping the nodes.

See, this is the sort of technical argument that you get from poor people, where they

look at the...

They say a statement, oh, the operaturn causes less bloat than...

It certainly does.

Yeah, so we're actually helping with UTXO set bloat, and it's like, no, but you're removing

all of the context from that.

If you added all the operaturns to the UTXO set, it'd be huge.

The context is that being friendly to spam is what causes spam, and spam is what causes

UTXO set bloat.

If we're hostile to spam, there will be...

But spam, according to you, does not cause UTXO bloat.

Yes, it does.

No, it does not, because...

BRC20 is spam, and that was the main cause of UTXO set bloat.

You defined it as operaturn as spam.

After you said, in your talk, you said it's not possible to define spam, but then you

said it's really clear that some things are, and operaturn does not bloat the UTXO set.

Just because it's impossible to draw an objective line between spam and non-spam does not mean

that the categories of spam and non-spam don't exist.

Would you...

Okay, so it sounds like there's mempool policy versus consensus.

In a BIP-110, let's say BIP-110 succeeds, or even if it forks off some way, and there's

its own implementation, would the idea be, let's make consensus and mempool relay policy

as close as possible, or just...

No.

You want them to be different.

Yeah, no.

Satoshi clearly designed the consensus rules to be really, really loose so that we don't

have to hard fork in new functionality.

And he clearly designed policy to be robust to prevent people from doing crazy stuff on

the network that harms the network.

What if there's a LibreRelay-110?

What?

Because this guy might make a LibreRelay-110, right?

Well, of course.

I'm sure he will.

He probably will.

He definitely will.

So then you have to keep making consensus changes sort of reactively?

Well, no.

So this is exactly why it's different from SegWit.

So the situation right now is that Bitcoin is not hostile towards spam because Bitcoin

Core is not hostile to spam.

This is a new situation.

Bitcoin Core and Bitcoin were always hostile to spam in the past.

Even if Core were, there's a guy with a hat, and it's like 110.

Right, but what I'm saying is he's an attacker, right?

He's a malicious actor, and we have technical defenses against that, and we can keep...

Are we supposed to be doing questions or something?

Is that what's happening?

Do we want to leave 10 minutes for questions?

Okay, sure.

Sure, sure.

Oh, it says three minutes there.

All right.

Yeah, but we...

I think we did that.

Any questions from the audience?

Yeah.

Thank you.

To the fork authors, what are your plans following up the activation of your respective forks

in different contingencies?

Wow, that's a wildly abstract wording of that question.

But it's funny because, of course, he was just saying a moment ago, we don't need any

contingency plans because we're all...

So yeah, I think with mine, it's a little bit easier because we deliberately hard fork

off to a different thing.

We cut the difficulty down.

So something will exist.

There will be some blocks mined.

There may be crazy difficulty adjustments or something.

The chain may stall out.

There may be people renting.

Who knows?

But something will happen, and we'll probably learn from the experiment.

So even if it isn't successful, we would all gain at least some information.

And then, of course, if it could have limited success, it could be cool as a demo.

It could have outrageous extra success.

It could be more successful than other famous projects.

It would be fun.

So I think that's where it goes for me.

And then BIP-300 is the soft fork.

Anyone could use that at any time.

And in fact, I'm pretty sure that Litecoin, they have plans to make use of the enforcer.

And so that will probably happen also.

What was the question again?

Sorry.

Basically, what are you going to do in the follow-up after the activation of your fork

and the different realities where things might play out?

In the follow-up of the activation?

Two weeks from now.

Are you on your computer?

So it expires after a year, and the BIP says that we should plan to activate some other

better permanent solution to this.

And I can't speak for the BIP authors, but my opinion is that this would be a good time

to do covenants.

So that would be a good follow-up, I think.

Something that prevents large contiguous data, larger than 256 bytes, and covenants is what

I would say.

But that's just my personal opinion.

I can't speak for the actual BIP authors.

Another question?

Don't be shy.

Thanks so much.

This question is to Paul.

You're hard-forking to e-cash, which seems to me like you want e-cash to be a lot more

expressive, kind of like programmable, or just express whatever you want with it, right?

I'm just kind of curious.

Have you considered just building this on something like Bitcoin Cash first, instead

of just doing a hard fork?

No, because I don't think that would really help.

Layer one in e-cash is just exactly the same as Bitcoin Core.

So the idea is to try to keep as much of what people already like.

The thing is, it could be interesting.

I mean, nothing's stopping Bitcoin Cash from using the activator.

So that's part of the advantage of the Q-SYS, the core and touch software.

So you could, but having optional large block L2 over a smaller block L1, that is sort of

just more efficient than, like, you wouldn't even really be.

So I haven't really thought about that, but as I mentioned, I'm pretty sure Litecoin will

try to use the Q-SYS 30031 activator.

So it's certainly possible that Bitcoin Cash could do it as well.

And I know at some point there was some telegram group about Bitcoin Cash drive chain or whatever.

I think nothing's really stopping.

To just maybe re-explain this part, all the L2 software that we build, that works with the

BIP300301 activator and that could kind of work with almost any blockchain.

So actually it should be possible to just take the entire stack of stuff if anyone likes it.

And it would be mostly independent of the L1.

So I think that we probably will see some people do that.

For, I guess, all four of you, preferably one at a time, how confident are you in your

thoughts on the forks and why?

You can go first.

Well, I can't believe I'm on a panel where Paul Sztorc, of all people, is a reasonable one.

And I guess, yeah, I'm actually pretty confident that Paul Sztorc's drive chain's badly named

e-cash thing will, you know, become its own separate currency and do whatever and it might

die eventually, whatever.

As for the BIP110 thing, I think, at the moment, I think it's more likely than not it gets

sufficiently little hash power that it just dies out and doesn't even really become a

separate currency.

But, you know, I think it's a pretty high chance in the double digits that it does get

a minority hash power and then ultimately becomes a separate currency.

That may at some point die out, but that'll be a little ugly.

And I'd say it has a very low chance, but not zero, that somehow it actually does get

majority hash power, which will be very interesting.

I can say, yeah, the drive chain, hard fork, that seems like it'll just happen, right?

You can do that.

It'll be a lot of fun.

I'm pretty confident you can do that.

I'm not advocating for doing that, but, you know, it'll happen.

It may encourage more people, because I think there are some innovations, like the sort

of one-way replay, which people probably like, because, well, anyway, and then taking the

old coins.

And so you might see research, because back in a few years ago, we had a lot of different

hard forks, forking off from Bitcoin with, like, Bitcoin Diamond, Bitcoin Gold, whatever.

So, like, hey, maybe people get into that stuff again with new rules.

With the BIP110 one, yeah, I don't know.

It might be minority.

It'll be interesting in the next two weeks, because it might be like, oh, well, actually

we realized that we don't have enough support, so we need to change something or tweak something,

you know, or push it off.

I don't know.

We'll see what happens.

If it does end up being minority, it sounds like the people running it, if you're a representative

of them, don't want to have a minority split side, right?

And so that would sort of be, like, not a good outcome for BIP110 people.

So, hopefully we can avoid that.

Yeah, I mean, like, all I know, I mean, I'm very confident, like I said, because of the

precedent of BIP148, so, but, like, if something crazy happens and, you know, the miners collude

to not activate BIP110 against the wishes of the nodes, which are the soul of Bitcoin,

which is crying out to limit spam, you know, all I know is, like, activating it, if it

activates, that's how Bitcoin is supposed to work, and if it doesn't activate, that's

not how Bitcoin is supposed to work, and we have much bigger problems if BIP110 doesn't

activate, you know.

Okay, let me give you, like, a metaphor, because the question was how confident are you, and

the metaphor is this, we're on the Titanic and we're headed maybe for an iceberg, we

don't know, because it could be, like, a parallel universe or something, but I'm, like, grabbing

all the dining room tables and I'm, like, sawing them apart and trying to make, like,

life rafts, like, as quickly as possible, and I hope that we miss the iceberg and that

everything's fine and that lightning works out really well and all the other stuff we do

works great and everyone adopts Bitcoin and everything's fine, and I think that would be

wonderful, if we miss the iceberg, that would be great.

Now, do I think these life rafts are going necessarily to save us all?

Probably not also, so I just think, but, like, what else would you do in this situation?

So, I mean, to me it kind of blows my mind we even spend so much time talking about BIP110,

that was low on my list of derangements that I alluded to in my talk about, I had this

long, long list of problems with Bitcoin, and the problem with BIP110 is not just that

we have it, but that it's somehow monopolized so much of the conversation for, like, a year

and a half, I think that's very bizarre.

Because it's really important, people running those actually care.

With respect to BIP110, currently my expectation is that on August 9th it will just, like,

not have blocks.

I agree with Peter, again, it's funny that we sometimes do agree, where, like, if it

somehow got 100% hash rate, I would just think, like, wow, I guess for some reason I'm not

looking at the world, like, I see something, I'm not seeing something about the world.

I would almost then think, though, we're about to hit an even bigger iceberg or some other,

that we're even more screwed than we were before, so I don't know exactly what I would

conclude from that, but those are my thoughts on this.

Can I do an article analogy, too?

I think we're on a nuclear submarine, and, like, we're the best top of the line U.S.

nuclear submarine, and no one's going to fucking touch us, because we're on such an awesome

boat, but with tail emission, I do think we're probably going to run out of reactor fuel

in 20 years, and we should think ahead 20 years to how we're going to make that work.

These guys, on the other hand, seem really pissed off that someone forgot to go and load

all of the frozen pizzas in, and we're missing that one nice thing, but we'll survive without

frozen pizzas.

We'll get some more in 90 days when we restock.

I think the analogy is more like this.

The iceberg is this arbitrary data thing that's coming at Bitcoin, and it's basically going

to kill any hope of Bitcoin being used as money for the foreseeable future, and maybe

forever, because if Bitcoin's culture forgets that Bitcoin is supposed to be money, then

at that point, it just becomes Ethereum, and nobody cares where it goes, and there's a

little button that all the miners have that just zaps the iceberg and makes it go away,

and that's flipping the bit to activate Bitcoin.

The nuclear submarine goes under the iceberg, just to be clear.

I mean, why is it so important to you?

It's so important.

I'm talking about having 8 billion users and Zcash privacy.

It seems like this is a completely different realm of significance to whether or not some

people sometimes put large op returns.

I'm honestly, I'm honest to God, curious.

This is your iceberg.

Why is it so important?

I just told you, if we allow arbitrary data storage as an officially accepted use case,

then it outcompetes the monetary use case, and it makes everyone forget that Bitcoin

is supposed to be money, and you're actually seeing this with Michael Saylor.

He's saying Bitcoin isn't money.

He's saying my STRC derivative is going to be digital money, and Bitcoin is digital capital.

It's like turning into this thing that isn't money.

So you're forking Bitcoin because of Saylor.

I know, and it's terrible, because Saylor does say, he literally says everything both ways.

I almost have a list where he said Bitcoin is money.

He has tweets where he says Bitcoin is money, then he says Bitcoin is capital, Bitcoin is real estate.

I don't think he said Bitcoin is money for a while.

He used to say it back in the old days, back when he was ingratiating himself to the Bitcoin community.

But he's not into ordinals and runes, right? Or yet?

No, he wanted to use inscriptions for his digital ID thing.

Originally he had some kind of ordinals company thing.

But he just does everything every way.

I don't think he has any idea what he's actually talking about.

I agree.

Guys, we have a last question here.

Well, thank you for the panel. It's very entertaining.

That's for sure.

I think all the people on the panel seem to be in agreement that Bitcoin, at the minimum,

has some small realistic chance of activating and there's some chance of a giant split.

So given that, I guess I wanted to ask the opinion of everybody on the panel.

How do we think centralized exchanges should react at that point of activation,

given there is some uncertainty on what will happen,

and following a losing chain for a centralized exchange?

I mean, I don't think there's going to be any uncertainty leading up to the fork.

Like, a few days before the deadline, the miners are all just going to turn it on and everything is going to be fine.

Maybe. So bizarre. I mean, like, yeah, I agonize over every detail of, like, oh, what if maybe this would happen?

It's like you're piloting the nuclear sub and then someone's like, hey, what if we, like, just, like, we're not, like, looking where we're going.

What if we just hit something? No, we're definitely not going to hit anything.

That's what Core did with ripping out the opportunity.

I think it's funny that if you do launch something that may split the chain, you kind of are screwing over the exchanges,

which I think is kind of funny because the exchanges, you know, they made so much money and they kind of had the run of the place, you know.

And I just honestly, I think given how much money the exchange make, and I think it'd probably be the right thing to try to,

if there is a chain split, just split it, like, under the hood, especially because it's like Bitcoin Core is the node,

and just split it and make it, like, the two things, and if the 110 people won't give it a name, call it Bitcoin 110,

and then just credit everyone with it. I think that's what they should do.

And so will they actually do that? I don't know.

And if they don't do that, will it just be total chaos as their, like, transactions are replayed and drained from them?

Or is it a bad precedent for them to set and say any random Yahoo who does a hard fork,

now they have to have this build this infrastructure? I don't know, but I'm saying in terms of August 2026,

I would just say, just, you know, just credit everyone's coins and kind of let them trade,

because they make more money trading. So that's my actual answer.

As to what they will really do, I have no idea.

I think it will be really interesting as the days approach, because exchanges failing to go put up the press releases,

saying what they're going to do, will be a very strong sign that what I think is the most realistic outcome is going to happen,

which is BIP 110 basically just fails.

I think that's the least likely outcome.

The most likely outcome is the miners are going to be like, wait,

so you're telling me there's a bunch of people who really, really want to activate this,

and they're going to start throwing away our blocks, and there's absolutely no reason to oppose it?

Let's just turn it on. The legacy chain is going to have a bunch of vulnerabilities that the new chain doesn't have.

Let me answer this poor guy's question.

So if exchanges do start putting up those press releases, then I agree with Paul there,

which is the obvious thing to do is just credit both sides and then start letting people trade.

From a technical level, it's a bit of a nuisance, because you have to do a few extra steps

to make sure you do BIP 110 non-compliant transactions to cleanly separate both sides.

But fortunately, putting two up returns in one is enough to do that.

It's not terrible, but certainly with cold storage, the nature of cold storage is

often the systems that actually handle those coins are really locked down,

and touching them is something that no one ever wants to do.

So it might be the case that some of these cold storage systems,

it's going to be a pain in the ass to change them to let the coins get split.

But we'll see.

I think maybe what we maybe all agree on is that since exchanges are trusted third parties,

it's always better, no matter what the case is, to have your own keys and have your own coins,

and then whatever happens, you'll have everything.

Do people agree with that?

I hate to say this, but one catch with this is a lot of wallets are not going to give you a way

to cleanly split things.

If you had to write it on an exchange, you would.

Yeah, but at least you're free to do it if you can figure out how to do it.

But I don't think it's worth it to even talk about a chain split,

because the historical precedent is that there won't be a chain split.

All of the miners will just figure it out in the days leading up to the deadline.

But yeah, withdraw from exchanges.

Not your keys, not your coins.

One super last question.

I was just going to say...

I'll go for like eight hours, whatever, I don't care.

Would you just quickly TLDR why you decided to hard fork specifically,

and is it because to use Taj's language, you just want this to actually happen?

We haven't had enough competition.

I think things have actually been really boring over the last ten years.

And the fact that we're talking about 1.10...

No, and it's like, 1.10, I think Peter was clearly...

I was waiting to get rid of the op return limit for a really, really long time.

I always thought these standardness limits were misleading, mostly.

And I just can't believe that the fact that this is what we're talking about is 1.10,

and we're not talking about how to add privacy to Bitcoin or how to do anything cool.

We're just talking about all this nonsense.

We need to have some other thing to do.

And I think that, obviously, all the altcoins people really don't like,

and a lot of them, most 99% of them, are terrible.

And we don't really want to give Ethereum any...

So I thought this would be a cool thing.

Everyone will get coins.

If you have people who are very interested in doing something with whatever,

Opcat or whatever, they want to do some kind of near-Bitcoin thing.

We have some other flavor.

So I just say, well, give us some other thing to do.

I think things have been very boring.

Of course, saving Bitcoin from existential threats is not the most glamorous or sexy thing.

I definitely agree with that, but that doesn't mean it's not important.

Okay. Thank you to our panelists.

A huge applause, please.

All right.

That was an incredible final panel.

I think a really great last day.

So thank you, everyone, for showing up for all the talks, workshops, presentations,

the hackathon finals that we did today.

You know what they say.

Sometimes when you set off fireworks, you get to watch a forest fire.

Oh, I see.

Oh, that did happen in Canada recently.

Okay.

Without further ado, this is the final presentation that we have for today.

So we are going to hand out a couple of awards.

What else have we got, Alex?

Yeah.

This is an amazing conference.

Let's finish up and give away some awards.

Final Day of Clothing Awards.

I don't remember what we're...

Yeah, so we had 16 projects.

So thank you for everybody that participated in the hackathon.

This was incredibly impressive.

The judges were blown away by the quality of your projects.

I can attest that there was vociferous arguments in the judges' room.

People were at their throats arguing for your projects.

So, again, congratulations to everybody for making incredible projects.

Wow.

Look at all the projects.

Again, we have a new hackathon platform.

So for all of posterity, you can view your hackathon projects at bccpp.dev.

In addition, you'll see your hackathon project on your dashboard.

So as you go to more Bitcoin++'s and compete in more hackathons,

you'll see all of your projects on the site organized.

It'll be pretty amazing to see how this grows over time.

So we had a record number of prizes.

17 million Satoshis worth of stats and in-kind gifts that we're giving out.

So thank you to all of our sponsors and projects that put up prizes.

And thank you for all of you for competing to win them.

So very excited to be handing out some cool stuff today.

We had a couple of bonus challenges that were put up by a lot of our sponsors.

Exactly.

Yeah, thank you to all of our sponsors.

First, Soapbox is our official hackathon sponsor.

They support us for all of our hackathons.

And we saw a bunch of very impressive projects using Shakespeare

to vibe code your projects on FreedomTech.

Winning one million Satoshis to the best project built with Soapbox Technologies

goes to BitVote.

Congratulations.

And when you get an award, feel free to come on stage,

receive your prize, take a picture.

Unless TeamVote BitVote is not here.

BitVote's not here.

Oh, they're there.

Come on down.

I'll give it to them.

We'll take a picture after.

We'll take a picture after.

There's a lot of stares.

Okay.

But yeah, another thing, if you don't want to be on camera,

obviously don't come on stage.

Just, yes.

Cool.

Shout out to Bitcoin DevKit.

The Bitcoin DevKit Foundation has supported several of our hackathons.

So, unfortunately, Thunderbiscuit had to leave.

But winning one million Satoshis for the best project built with BDK

goes to BDK Compact Block Filters and Bowl.

Congratulations.

Pablo.

It's not every conference that someone will present on something at a presentation

and someone will include it in their project in the hackathon.

So, that's really cool to see.

Yeah.

Next up, we had Blockstream, who I believe put up some jades.

Watch your step.

I'll try not to trip like the other day.

Okay.

Yeah, you want to present it?

Oh, go ahead.

Where are you?

I gave you the wallet.

I'm here.

I need to show you.

Basically, I was suggested that we should give a hardware wallet to the winner.

I already gave him a virtual call.

So, this is just a shake of hands.

Congratulations.

And, yeah, thank you for using something that looks like ours.

And now you can use it.

No problem.

Awesome.

Thank you.

Yeah.

Next up, we have...

Leo.

Leo, are you here for the presentation?

Here you go.

This is also exciting.

The Lightning Labs just launched a new project this week,

and Leo's here to present an award for it.

Yeah, very cool to see two projects implementing Wavelength.

I heard good things.

I am aware of some of the limitations.

It was very cool to see you integrate it so quickly into your web apps.

The winner of the prize, which is a demo presentation at the quarterly demo day

and also a one-hour vibe coding session with a Lightning Labs engineer,

goes to OpenStays.

Congratulations.

Congratulations, OpenStays.

Great.

Thank you very much.

Thanks.

Peter.

I think this is our second-to-last bonus challenge.

How many of you have ever used OpenTimestamps before?

We have one, two.

Okay, a handful of people.

That's really great.

I'd say about half.

This is a special prize.

This is the...

Yeah, Peter, do you want to explain what this prize is?

Well, so, you know, OpenTimestamps has this interesting property

where it's just timestamping data,

which means that almost anything you can timestamp data.

So this is the 42,000 sats prize for the most unnecessary use of OpenTimestamps

in otherwise serious projects.

In the very serious project, I forget what the heck the name was,

but, you know, it involves prime numbers,

and timestamping prime numbers is completely fucking useless.

Congratulations, CanYouHackBTC.

Yeah, CanYouHackBTC, a very cool educational project.

There you go.

And I'll give you some lightning later.

Awesome.

Great, congratulations.

Watch yourself.

All right, and last but certainly not least goes to,

we like to give this prize out every Bitcoin++ conference,

to the best beginner hack.

So this goes to teams where every member

is either a first-time contributor to open source or Bitcoin.

And this one, we are very excited to give out to NodeSignal.

Congratulations, watch yourself.

Congratulations on your first hack.

It was incredible, yeah.

Awesome, all right.

Yeah, moving on to our honorable mentions.

These are overall fantastic teams across the board

that created very quality projects generally,

but didn't quite make it into the top three.

So we have six incredible projects to present honorable mentions to.

The first goes to Silent Receipts.

The second goes to BitVote.

Oh, come on up, yeah.

I also got the...

Watch yourself.

We get two of these, I think, right?

Okay, one, and then...

Oh, that's all right.

Well, congratulations, yeah.

Okay.

Final challenge is getting off the stage.

All right, we have a couple more.

What's up next?

We've got CryptoProof Visualizer.

Congratulations, Sundar.

What a great project, yeah.

Congratulations.

Our next honorable mention goes to NodeSignal.

Do you want to leave the name up?

Leave the name up, yeah.

Our next honorable mention goes to...

All right, what else have we got?

Is This Good for Bitcoin?

Just Ask Bits.

All right.

A couple of guys coming.

Great.

Well done, Tuma.

Nicely done, guys.

Great.

And our final honorable mention goes to...

Okay, compact block filters in bowl.

Congratulations.

All right.

Some very incredible projects that went through.

Unfortunately, only three of them could make it to the top overall.

Yeah, the moment we've all been waiting for.

So a reminder, in third place is going to be winning 750,000

Satoshis along with Bitcoin++ tickets and an even bigger

Bottle of maple syrup, which they get bigger over time.

And second place is going to be getting 1.75 million Satoshis as

Well as Bitcoin++ tickets and an even bigger bottle of maple

Syrup.

And finally, first place is winning a whopping 2.5 million

Satoshis, Bitcoin++ tickets, and the max addy of them all,

Bottles of maple syrup.

Enough maple syrup for a year, depending on how many pancakes

You eat.

All right.

So in third place goes to...

Actually, we have a few sponsors to thank first.

Bitcoin++ would not be possible without generous support of our

Sponsors.

So I want to call out to NIDIG and the human rights foundation

Who are our headline sponsors for not just this conference but

All of the other events we're doing the rest of this year.

So a very big thank you to them.

Also want to shout out stacks, who's our workshop sponsor.

They help us run our workshops every year.

So a big thank you to them.

And then it's not on the slides, but also thank you to layer 2

Labs and Paul for sponsoring this event.

Some really lovely banners, decorations that got contributed

For them.

So thank you very much, Paul, for making this possible.

We are doing an after party.

It's unofficial.

So bring some sats for beer.

But it will be at the rhino, which I believe is like maybe a

Ten-minute walk down the street.

So I think we'll probably get there around 637 and hope to see

Many of you there where we can continue talking about projects

And forks and consensus and bitcoin.

So thank you very much.

All right.

Without further ado.

All right.

Third.

In third place, we have actually before announcing third place,

We have one more very important award to give out, which is our

Star volunteer award.

So we like to give this out to the volunteer that we feel like

Showed up early, stayed late, was down to help out with

Whatever was necessary.

Bitcoin++ would not be possible without our volunteers.

So I want to issue a very heartfelt thank you to each and

Every one of you for signing up and showing up.

We're definitely looking for more volunteers for future events.

So if you enjoyed the conference and want to get more of a

Behind-the-scenes look at an upcoming event, we'll be having

Events in berlin and in seoul later this year, and we'd love

To see you there to help out.

So without further ado, a big thank you.

Oh, and they're getting hall of fame and our token of

Appreciation, which I seem to have lost.

This goes to hugo boss.

So congratulations, hugo.

My understanding is he had to catch a train already, but we're

Big.

Okay.

Cool.

Great.

Where were we?

Oh, yeah.

Third place.

So can we get a little bit of, yeah.

And third place goes to winning 750,000 satoshis and bitcoin++

Tickets and a medium-sized bottle of maple syrup goes to

mtp.

I believe he already had to head to the airport, so big thank you

To him.

Okay.

Second, winning 1.75 million satoshis and bitcoin++ tickets

Goes to can you hack btc.

All right.

So that leaves for first place where 2.5 million satoshis and

Tickets to upcoming bitcoin++ tickets.

And a massive bottle of maple syrup.

And the title of overall winner of bitcoin++ consensus edition

Hackathon goes to template watcher.

Template watcher.

Thank you.

Incredible.

So we're all very excited about watching the upcoming forks

Over the next few weeks on template watcher.

So we hope we get it shipped to production and are looking

Forward to paying attention.

Yeah.

Good job.

I think that's all we've got, guys.

Thank you again to each and every one of you for showing up

To bitcoin++ and i can't wait to see you at a future conference.

So see you at the bar.

Massive thank you to the toronto community for welcoming us.

And thank you for matthew and leo who are local canadians who

Made this event i think a lot easier than it would have been.

Also kevin who works with the bitcoin++ team.

Alex for running the hackathon and all of our crew behind the

Scenes making bitcoin++ work.

It wouldn't be possible without you.

And thank you to all of you again for coming and i can't

Wait to see you at a future event.

So thank you very much and until next time.

Applause.

Music.

Music.

Hey, peter.

Howdy.

How are you doing?

Another conference.

This one is a little different.

Yeah.

It's in the town i grew up in.

You grew up here?

Like, here, here.

I mean, I used to have, like, an art studio just up that way.

I mean, the first time I was here, I was probably, like, 14 or something.

What was your medium of art that you explored?

So, I did, like, electronic art.

Made a bunch of stuff that you could kind of call clocks.

I made systems that showed behavior over time.

And I grew to go and hate how bullshit my entire field was.

Because we were really not very good at it.

The clock industry?

The entire, like, integrated media art industry.

I mean, there's this sort of thing where all of these electronic art pieces,

They all become a game of, like, spot the sensor.

And there will be a sensor.

You hit the sensor, and it does something.

And that's it.

So, you know, I tried very hard to make all my art pieces have no direct interaction with the person there.

It would rather be some, like, slow, long-term thing.

Which, again, gets back to, you kind of call them clocks.

Yeah, then it's kind of like a sidecar, right?

It's like, here's the art, and then here's the technical integration.

And you stick the thing in, and it's all...

I hate to say this, but working on Bitcoin Soft Forks is much more artistically meaningful.

Oh, where do you see the artistry?

Art is in everything.

Art is in a beautiful idea.

Check, lock, time, verify.

You check the lock time, and you verify.

It's a beautiful piece of code.

Now I see check, lock, time, verify in a completely different light.

Did you write it in Toronto?

Check, lock, time, verify...

Yeah, I would have written it in the GTA area.

I won't narrow it down more than that, but GTA area.

Although, it's possible some of it I've written while I was traveling.

I mean, since roughly 2014, when I was doing this full-time,

I suspect I've probably been to something like one Bitcoin conference every one to two months

for, you know, 12 years straight.

Yeah, that seems like a lot. Yeah, it is a lot.

One question I was interested to talk to you about today. One of the things that we saw a lot in these panels is this recurring theme of

you have to fire the miners. If the miners go against what the users want, the miners are adversarial, so they must be removed.

Can you explain to me, like, what is that thought process? Like, what are they trying to articulate, and do you agree with it or disagree with it?

So, in theory, I agree with the idea that you can go fire miners. The problem is, this is coming up in the context of BIP-110,

where it looks like on activation day, there's a pretty good chance they're going to have 1% hash power.

And under that circumstance, all right, maybe fire the miners. But to fire the miners and not have a fork,

the people who do the firing need to represent some kind of economic majority.

You know, enough people to meaningfully make the coins on the other side not worth enough.

And if you do a show of hands, and the people attending this, do they run a BIP-110 node?

I really should have done it while on stage, but I suspect it might be, you know, two, three people.

Like, they just, they don't have the numbers. Now, you compare that to, say, SegWit,

where through the UASF movement to activate SegWit, there's a legitimate fire the miners moment.

Now, do I think they necessarily had the economic majority? That's not clear.

But it was sufficiently unclear that miners said, you know what, let's avoid creating a bunch of drama

and just do this reasonable thing called SegWit. BIP-110 is not reasonable.

What's this wipe-out scenario that they keep talking about?

So, their hope is, I'm going to say hope, is that even if they get a minority of hash power,

they can threaten the majority chain, the chain that Core and all the other implementations follow,

in the sense that if the minority, the BIP-110 minority, eventually gets majority hash power,

from the point of view of the Bitcoin Core nodes and LibreRelay and so on, they would then switch.

Because BIP-110 is the software, it only tightens the rules.

From the perspective of Bitcoin Core, BIP-110 compliant blocks are all valid.

Now, the problem with that argument is that, yes, that might be a reasonable argument,

40% hash power was on BIP-110, but it'll probably have 1%.

And in 1%, what's the chance of 1% catching up for very low?

There's another thing Chris says, where it's like, okay, it's only the 1% of the hash power today,

but imminently before activation, the miners are going to make the switch.

Is there some merit to it?

Like, someone else told me is that if there was more fees and more economic activity

on the tighter ruleset chain, then the miners would switch, and it doesn't matter what happens before,

because after activation is when that switch would happen.

You know, the lack of replay protection might actually go and shoot themselves in the foot there,

because there will be the same amount of fees and activity on either side.

Now, maybe going further on, or I should say, there will be the same amount of fees and activity

on either side of BIP-110 compliant transactions, right?

Because on the BIP-110 chain, if you make a transaction, it's valid on BIP-Concord.

Now, that can kind of change over time as people split their coins and whatnot,

but it's certainly plausible that BIP-110 would not get all of this interest,

because it would be creating blocks a lot slower.

Just to give an example, let's say BIP-110 gets 1% of the hash power.

Now, multiply 10 minutes by 100, are you going to keep using it?

Well, some diehards might. You'll get roughly a block a day,

which is enough to go trade your coins, but it's not a pretty picture.

Your next halving is going to come well into the future,

and the halving is only going to cut the difficulty by a factor of 4.

So, your blocks are still slow, and then the next one will be another factor of 4,

and again, they're still slow. So, that'll be ugly.

Can you explain what replay protection is?

So, that is where you design the rules of the side that forks off,

so that transactions on the old side are not valid on the new side, or vice versa.

There's some different ways doing replay protection,

but because the BIP-110 people are convinced that they will be Bitcoin,

that what we call Bitcoin will be their chain, they have not done this.

Now, compare that to say, I think, what's a good example?

There are a few examples where they've just changed one little thing in the transaction format

to ensure that transactions don't happen on both sides.

This is an issue for wallets that want to cleanly separate the coins,

then trade them separately.

So, if you have good replay protection, there should be an easy way to cleanly separate them.

And BIP-110, the only good way to do that is deliberately create a BIP-110 non-compliant transaction.

Probably the simplest way to do this is just put two up-returns in it.

There is a video I watched from you of a talk you gave in 2015,

and you're describing that there's three groups in Bitcoin.

There's miners, the devs, and there's users.

So, how do we see that today?

What is it that the miners and the users and the devs, they're all in harmony?

And what is it that the miners are doing adversarially that would warrant firing them?

From my point of view, nothing.

I just don't agree with the BIP-110 guys.

Now, from their point of view, they think the adversariality is the fact that they have not filtered out,

as they term it, or censorship as other people term it,

transactions that the BIP-110 guys consider spam.

And at the moment, something like half of the transactions being mined at the moment,

I mean, I literally looked at memepool.space about an hour ago,

but half the transactions are things that BIP-110 considers spam.

So, other than Ocean, they're all mining this.

And even Ocean actually mines some of these blocks containing quote-unquote spam,

because miners pointing their hash power at Ocean have chosen to mine the concordant client rule,

you know, mempool policies.

Does that mean that if there's a set of all transactions right now in the mempool,

half of them are spam?

So, assuming that there was no changes in the transactions that are being made,

then when the fork happens, the NOTS BIP-110 chain will only be mining a subset.

Yes.

And because they're only mining a subset,

it wouldn't make sense that they would be able to attract the miners over to their chain,

because the miners would rather have the fees from the more loose rules.

That's a good argument.

Like, yeah, I mean, of course, an issue with this is at least at the moment,

fee revenue in general is just really low.

So, you can kind of go say it just doesn't matter either way.

But, you know, one way this plays out is you could imagine leading up to this,

there's more hyperannot descriptions,

and they push fee revenue up in a way that the BIP-110 chain doesn't.

However, BIP-110 does not successfully actually stop all this stuff.

One bizarre outcome of this could be that the inscription guys,

you know, that meme coin community,

they create a meme coin that's deliberately BIP-110 compatible,

and ironically push up fees on the BIP-110 chain,

because they're trading stuff that BIP-110 claims that they're going to stop.

So, this can play out in strange ways.

Now, in that circumstance, you could also have a circumstance

where most of those transactions get replayed on core, or maybe not.

I mean, it all depends on how this plays out.

But there are a lot of weird things that can happen here.

Does that mean that unless there is a URSF,

it really could be possible that the core chain would be wiped out

and re-org'd into an AUX chain?

It's absolutely possible. I think it is not likely.

And one reason I think it's not likely is like,

let's suppose that AUX survives more than a day or two.

So, it does have some blocks.

I mean, really, of course, given how slow blocks are,

we're really going to be talking like a week or two.

But if it does survive, it's quite possible the way miners deal with this,

they should say, look, you know, we ran invalidate block on their chain.

It certainly isn't going to switch.

It wasn't likely to switch anyway,

but you can be confident that the core chain is going to continue

even if something weird happens.

And one example of something weird happening could be

maybe the Bitcoin 10 guys do an attack against Bitcoin.

Maybe they start creating poison blocks that take a very long time to validate

to try to get hash power either off the core chain entirely,

or make it ineffective.

Maybe there's something entirely different that we didn't know about.

I mean, maybe there's some way that they can remotely

denial of service attack pools.

You know, the sky's the limit for what's possible.

Do we still poison blocks today?

Well, we have seen them in the past by accident.

A good example is F2Pool.

Many, many years ago, they accidentally created a block that took,

I think, at the time, like, say, two, three minutes to validate

because they create a very, very big transaction

that, quote-unquote, cleaned up a lot of very small transactions.

Sorry, a lot of small dust, if you will, outputs.

And due to the quadratic signature hashing bug,

in the particular variance that they ran into used to existing core,

that block just took forever to validate.

Now, in that case, that block stayed.

They didn't get re-org'd out by conflicting blocks being found,

so they got lucky there.

But there are quadratic hashing issues that remain

that could be exploited intentionally,

and maybe the Notts guys try to go do this.

Maybe this is part of a PR saying, like, you know,

Bitcoin Core failed to fix these issues.

We fixed it by virtue of the fact that you can't really do much with Notts.

I'm interested to know, we talked about how

the miners would be attracted to the fees,

whichever chain has more fees on it.

Is that what people are talking about when they refer to economic nodes,

that only the economic nodes matter?

Because they would be broadcasting the transactions

that have more fees for the miners?

Well, it's more than that, though.

Economic nodes is also about people willing to buy Bitcoin,

be it worth coins, be it whatever chain it is.

So, as an example, let's suppose I don't personally do many, if any, transactions,

but I'm willing to go buy all of your coinbase outputs

and give you fiat in return.

I, from your point of view, am a very relevant economic node

because you, as a miner, want to earn money,

and I'm willing to go pay you for it.

And my idea of what Bitcoin is is the thing that Bitcoin Core does,

not the thing that Notts does.

So I am making your coins valuable.

Now, it could go the other way.

Maybe someone says, all right, I'm only buying BIP110 coins.

End of story.

Well, a miner who chooses to mine BIP110,

they now have an outlet to go sell their coins.

Of course, the moment I go say I'm willing to buy BIP110 coins,

people who think Core is the way to go,

they can split their coins and then start dumping their supply of BIP110 coins on me,

and now the price goes down.

Now, that's assuming there even is an exchange.

I mean, it's quite a likely outcome of this

is exchanges don't even think this is going to be a thing,

so they don't actually provide a way to sell these coins,

and BIP110 just dies.

Has there been any response from exchanges?

Not that I'm aware of.

I don't pay a ton of attention to exchanges,

so I could certainly miss something,

but this isn't like in the lead-up to SACWIS,

where there were already even futures markets on this

in the sense that you could already pre-trade coins.

Okay, and then my last question I'd like to talk about is,

do the node runners run Bitcoin, or is it the miners?

Depends on what you're talking about,

and I think there's not a simple answer here.

The node runners have power, economic nodes have power,

miners have a type of power,

devs have a type of power,

thought leaders and influencers have a type of power.

There are many different types of power,

and it depends on what kind of thing you're talking about.

And I think BIP110 is a type of thing where node runners,

who are in a minority, who think they have power

because they just choose to go run some software,

will find the hard way they have much less power

than they think they do,

because they're not really part of the economic majority,

they're just a small number of people.

They think they can just kick the miners to the curb,

but unless they get a lot more people adopting this,

there's not much they can really do.

And this is particularly true in a scenario

where hash power just doesn't substantially mine

the BIP110 chain.

In that circumstance, you might get, like I said,

a block a day, and a block a day looks like a chain

that's useless and doesn't work.

An interesting question somebody asked me today,

he was asking about, you know, there's some proposals for BIPs

that seem like, okay, this is so far out there,

away from feasibility, like something like

activating simplicity.

Yeah.

That is like light years away.

And then you have something like check SIG from stat.

Fairness, I believe Liquid just did activate simplicity.

So the code is there, it could be done.

It just needs to be formally verified.

Yeah, well.

And then you have something like check SIG from stack,

which nobody seems to really have a strong opposition to.

And then it seems that the rest of the proposals

have some spectrum in between.

So for all of these different competing BIPs and proposals,

what does the path to consensus look like for activation?

Well, I mean, I did get a soft fork in,

check locked on verify, and my path to consensus there

is to pick something so simple,

you actually could get wide agreement.

And I think the next likely thing that we'll get wide agreement

is the great consensus cleanup.

It's almost everyone agrees it's a good idea,

fixes some issues.

Some people have some opposition to certain things,

some of it on really kind of kooky,

well, we'd rather exploit this bug

to like do this thing on Bitcoin,

but probably it will be uncontroversial enough

that there will be a path forward there.

And since it's uncontroversial,

it's possible the way this gets forward

is you try a minor activated soft fork first,

just on the basis that, look, we can all agree to go do this.

Of course, some people say that's controversial

because it puts miners first.

And that's BIP 54.

I may have my memory wrong, but you're probably right.

It's the one Antoine is working on.

Yeah, that could be right.

There's so many BIPs now, it's hard to remember.

Can you just summarize what is the great consensus cleanup?

So there's two main issues to exploits in Bitcoin

that are reasonably important,

which is the poison blocks issue

where it's roughly being related to quadratic caching.

If you have a really big transaction,

you can hash a lot of data over and over and over again

trying to validate the signatures.

We partially fix some of those issues with signature caches,

and there are ways to bypass that

and create blocks that are just really slow to validate.

The other issue is a time warp attack,

which you can kind of summarize

as it lets you bypass the 10 minutes per block average

and create blocks very close together,

even like seconds apart.

And that A has a problem

that you can mine through all the subsidy quickly.

There's disagreement on how much of a problem that is.

Some people like the idea.

I think what we can widely agree on

is being able to mine blocks that closely together

really screws up Bitcoin coming to consensus

at a technical level.

Because 6 seconds, or whatever the number is,

is so fast that it's hard for the data

to actually propagate around the world

in sufficient time that all miners are mining fairly.

Speed of light is slow.

6 seconds relative to the circumference of the earth

is a lot of time.

It means that a miner with negligible hash power

is going to spend a lot of their time just waiting,

not mining, because they haven't gotten the data.

Whereas a miner with, say, 30% hash power,

well, they're at an advantage

because it's much more likely they're building on their own block.

That's a real problem.

It's interesting to me how you think that

Greikinson's cleanup has such ubiquitous support.

There's no strong opposition to it.

Now we have this soft fork

where there's this big army of people running Bitcoin 10.

They say, haven't you consulted with me first?

Why haven't you asked me what my opinion is first?

What do you think about this scenario

when it comes to soft forks?

Gets the issue of not everyone's voice

is really considered equally.

Like it or not, if you have a big army of people

who we think are advocating for something dumb,

other people aren't going to listen to them.

And you see this in how you don't have a big army of exchanges

saying, yeah, we're certainly going to do Bitcoin 10.

Like, you know, saner economic nodes,

businesses on Bitcoin,

people with a lot of Bitcoin even,

they're not for this.

I mean, hell, even Saylor recently came out

saying he really didn't like Bitcoin 10.

Some people say the thing he wrote,

say he didn't like it, looked AI-generated and whatnot.

But the point is he was able to,

he was willing to come out and say,

yeah, I don't like this.

That's a very strong signal,

even if the way he may have written that

might not have met your standards.

Yeah, he's the biggest public holder

with his identity attached.

Yeah.

Indirect holder.

I mean, obviously it's not actually his coins,

but he's responsible.

It's not his coins and they're not held in his custody

and held through Coinbase.

But it has influence.

I mean, he has economic influence there

and that he ultimately makes decisions

that lead to people actually holding the coins

decide what is or isn't valid.

And, you know, one outcome of this,

hypothetically, could be

Saylor talks to the board of strategy

and they ultimately go tell Coinbase,

yeah, we want to go split the coins

held in storage

and dump them on the Bitcoin 10 markets.

Maybe that crashes price.

Who knows?

So, in summary, in conclusion,

not all actors in Bitcoin

are created equal.

Yep.

And Bitcoin does not

absolutely belong

to the node runners.

Like it or not,

Bitcoin is not a democracy.

Bitcoin is a marketplace.

And marketplaces can look

a little democratic.

Yes, there are, but it's not the same thing

as a, you know, one person,

one vote democracy.

Very good. Thank you.

Thank you.

Thank you.