My fellow clubs River is setting a new standard in
bitcoin@river.com. You'll pay zero fees when you
dollar cost average. Truly the best way to build your
Bitcoin? Well, all Bitcoin at River is
held in secure cold storage with 100% full reserves.
There's no need to wonder what's happening behind the scenes.
Your Bitcoin is your Bitcoin to withdraw at any time.
Additionally, River lets you make Bitcoin payments via the
Lightning Network, offers a Lightning integration for
developers, and allows you to mine Bitcoin directly to your
River account. River has a level of service
that is unheard of in this industry, including phone
support, private client advisors, and the ability to
designate beneficiaries to inherit your Bitcoin wealth.
River has become the premium name in Bitcoin that anyone can
easily. Access.
Sure, you have a place to buy Bitcoin, but have you tried
River? See and feel the difference at
river.com and the River iOS app. The preferred partner of Bitcoin
Magazine. Over the last five years, the
Bitcoin conference has become the world's largest gathering of
bitcoiners. From breaking announcements and
international media coverage to countless meaningful talks by
thought leaders and industry innovators, we are excited to
continue our drive for global hyper bitcoinization.
From July 25th to 27th, 2024, we'll be taking the Bitcoin
Conference to the City of Music and Freedom Nashville, TN.
Join thousands of attendees for countless opportunities to
learn, engage and network across 3 days of pure Bitcoin signal.
Get your tickets now for the best price at B dot TC forward
slash conference. You are not going to want to
miss what Nashville has in store.
How's it going, Shinobi? Doing well?
What's up, Mark? Looking forward to this
conversation. Talking about covenants, Yep,
guess there is just the waiting. Buddy, how we doing?
What's up, Chris? What's up, shinobi?
What's up, Mark? Well, I guess we're waiting for
the autistic. Cabinet a nice, nice lovely
morning over here. Excited to talk covenants with
the homies. Yeah, Mark, I think you might
need to hop off because I don't know if you can hear Shinobi
when he's talking. No.
You might need to just leave and come back.
And I'll. I'll bring you back up on stage.
All right. The Avengers slowly assembling.
Got two more. Yep, I'm inviting Sam.
Super testing that up here. Hopefully Mark will be back in a
minute too. What's up y'all?
Hey Sam. Hey, Moon Settler.
Nice shinobi. Aloha.
Hello guys. How's it going everyone?
Mark, you're back. Hopefully you can hear everyone
now. I can, I think.
Can you hear Moon Settler? I haven't heard Shinobi yet, but
it's up Super Test net. What up, Sam?
How's everybody doing? So good, thank you for asking.
Just wonderful. What a, what a, what a group of
people this is. This is the spaces I've been
really, really, really excited about for a while and I am a bit
over my head on a lot of these things.
So I'm excited to learn from you guys about all this stuff.
So been following you guys for a while and I think more people
should. Pay attention to what you guys
are talking about. So excited to have you guys.
Yeah, I'm what you want to call it.
Chris, if you could invite Reardon up, he he was a maybe.
I see him working down there though.
Yep, just tossed him an invite and looking for, I think anyone
else that's coming in last minute here.
All right, at this point, I think we are just waiting for
Polly Ed, who might pop in late, and Robin to stop his autistic
spasming in the in front of a. Shinobi, you want to take it
away? Maybe we'll do some brief
introductions and then we can dive into it.
Yeah, I guess before I go on the long winded framing ramble,
everybody kind of want to introduce themselves, tell
everybody what they're working on, if they're working on
anything. I guess we can start with you,
Sam. Yo, hey guys.
I am a fur researcher guy who among other things, that was
part of the kind of group of people that were thinking about
how to hack Zero knowledge prover into Bitcoin that
eventually led to Robin's discovery of Bit VM.
In general, my day job is inventing product specs for
weird. Experimental type of protocols
like bit BM but for shit coin projects but at the end of the
day like all I want is to to scrape all the the good research
and and bring it back to Bitcoin.
Here here Mark. Oh, hi.
Yeah, hello. I do writing and you know, do
some editorial stuff for Bitcoin Magazine.
And yeah, in general I think my like first big break from, I
would say the echo chamber discourse of Bitcoin was
watching. You know, the bit 119 stuff kind
of happened and and. You know, being, you know,
getting covenants explained to me seemingly like a really great
idea that would be pretty much good for everybody for pretty
much every reason. And then kind of seeing a lot of
people push back against it was, you know, a big part of my kind
of, you know, break to the echo chamber and yeah, I I'm
interested in covenants greatly. I think that they're very
important for, you know, keeping Bitcoin basically as permission
lesson and as accessible for the next billion people as it was
for us, you know, people the last few years.
So yeah, excited to learn more about it and be here with you
guys. Super Tesla.
Hi guys I am a free and open source software developer
focused on primarily Bitcoin, the Lightning Network, and most
recently Noster. And some of the most of what I
do is come up with cool new ideas and then proofs of concept
that they are actually possible in code.
And so that's what I do. And moon.
Oh, do we still have you, Moon? The moon is gone or moon has
been taken from us. That's no moon.
Or is it a space station? When you are the moon.
All right. Well, well, Moon diagnosis that,
I guess. Someone go out there and lasso
the moon for us. Sorry guys, I couldn't speak.
There we go. So hello guys.
I'm Moon Settler and I she was on Twitter about scaling Bitcoin
and privacy covenant stuff and blind store and stuff like this
already. So I guess time for the long
winded framing rant from shinobi.
So covenants are the the thing that bitcoiners have been
obsessing about for the last couple years.
At this point, I still feel like a lot of people are very
confused when they hear that word about what that means, just
because of how broad of a topic it is.
So to start, I think the best place to begin would be just
thinking about what is Bitcoin Script right now?
And it it's essentially just a very small language where you
can write programs to lock coins that exist right now so that the
only way to spend those coins is fulfill the condition of that
program. Like for instance, the simplest
example of that is just. Here is a public key provide me
with a signature that validates against this public key.
And so the the entire purpose and point of Bitcoin script is
to define what conditions you have to meet to spend coins that
exist right now. So what covenants want to do is
expand what script is capable of doing from just restricting
coins that exist right now to restricting coins that don't
exist that are yet to be actually created on chain.
So that the conditions you put in a script for a coin that
exists now actually have some degree of control to restrict
coins that will be created when you spend that coin.
Also real quick Robin, if you could request the host is having
trouble you finding or finding you down in the listener, but so
like that's the most general definition there is for a
covenant. It's just some script, some
primitive in Bitcoin that extends the ability to restrict
coins being spent from coins that exist right now in the UTXO
set. 2 coins that haven't been created and added to the UTXO
set yet. And so that is a really, really
open-ended and kind of a vague potential like that that could
be literally almost anything like that could be these coins
can only be spent if the government authority lets you.
Or these coins can only be spent for the rest of eternity, once a
month. And any coin that descends from
it is forever encumbered by those same conditions.
And so that's that can be a very scary thing when people just
hear covenants and think the most general type of
restrictions like that. But they can also be incredibly
simple things, just like this coin has to be spent to this
address just once. So you just have a simple
covenant that applies to 1 UTXO that exists right now.
And all it does is for one time, it just requires that that coin
be spent to a specific place, and after that, that coin can be
spent to wherever the owner wants to spend it after that.
So you have this vast spectrum of like just super simple, not
really dangerous or expansive restrictions that you can place
on future coins to the open-ended like whatever, like
your head could come up with. And that is a massive design
space. But at the same time, everything
that we're doing in Bitcoin in terms of solving problems like
scalability, like privacy, all of the problems in making those
solutions we, we're implementing work keep coming back to
covenants. And so I think the whole
question here is what is the bare minimum type of covenant to
address problems in our scaling road map and what are the
implications of that? And so I guess you know from
here I might try to rein in the autism and ask for
clarifications. If you guys start going in a
direction that might be a bit too over everybody's heads.
But I think you know the to start off like what are you,
what are your guys thoughts? Just open question to everybody
about like how far should we try to take the capabilities of a
covenant just to get the first simple covenant to try to solve
the problems of stuff like lightning or systems being built
right now, you know, open floor? I'm a big fan of OP CTV Check
template verify and one of the reasons why I like it is that
there are a couple of things that I know how to build once we
have it, and two of them are, I know that it's it seems to me
that it's a lot easier to build arc if you if you have CTV.
And similarly, it's a lot easier to build channel factories for
lightning. So those are two things that I'd
like to really I'd like to get started on.
And CTV would make them easier. One of the reasons it does that
is because CTV allows you to get a guarantee that if you put
coins into address A, you'll get the same amount of coins back
later. No one, no one can like take
them from you. And address A can be controlled
by a lot of people. It can be, It can be.
It can have payouts for A for a number of people.
It enables something called payment pools where a bunch of
people put money into address A and they know that when they're
done using it, they'll get the same amount back out of address
A. So I really want that.
And that enables a couple of cool things.
So, yeah, that's that's one of one of the things I'm a fan of.
All right. So real, real quick kind of a
question to go with that just for listeners like why is that
something that we need CTV for? Like why couldn't we do that now
just using pre signed transactions or like the scripts
that we have available right? Now well you can do it with pre
signed transactions, but it limits the number of people who
can be involved and it increases the expense.
So when you do pre signed transactions you either have to
add every public key who's going to be in control of this Bitcoin
address. On into the into the address.
And so when you want to spend it, you've got to have like 50
public keys in there. That's pretty expensive.
For every public key you need a signature.
It adds up quickly. You have a lot of data that you
have to put on the blockchain in order to do that, increasing the
expense for everyone. And the other thing you can do
is you can do it off chain using using MUSIC or FROST.
But that increases the computational the amount of
computation that you have to do, and it also increases the the
online time of everybody. Everyone who's involved in that
address has to be online at the same time.
Well, not necessarily at the same time, but they have, they
all have to get online in order to coordinate what they want to
do with this address and any changes they make to it.
They all have to come online to say all right, it's time to do
everyone's payouts or whatever in order to change the payout
structure. That kind of sucks.
And with CTV you limit the, you limit that you you make it so
that you only have a a normal sized address, normal sized
transactions and the process for modifying what it does is a lot
simpler. Not not everyone has to be
online at the same time. So that that makes everything a
lot easier. And and it makes it scale
better. It makes it so you can have
thousands of people instead of just dozens.
Yeah, I mean, you got something to say?
Yeah, so I wanted to add that with Music and Frost and stuff
like that, with this easy small signature aggregations, we no
longer really have the problem with the blockchain space
utilization because everything could look like a single signal.
That's pretty efficient, but the interactivity requirements are
still there and. If you want to allow for a
flexible fee schedule without covenants, you can't really do
more than one hope with pre signed transactions.
After that, if the transaction IDs are not predictable to you,
then those signatures are basically unusable.
So we have this problem of creating longer chains where we
want the ability for people to odd fees according to a future,
you know, fee market and not have to suffer with the child
pay for parent outputs and stuff like that.
Basically want to allow that anyone who executes from a large
set of people, anyone who executes that contract, is
actually paying the fee if he's opting out of cooperation.
And he has to bear the cost you know and stuff like that.
So so it just it just makes the whole thing more practical and
and more implementable for a lot of cases and like you you you
can you can better do certain relative time lock situations
like that again with with flexible fees and and not having
to worry about the transaction ID more liability.
So that's that's kind of where I would put the the emphasis and I
would like to say that I I personally think the minimum
said that we should be thinking about these these check check
complete verify CTV plus check seek from stack CSFS.
So the two together enables like very, very flexible, very clever
ways to to exit. Directly with the operator from
payment pools, it gives us LS symmetry which is also high
value use case to many people. And so basically basically it's
not something where we would not be able to properly reason about
the possibilities that it opens up and it just gives us like the
building blocks for. You know, getting started on
this part, yeah. So just to, you know, sum up for
everybody listening. So CTV is essentially something
that lets you make a bunch of pre signed transactions, except
once the first one confirms the rest of them are not double
spendable. So like once you start spending
that chain of transactions, you have to follow through all the
way to the end by consensus and then check sig from stack is
something that the when a signature gets checked in the
Bitcoin script system, right now it only gets checked against the
transaction itself. Check sig from stack would allow
you to check a signature against any random piece of data, so
like just part of a transaction or some arbitrary value from an
Oracle and things like that. And also Robin, I don't know if
you missed it, but we're kind of going through like what is the
bare minimum degree of covenant functionality that people think
we should start with. So if you have any thoughts in
that regard, welcome to chime in.
Yeah. If if you wanna go for the bare
minimum, that's I think obviously CTV because that's
what CTV is designed for, to be the bare minimum of covenants
that we could have. And I guess, Sam, you got any
thoughts to chime in here? I mean, yeah, if someone is, if
someone has an idea of how to make a more conservative
covenant scheme than CTV, I'd love to see it.
But yeah, I think that. That that maybe we should start
arguing about whether we necessarily need that level of
of conservatism. Like, how important is it to
absolutely prevent the kind of infinitely recursive
restrictions that, you know, we're, we're worried about at
the protocol level, knowing full well that those kind of
restrictions are and. That can be enforced at the
level of, you know, physical violence, etcetera.
All right. So I guess the next one I'll
toss out again to the floor, open to anybody.
I think this is kind of really where a lot of users and people
paying attention in the space kind of just get lost on this
whole topic. But like what are some of the
problems? That we face right now that are
really difficult if not impossible to solve without some
form of covenant. You know, like shortcomings or
issues with things like lightning or side chains or
systems like FIT BM. Just like where where are the
limits of all of those types of system and the problems they're
running into that covenants would really help address where
nothing else can really solve that.
Yeah. Well I I was thinking about this
a lot recently and I think that one of if not the biggest core
problem to scale that we that we need to solve right now is is
guaranteeing settlement of of like exit transactions, right.
Because it it's seeming that like you look at lightning, you
look at our, you look at bit VM, you know assuming that we're not
ever going to have op ZK verify on Bitcoin, that kind of
restricts us to these optimistic protocols.
And the way the optimistic protocol works is like you're
assuming that someone is following some rules, but if
they don't, then you're able to exit somehow and either, you
know, do a fraud proof or just just get out of the system in
time for you to not, you know, be damaged by them acting
maliciously. And and and that's great.
These these systems are like absurdly efficient in basically
every way. But but the problem that this
keeps running into is like, well, you you can't, you can't
guarantee that you're going to be able to get your day in court
on the L1 in time before you know the expiration window for
these kind of fraud proofs expire.
So one of the things, one of the big things that I think we need
like something to to enable we've argued about this before.
I don't think you can do this with just getting with just
clever like interactivity schemes is you just need to have
some kind of way to guarantee that if you need to exit from an
optimistic protocol, you need to do a fraud proof, whatever that
that's going to get settled. Whether that means, you know, a
side chain or whether that means some kinds of clever, you know,
like congestion control batching scheme whereby you know, oh, I
have a fraud proof for a very small amount you're sending a
transaction on chain anyway, you can kind of aggregate that into
yours without bearing, you know, much more cost for yourself.
And now I'm getting settled. I think that that that is kind
of a very big high level problem that that something like
covenants is probably the only way to solve.
But you know, I could never say never.
OK, really, really quick before you moon settler.
So what what you're saying Sam, is like if if multiple people.
Have to take something like lightning closure transactions
on chain. Like right now there's no way to
save block space by just combining those, not without
everybody having to be online at the same time and talk to each
other. And if we had a way to combine
those without everyone being online at the same time, like
that would be a huge efficiency gain for 2nd layers that have to
do that. Yeah, it's not even efficiency.
It's just like allowing them to actually be secure like
lightning. Plus like, you know, stuff that
looks like arc, like you look at that, you can just see how that
actually does scale to literal world scale.
The only kind of flying the ointment there is like, well,
you know, what if you would need to do a fraud proof for an
amount that isn't worth the block space?
What if, you know there's some kind of massive attack just
within the rolling window for the being able to do a fraud,
proof these kinds of things. Yeah, I just wanted to add that
I know there are tricks that you can do with check sync from
stack and maybe a lot of people don't even understand what's the
point in signing some random data.
Well, we checked and verified. The obvious answer is that you
can actually. Like sign a CTV template hash
and that means that you can sign a certain output distribution.
And the way I think about this is basically deferred
authorization. So you are giving someone a
deferred authorization to spend, so that may or may not exist
yet. So the best part of that?
Is that you can actually give him an authorization to spend
UTX so that does not exist yet and you don't know the
transaction ID that it will have.
Like this is the absolute best part about it.
You can do that with pre signed transaction.
Basically it's impossible to do that.
But with checks from stack and CTV you can do these
authorizations. By the way, hash locks are a
certain type of these. Deferred authors that are
technically like normal label, but you cannot actually like
rest the outputs. That only works on the input
part. So with the check table, verify
and check from step, you can actually give someone a deferred
authorization to spend a future UTX so that he knows how to
create in a certain way, and you can keep giving him these
authorizations and let him take the one that is the most.
The most beneficial to him. So basically this is the basis
of more interactive channels. You can create lightning
channels and you can show to someone that there is nothing up
your sleeve and you are giving him this authorization and he
will be able to spend it and you can keep giving him like better
versions of it and he can have like a single sig on that.
So in case you have. Like a covenant pool operator
and you have a lot of participants in the covenant
pool and some of them are not responsive, then you can without
taking these virtual Utxos on chain, you can basically just
start giving the pool operator these deferred authorizations
and in return he can basically I don't know how to say it, he can
basically help you get out. Have you spend without the
cooperation of the others? You create an all interaction,
everything and you are able to spend over the lightning
network. And others may come online later
and maybe they update the state or maybe they just, you know,
everyone exits on their own and the new pool is created.
So it gives a lot more flexibility and a lot more the
ability to cover on pool designs that are not.
And don't have this compromise that ARC choose to have with the
time lock sweep. So with the time lock sweep, we
know that technically, as was said before, if if people cannot
enforce their property rights on chain for whatever reason, then
the pool operator is is able to basically steal from people.
And that's kind of the the main downside of the design, but also
what makes it. Sort of work from the ASP's
perspective because he knows he will get his liquidity back in a
certain time frame. And basically this is the
compromise that you don't necessarily have to make if you
have checks from stack and you can do these deferred
authorizations for specific settlements, because then you
can. Like I said, create lighting
channels that never existed because once you spend them you
can just give the give your private key the pool operator
basically give up your private key and he can compose the the
settlement chain at the higher level, even even maybe back to
the route if everyone just exits the pool 1 by 1 unilaterally
they I mean the help of the operator, they just exit.
Then basically the pool operator, we have all the
private keys for the large end of music, for example the keypad
on the taproot output. And then he can just take the
whole thing very very very efficiently.
So this whole idea that the CTV settlementary has to be unfolded
on chain just goes away. And I think that's a very
powerful thing and we should definitely coincidental and talk
about that because I don't think the downsides that are imagined
justify being overly careful around check signal phone stick.
OK, so I'm try my best to succinctly put that so the one
of the problems at least is. Something like a a lightning
channel, like you are just spending as you unfurl things
like previous transactions. And so with SegWit, like the
transaction malleability is not a problem in the sense that
somebody else can just see your transaction and change it and
then break future transaction spending from that, but the
participants still can't. Like if if somebody involved in
the channel adds a new input to pay fees because the fees were
too low and it's not confirming that changes the transaction ID
which breaks anything spending from it in future.
So it's really difficult to have more than one or two hops
involved there. The the other issue you kind of
wanted to. Is the cost of actually taking
that data and unfurling it on chain and kind of the solution
that you were getting at is where you can apply a signature
to any arbitrary data that allows you to change the
spending conditions of a coin without actually spending that
coin. So if there is a UTXOI can make
a script that just says. Use check sig from stack and
check against this key and then I can actually just add any
script to that later after the fact.
And as long as I sign that script with that key, What
somebody can do is then put the script with the signature on it
on the stack it will verify against the public key that's
actually in the UTXO script. And then this whole new script
that was never part of that UTXO that gets checked and as long as
that pass is valid you, you can just keep adding new ways to
spend a coin without ever actually moving that coin.
And so that adds a lot of flexibility to what you can do
off chain. I get that right?
Yes. Although in my example and with
CTV, I don't think you can just only add like new distributions,
so you can keep updating the distributions.
Someone can imagine that if Lightning China can only go from
Alice to Bob and never backwards, then Alice can just
give updated signatures to Bob with new and new templates for
Checked Amplify that changes the distribution between them
towards Bob. And Bob has to do nothing else
but sign a transaction that that spends this with the one that is
most beneficial to him. So Alice does not really have a
way to screw Bob over in in this setup, and Bob has no way to
steal from Alice any amount that she did not forfeit to him.
So the whole thing is perfectly fair and secure.
And basically, Bob only has that.
Maybe he loses the best state that he had, but that is a
technical problem that is solvable, and it's not something
that Lightning does not suffer from and whatnot.
So this is what's called non interactive channel.
And the best way is that Alice can open this non interactive
channel without even cooperating with Bob.
So she can just open it and show everything to Bob and Bob can
verify that this is indeed a proper non interactive channel.
And this can happen like in a way where this channel is
created at the end of a long tail of CTV transactions and.
So that that's kind of the way to think about in in this regard
that it just gives you a delayed authorization, A deferred
authorization to spend otherwise and that opens up a lot of
possibilities on how to how to proceed or how to compose these
things. I guess Robin or super, do you
either of you have any like concrete problem or limitation?
With something existing now that would be solved with covenants.
Yeah, if I should speak for bit VM, like there is that setup
phase where you have to set up the transactions that you can
execute in case there's fraud and yeah, or like the
transactions that you can execute as as to perform the
fraud proof and currently you have to set them up
interactively. And in particular in that multi
verifier setting where you have like a single prover
facilitating a bridge for example and lots of verifiers
verifying them. In that setting, every verifier
has to verify the setup of every other verifier, and of course
that's case pulley and if we had covenants, if we had CTV for
example, the the prover could set it up and it could set it up
for everyone non interactively. And OK I I'm confusing myself
here they still everybody has to verify the setup of everybody
else but they don't have to Co sign the setup of everybody else
without covenants. You you have to Co you have to
pre sign the the sequence of transactions and in the multi
verifier setting every verifier has to Co sign the pre sign
transactions of every other verifier and that's gates very
poorly. They still have to verify the
setup of each of all other verifiers, but yeah then you can
essentially compress all of that into a ZKP and then it becomes
no problem to verify the setup of the other verifiers.
So the the the the essential part that you can get rid of is
the pre signing and I think there are many protocols where
you have like. Yeah, lots of things that could
happen and you have to pre sign them all and if you had some
kind of covenants, then yeah, you could get rid of this pre
signing and just replace it with them some.
Yeah, some template. All right.
And the. VM real quick is is far beyond
the scope of this, so there there's an article I claim
magazine to read about that, but the gist of what you're saying
is in context. Bit VM requires like potentially
millions or billions of of pre signed transactions to be made
and So what you can do is cut out like the back and forth part
of that. Like you still have to make
them, but instead of each step involving going back and forth
between everyone involved, like somebody can just make them all
at once, Send them all at once. And the other people can verify
them all at once instead of all the back and forth between
everybody. Yeah exactly.
And that is very similar to the problem that they have at ARC.
Like in ARC you also have that problem that yeah you have that
non cooperative case and in that non cooperative case you have
these exit trees and people have to pre sign them all together
for these exit trees to be trustless.
And yeah, you can get rid of that with CTV.
And I wanted to say that I think in general, of all the proposals
that are currently discussed, I would say CTV is the most simple
proposal that enables the most powerful things next to OPCAT,
of course, but. Yes, opcat definitely takes.
But like of the of the of the proposals where everybody is
like, yeah, this, this is very simple.
And that has no side effects at all that.
Yeah, you. Have to, you have to say that it
is also the the least risky, right?
So if you say, oh, you lost Robin.
So if if if you say that CTV is basically the best risk benefit
move that we can make at this point in Bitcoin's history, then
I don't think anyone is able to argue with that on a technical
level. And when we are talking about
the simplest that's most powerful, then to my knowledge
that is of CED because it's like 10 lines of code and it enables
like almost everything. Oh yes, super.
Did you have any, like, specific problems in mind we haven't gone
over already? That would be drastically easier
to solve if we had some form of covenant.
Yeah, lightning, lightning, the lighting network could benefit
from covenants as well. One of the things that you have
to do in the Lightning Network is save a lot of state, which
is, which has to do with the fact that you're in a
relationship with someone on the Lightning Network.
You you always have a channel partner, someone who you open to
Channel 2 or who opened a channel to you.
And every time you make a payment on Lightning, you're
creating a new Bitcoin transaction and you're
revealing. You're typically revealing
something called a revocation key for the previous state.
So every time you make one of these Lightning payment you have
to store. The old, every old transaction
of every old state in your in your channel as well as the
revocation key given by your counterparty or that you gave.
And that's a lot of data to store it, especially for routing
nodes, it really adds up sometimes they have, you know
gigabytes of of data that they have to store.
But if we had covenants, we could make it a constant size.
We could make it like, you know, you only have to store one MB of
data. And and then ever like it
increases after that. So that's another area where I
think that you could make it a lot less intrusive or or less
difficult to run a lightning node.
You could make the software a lot simpler in the database, a
lot smaller if we had covenants. I think, I think that's an
interesting, an interesting point to kind of discuss like
the difference of you know, I would say you know it's it's a,
it's a. Basically a fact that there's
more funding and broad support for you know, development and
advancement with Lightning and you know even I guess at this
point even like tokens on Bitcoin but like not necessarily
for covenant support that's that's not as much of A of a,
you know, mass saturated thought.
So I'm kind of curious to you guys like what, what is kind of
missing you know based on these you know kind of solutions that
covenants can provide to these issues you guys just brought up
especially with some of them like Lightning being you know
having a big application to you know presumably the next billion
users. You know what, what is the
missing? What kind of element of of
education and the communications that we can give to the masses
like for why this is important and why they should care and and
be supportive of, you know, whatever their iteration of
covenant that that, that, that they want like what?
What is kind of missing to get that sort of mass acceptance?
Yeah, one thing that is worth noting is that the lightning
network works like even without the lens symmetry it it just
works. And with splicing temperatures
and splicing you going to get a free pruning of your channel
state anyhow. So I don't think professional
nodes we have any problem with this whatsoever.
So the main benefit to Allen's symmetry is US super said it is
going to possibly make the lightning developers job a lot
easier. They can make simpler and more
robust nodes. So that's like the main benefit.
That benefit to the users is going to be basically non
existent As for a second. So LS symmetry does not actually
deliver anything to the billions directly.
What actually is something that covenants can help us with is
that the Lightning network is severely limited in the number
of participants with the Avon throughput the block space that
is available for us. And that is the big point where
all these covenant pools and channel factories and.
Not even sure why we are calling them in different news because
it pretty much looks like that any channel factory will be
somewhat of a covenant pool and every covenant pool will be like
a channel factory on demand or or opportunistically or
whatever. So I I kind of think the two
concepts are are going to. Like converge into a hybrid
thing and and that is like where we see a very clear need of
covenants for for for that to work.
OK so So what you're you're saying is like just we we we
kind of need to stay ahead of like keeping the limitations of
lightning in mind so that like the the small changes and
optimizations we can make right now without.
Like forking or adding anything to Bitcoin that just give us a
little more breathing room. Don't come across like they're
fundamentally solving the issue to the same degree.
Yes, and and and the like. There is another point that you
could make about all this I guess is that you know the pay,
Polish and and SMTP vacation of the lightning network.
It's something that we are seeing in real time happening
and that's not the vision that originally.
Really quick, Can you just, like, explain what that means
for people who maybe don't know the history of both of those
protocols? Yeah, so lightning was
envisioned like that anyone can run a server and connect to this
network and it will be a lot more mesh like and less.
Providers like Skype, PayPal, Google, whatever.
So these giant providers operating with each other in a
more closed, more permission network.
How the SMPP protocol turned out and basically turned the whole
thing into a hub and spoke model that you are.
Completely exposed to your hub you have no privacy against your
hub because they see everything they report to chain on all and
things that you do anyhow and to each other and and basically we
can we can get into this this state with the Lightning
Network. There is a very, very strong
much of A tendency for, for centralization, for for, you
know, the optimization of this whole thing and so.
That is kind of where I see like a big danger because you know
that especially custodial lightning in this set rise form
we are scared to billions. But that is not the network that
one can say it's a peer-to-peer network or anything.
So that's why I say the pay qualification and SMTP
ification, because the SMTP protocol started out a lot more
peer-to-peer. But eventually with the spam and
these giant providers, you know, trying to combat it, it became
something where you can't really have your own SMTP server
anymore and and have people be able to send you emails or
you'll be able to send anyone emails.
You know you have to have an account with one of the large
providers and it has become very permission and you are very
easily denied access to this. This protocol, so to speak, in
practice, even though in theory anyone could run the software
right, but it just doesn't doesn't actually work.
You won't be able to send an e-mail to someone else like
that. Well, I guess I'm going to take
the spotlight for a second and jump in with a big problem I
see, because I think it relates to that pretty well.
You know, the more we look at lightning as it is now, like
Moon said, it keeps. Gravitating towards big central
nodes like a lightning service provider, and honestly a lot of
the most practical basic types of coin pools or channel
factories that there are very concrete designs for that we
could do if we had covenants actually kind of lean into that
dependence on something like an LSP.
Like they're explicitly designed around counting on that.
And I think one of the big problems that that has caused
that is the problem of how do you exit from something like an
off chain channel that has more than two people involved.
Because the general way that's done is just a long series of
transactions where one UTXO breaks into two.
And each of those break into two and each of those break into two
until eventually the UTXO is on chain are actually somebody's
lightning channels. And you have to go through all
of those steps in between to get to somebody's lightning channel
going on. Well, like there are covenant
proposals like tap, tap, weave, update, Verify T Love building
on top of Taproot that offer a more efficient way to do that.
Where you actually have in like the Tap Leaf script, some script
that enforces that in one transaction, even if there's a
hundred people or 1000 people in in this UTXO, one transaction
enforces that you are allowed to take whatever money you own in
the current state and spend it wherever you want everybody
else's money. Has to go back into a specific
output with a specific script, which is that like taproot multi
sig with everybody involved minus just your key.
And it actually enforces all of that.
It actually checks the tap leaf, it looks at the amounts in
there, it makes sure the right amount goes back to the script
with everybody else's money and it actually verifies that the
public key for that output is the pre-existing like taproot
multi sig just minus the key of the guy who left.
And so it can take that whole chain of of a shit ton of
transactions that has to unfurl on chain.
And turns it into just one transaction and that capability
is exactly what we need to build multi party channels like that
that don't require being built around like some service
provider and like those designs they're they're not trusted.
You still can't enforce things without that provider
cooperating. But the whole design is still
built around them. Whereas if we had a covenant
that would just let anybody in a single transaction pull their
money out and leave everyone else to do whatever they want.
Or the opposite allowed everybody to kick out the one
guy who won't get online to sign stuff in one transaction and
everyone else goes on with their day and like that type of
functionality? Is something necessary to do
things like coin pools or channel factories in a way that
doesn't revolve around some like service provider that is
necessary to make it all work? I think it's it's it's worth
mentioning that everyone that dug into this problem space
knows that the the denial of service.
Potential for for any any multi sequel is going to go very hard
up with the number of participants and not necessarily
intentional. So like like the sheer
possibility for an error for someone to to to suffer no error
is just going to go up hard after a certain point, so.
Basically kicking someone out without stealing their money, so
enforcing that property right just putting them out of the
pool is something pretty fundamental that should be
taught about, and ARC is actually sidestepping this whole
issue. So with there if if you like
experience no other wallet failure then the mean the the
ARC service provider we are simply sweep your virtual Utah
and that's basically is going to turn them into IOU's.
So either he honors your claim, then you can, can, you know,
show your keys and prove your keys to those virtual Utah
excessively, either under them or not that that's up to him at
the point if they are stopped. So yes, this is a very big
problem. And the other issue is that when
you just imagine this scaled up to like billions of people,
let's not say 8 billion people, because I think it would be more
than enough if every household had an old or something like
that. So we shouldn't go beyond like 3
billion or something like that in our imaginings?
So if you imagine that like 3 billion nodes are trying to do
these this cooperative pools, the mod still does not work out
for even very optimistic on chain settlement if if these
these unilateral exits like keep happening.
I just wanted to know that. So I don't think that schemes
that are trying to enforce cooperation like they they are
forcing people to cooperate. Are not necessarily garbage.
I think they should be explored because that that kind of has
this benefit that if people are are are kind of forced to
cooperate, then then they will, you know, they will find a way
to make it more efficient because it's actually in
everyone's interest to to have a more efficient settlement so
long nobody can steal from the other, you know, That's just my
thought on this. And Sam, it looked like you had
something to say. Yeah, well this is.
We've talked about this before, but this is the reason why I
love ARC is it It doesn't have the the the data availability
problems that basically all other forms of like UTXO multi
sig aggregation schemes have, which is like they're always
some version of. Hey guys, I'm going to aggregate
all of your UTXOS into some Merkel, something that looks
like a Merkel tree on chain. I'm going to publish the route.
But what if you give me your your UTXO and I don't give you
your inclusion proof from your TXO to the root?
I can't steal your coins, but I've kind of burned them if I
don't give that to you. And I can certainly hold them
hostage for, like, you know, some.
You know, like 30% of their value or or something like that.
Unless you get really clever. And the ways in which you can
get really clever are you can have like massive interaction
schemes that scale extremely poorly, like n ^2 in the number
of participants, or you can have something like a side chain.
Where you know you're posting your UTXOS on the side chain and
they're Merkel eyes up to the root that goes on the L1 kind of
from that side chain. And so everyone can compute
their own inclusion proof from the data available on that side
chain. This is kind of the main reason
why I've slowly become a side chain apologist is I don't see a
better solution to that particular problem than this.
But the thing that kind of gives me pause as to whether that's
100% necessary is ARC. The way that arc works, it
sidesteps that because of what you just said Moon, that the the
way the interaction there works, it's it's like eeny meeny miney
MO. And rather than the MO landing
on the like the authority and like now they're the one that
gets to go to chain. The MO ends in the user and it's
like the the thing goes through. Atomic with the user's final
action, not with the, the service provider.
And so you don't have this kind of, you know, OK you're you're
the final executor now please give me my witness because
you're the one that's kind of generating that with that
clinical witness yourself. So yeah, if if we can figure out
a way of kind of having a cake and eating it too in that
regard. Even with things like like T
love, I think still requires solving this problem.
That would be cool. I guess what, sorry, but welcome
Trevor, might be a little out of stuff, but I guess just to try
and catch you up real quick, we kind of for the first bit just
went through the nature of covenants and the difference
between restricting the spending conditions of future coins
versus ones that exist. And we've kind of just been
going through like specific scalability problems with things
like lightning or side chains and other layers that covenants
would help. So I don't know if you if you
have any thoughts on that matter and I guess if we've gone
through it, I'll let you know. Yeah.
No, I I definitely have some thoughts on it.
I mean, I think, I think that covenants to me seem like a type
of protocol change that. Is one that if you don't use it
it, it won't really affect you. I think you know we always
struggle with like these changes to Bitcoin because as opposed to
like normal software development, like once you
introduce a feature like you can't really take it out right?
Like the majority of the software development world you
know, USE has many best practices for AB testing and
feature flags and different things to like.
Implement a new feature and test it out on a certain percent of
the population. Figure out if it's valuable and
then and then implement it right or then roll it out.
We can't, we obviously we can't really do that with Bitcoin and
so it makes development much harder.
And you know, This is why, you know we have to be careful of
course because we don't want to interest bloat to the protocol.
We don't want to mess up anyone's funds and bitcoins core
value proposition is it's. That it changes very slowly and
it's a it's a safe haven as opposed to the kind of Wild West
of other blocks. And I think that you know
covenants to me seem like the time is really right for them.
I think that people have kind of come around to it more and it's
really a question of various implementations and and where to
start because you know, covenants are essentially more
of a category than a specific feature.
I love what of course like Robin is doing with with bid VM and I
think that you know introduces a lot of alternative ways to
implement potential covenants that might also you know,
depending on Robin's development and his team's progress like can
help show if there's value, you know, like if there's a certain
covenant that we want you know the ideal way.
Would be to sort of follow the path of like what ordinals did
if it's feasible, which is like to implement it in an an
alternative way that can show what the adoption is, you know.
So for for covenants though, I think it's also a change as
opposed to like you know to drive chains like there's a lot
of, there's a lot of product discussion is like, well, if you
don't use it then you know it's not going to affect you kind of
a thing and I don't know that it's.
The case with with drive chains but seems to be the case with
with CTV. And you know I think that this
this larger discussion about you know classification and
categorization of potential changes and and whether or not
they introduce or they will affect users who don't use it.
And what the implications of that are going to be as part of
the. The real crux of where the
discussion should be is you know.
If some if you know how much blow does it 'cause you know
could could there be a scenario where there is a trial period
for something where it's like you give it a year and if it
doesn't reach a certain threshold you you roll it back
and it's just agreed upon by the community in advance.
You know we're we're definitely entering a period where I think
in the next cycle Bitcoin is going to grow even larger.
There's going to be even more demand for users.
We see the. You know inflation and what's
happening with interest rates and and in the Middle East is
causing Bitcoin to break away from the you know being traded
like a a bit high beta of a tech stock and sort of going the
opposite way of the market and maybe a new narrative forming
and that could lead to significantly more users coming
on. And so we definitely have to
step up our game in terms of the the nuance and and how we
execute in introducing these features which we may need, you
know, to add. ZK roll ups in the future or to
add other scalability solutions. I think we need to try as many
things as possible with while being conservative and not
messing up what we have today. Moving You got something to say?
Yeah, yeah. Just quickly, I wanted to say
that it is always worth, you know, examining these claims
that only the people who opt in to use them will be affected.
And it is there is no way for others to be negatively
effective. So obviously in the end after
after like the the, the basic you know the the rudimentary
like how do you say this like due diligence is done by the
developer committee it is actually on the detractors the
opponents of a software to to prove that it can you know harm
the network and and users will be not obtained.
But for example, recently there has been talks about
reactivating cat or cat, and we know it is relatively harmless
in the sense of resource consumption because stick items
are limited in 520 bytes if I remember correctly.
And the people realize that this also limits what opcat can be
used for in terms of, you know, funny, fun developer things.
And so a proposal was made that you should actually multiply
that 520 times with the maximum number of stack items.
So the total amount of stack memory that you can use with top
cat would still be limited, but you could actually create like a
520 KB size strings at maximum. And the problem with that is it
actually it opt get you can very quickly reach that size and it
opens up a quadratic hashing talk.
I'm not sure if my calculations are completely correct, but I
got something like it would take 11 hours for a Raspberry Pi 4 to
verify a block specifically constructed to deny service to
the Bitcoin network. So.
We have to be kind of you know, vigilant about this and think
these things too. I'm not trying to fought
covenants. I think covenants are super
important and I'm not sure on the next step for this, but
obviously we cannot like get carried away and claim that that
nobody will be harmed by anything unless they use it.
We have to actually examine these claims with each and every
proposal. And certainly the way things are
in Bitcoin and script, you actually kind of have to take
into account how multiple, of course multiple proposals
interact with each other. I think she know be likes to
rant about this a lot, that it's not enough to just look at
something in isolation. For example, opcat can do a lot
of very fun and interesting things.
For example you can actually it looks like you can implement the
finite state machines in Bitcoin script that can change state and
stick to a contract or program if you wish.
With these States and one transaction at the time you can
update the state and you can do this.
But for example with taproot you can't really do that because you
would need optic verify. Known from liquid elements
script. You would need optic verify to
actually verify that assembled test script output address so to
speak and so opcat with taproot would not really work in this
way, but so stuff like this I think.
We need to, like spend a lot of time collectively on exporting
these limitations and possibilities and not be too
fearful, but but always have in our mind that how could this be
used as a denial of service attack on people who do not use
it? Because that's like the first
thing that you have to ensure that it cannot.
That's the absolute basic your proposal cannot, cannot go
through. If you cannot, you know, like
reassure everyone. That that it is reasonably safe
and the CTV has been around the block for years and then the lot
of very small people have looked at it for a very long time and
and so far I'm not aware of anyone being able to find
anything any such thing. If anything, if CTV was heavily
used it would actually speed up block validation significantly
because it's a much cheaper operation than like a signature
check. So please sign transactions that
actually actually much more computational heavy and and take
up more space on the blockchain as well.
So that's one thing. All right, just just real quick.
I wanted to let everyone know we're going to have to wind up
in 8 minutes. But also real quick.
Robin, I saw super tried to get a word in.
Yeah, I just wanted to add that. Of course, Shinobi is not that
big of a fan of side chains, but I'm a big fan of side chains.
And in general, to have trust the side chain, you need two
things. You need a consensus mechanism
and you need some kind of bridge.
And for the consensus mechanism part, CTV also helps us because
CTV enables. Yeah, essentially.
Space chains. Space chains.
Space chains as well, but, but
I'm talking about stake chains and I think they are superior
because yeah, they enable a Bitcoin backed proof of stake.
So you can have a proof of stake algorithm and essentially you
get the best of both worlds because you get the proof of
work security because you get bitcoins that are anchored into
bitcoins, proof of work. But you can stake them in such a
way that, yeah, you get the benefits of proof of stake,
which is essentially, yeah, instant finality.
Because once the stakers have signed, once the majority of the
stakers have signed, you cannot change their voting without them
revealing their keys and getting stashed for it.
So. If you try the 51%, your A6
explode. It's the only way in which Proof
of Stake is superior. And that's.
That is, I mean not not the only way, but yes.
Real quick though guys. Because there is no social
consensus or something. Because it's it's really about,
you know, reusing you you you're using pre committed analysis and
you can sign block 5 only with your announce 5, and if you ever
sign 2 conflicting block fives, then you have to reuse your
announce 5. And if you reuse your announce
5, you will leak your key immediately and then you get
slashed. And Long story short, that is a
very interesting side chain consensus mechanism that is that
has all kinds of nice properties.
It is way more on chain efficient.
It is way faster, like you can have way faster block times, you
have way faster finality And yeah, you have all kinds of nice
features and I think that's a cool thing about CTV that it
enables such a powerful side chain consensus mechanism.
Super. You were trying to say something
a bit ago, though. I just like to mention that one
difference between space chains and stake chains is that space
chains work right now and they work very well, whereas stake
chains don't. So.
So I think that's an advantage that is worth $1,000,000.
So there you go. State chains work as well, like
you just have to emulate CTV like you, you have to pre sign
the burning contract and yeah, you can emulate CTV.
By yeah. Using an N of N music and you
can make everybody participate in that N of N music by yeah.
Inscribing the the the protocol into the chain so that everybody
can participate or like sign up for it to participate and then
when they refuse to sign they get removed removed from the
cosigner set and. At some point you will end up
with a valid signature and then this is the signature that
allows you to emulate CTV and then it would work like.
Then you can run state chains without CTV.
All right, sounds. Like a lot on that proclamation
from the wise Wizards of Bitcoin.
We're 5 minutes from the the end time, I guess Everybody.
Want to go through like any last comments they have on covenants.
I guess we can start with you, Moon and go reverse.
All right. So the reason I I changed my
name to get Moxie is because I'm I'm kind of personally a bit fed
up with the current culture that developed on Bitcoin and and
everyone is trying to tell everyone else what they can can
do on on Bitcoin. And it's kind of like me opting
out like a teenager, you know, and saying that, you know, fuck
that. Let's enable everything and then
only talk about what use cases are actually valuable enough to
make them more efficient. Because doing it with Top cat is
going to be like messy and limited and inefficient for a
lot of things, but as soon as like the possibility of.
Of like not having people, not having a say in embargoes and
whatnot goes. And also like opcat was a part
of Bitcoin. I would like to, you know, move
us like to see us move past this, this phase of what we want
and what not want and just just go into the what we should make
more efficient and what is really valuable to Bitcoin
phase. Just let's let's do it.
I think I I want to build this. I want to build a meme that is
currently not true, but maybe someday will be.
Everyone agrees that we need CTV.
The only question is what comes with it.
Do we bring it, bring along with it's C cash, any priv out or do
we bring along with it? Check from stack or what?
But everyone agrees or not currently, but pretty.
If we say this enough, maybe it'll happen.
Everyone agrees CTV is the minimum.
And then after that you know, who knows.
So let's let's start there. Yeah, I, I, I, I generally agree
with super right there. I think, you know, I'm really
curious to see where kind of public support falls, you know,
amongst these different iterations and you know how we
balance that with. Things like simplicity and some
other things. So yeah, I'm just very curious
to see how it develops. I do think we could benefit
greatly from them. I think they were will really
benefit, you know, Bitcoin users in the future.
And I think it is sort of a duty of the current Bitcoin users to,
you know, keep it as trustless. And as accessible as it was when
we found it, So I'm, I'm interested in seeing what
happens and yeah, appreciate all you guys coming here and
teaching and speedy trial. Now I guess right Robin, Europe.
Yeah, I totally agree with with what Moon Settler said.
I think opcat is by far the best government proposal.
Even though it's kind of inefficient, I think it's the
most flexible opcode that's. Is currently in discussion and
it would enable all kinds of great things and it would allow
us to scale Bitcoin to global scale to billions of users, I
think. And that's why I think Opcad is
the right proposal. And from there we can see what's
worth optimizing. Sam shower us with Autism.
In order of preference cat, CTV, APO.
CSFSI would be happy enough with all four of them, but if I had
to pick just one gun to that, it's got to be Cat.
Yeah, I agree fully with what Sam just said.
Yes. Trevor, you got any last
thoughts for us. Yeah I mean I think the the
panels here are are more expert than me on the the the specific
alternatives here and it's it's you know great to be on the
stage. Thank you for having me.
I think that you know taking more broader look like we're in
a very uncharted domain for software development when it
comes to how Bitcoin works. Most of the software best
practices used are you know, come from Silicon Valley, come
from web too. And I'm just wondering if
there's you know lessons we can learn maybe from other
industries where they need to adapt and move quickly, but if
they move too fast there could be catastrophic consequences.
You know industries like the Pharmaceutical industry,
aerospace etcetera, things that we can kind of adapt to software
development model to more closely match the environment
that we're in. And I think that a lot of the
things that prevent what we need from happening just come from
the the lacking the right tools for for deciding how to proceed
here. All right.
Thanks so much everyone. Shinobi, is there anything else
you want to add or should we just wrap up here?
I think hopefully this was what people needed to hear.
Just thanks everybody who came and participated for coming and
give us your time. Thanks so much everyone.
Really appreciate all the speakers up on stage and
everyone that came to listen in can.
I just one more thing please. Yeah, sure.
We are inscribing now the first Blake 3 hash function call into
Bitcoin script. We implemented Blake 3 and it
will. Execute right now, like we will
add it to the men pool within the next few seconds and then we
yeah, we prove that Bitcoin script is capable of much more
than people thought. Bow, chicka, bow, bow.
Wizard shit. Wizard shit, Really.
For those who don't get it all. Right.
Thanks so much, everyone. We'll catch you next week.
Thank you for tuning in. And I want to say thank you to
all the speakers and everyone that joined us today.
Have a good one, everyone. Peace.
Take it easy. Toodles.
Thank you Miami, for the last three years in this amazing
city. The whole world shut.
Down, but Miami welcomed us with open arms.
We want to show Bitcoin to the whole world.
We are taking the conference on the road.
To set the stage. For Bitcoin in a New City,
Nashville. Bitcoin 2024 is coming to
Nashville in Tennessee, a city that is known as a Music and
Freedom City. Bitcoin 2024 in Nashville from
July 25th to 27th.