I suppose we will now all talk about covenants...again.
Here is a nice lite compendium of covenants info. The sit didn't show up too well on mobile, so consider checking it out on desktop.
Might be a good place to start if you want to get up to speed on what's out there.
I wouldn't call myself an ossifier, but I'd prefer to err on the side of being conservative.
My reason, Bitcoiners shouldn't ever compromise on freedom, and as long as nothing is breaking, then I'd say the only acceptable change is one that blazes forward from that principle, ideological, freedom-maxxing intolerance. Obviously, the foRkTarDS didn't -- they were ideologically intolerant, but from another camp, the wrong one. From my 30000ft view, a good proposal has to somehow create the narrative that it enables more freedoms in the future, and not less, get the ideologically intolerant freedom maxis on board and the rest will follow.
Again 30000 ft.... Covenants defined as,
Isn't very reassuring. But what do I know?
Now I wonder, can we undersrand the Knotzi as a semelparous bitcoiner, that essentially proved the opposite of their main thesis, i.e. that a small subset can control bitcoin?
I wonder.
In Bitcoin, the recipient picks the address (i.e., the output script) that they expect to be paid to. Usage of a covenant construction would be self-selected, it generally cannot be imposed by the sender. If the sender unilaterally decides to send funds to a different output script than indicated by the receiver, the receiver would likely not even notice the payment, and has grounds to not honor the payment.
My comment may have come off as tone deaf, I'm realizing. I do understand the basics of bitcoin transactions, but a covenant script is unfamiliar to me.
I'm trying to think about what it would be used for, about which I can see there have been huge efforts to explain, but I encounter heaps of technical jargon that I don't understand when I try to engage. Not from you, though. It is really interesting that the people who do understand, and whose opinion actually matters seem to have their own preferences based on the techanical merits and pitfalls of each proposal.
Fwiw, I hadn't ever read up on these nor paid attention to any commentary before reading this webpage and I was just pointing out that the language sounds CBDC-esque, put in that way. Maybe it isnt just me, since you and nerd2 sought to clarify the point as well. Is it a common FUD?
Covenants being used to create a whitelist-coin was a big concern when the covenant debate restarted a few years ago. After it was debated for months, the general sentiment settled on the concern being unsubstantiated. About to go to bed, I’m gonna try to write up an example for a covenant tomorrow after the Optech Recap.
Just checking, you have already read this thread by Robin Linus? https://delvingbitcoin.org/t/perpetually-kycd-coins-using-evil-covenants/556
Looking forward to that!
Multi-sig can be defined as "Restricting a UTXO to only be spent after a number of wallets has signed" or timelocks as "Restricting a UTXO such that it can only be spent after time is passed"
You have to create a wallet with the CTV script for this to be a thing. As we only expose addresses, and not xpubs, no one can lock your Bitcoin to a CTV script (using a seed phrase you created) in the same way that no one can lock your Bitcoin into a multi-sig with keys that they control. This is FUD.
This is once again a demonstration of why I am calling for anyone serious about CTV to write demonstration software
Anything you can do with CTV you can already do with presigned transactions + deleted keys. The purpose of the CTV consensus change is to make it so users don't have to perform this bullshit ceremony just to use that functionality.
No because like one of the things they're trying to do is like coin pools. Like your lightning transaction is actually a 2-of-2 multi-sig. So its kinda like "just use deleted keys" and so you're relying on the other party you're in this covenant with (which just like multi-sig only works by exposing xpubs) to delete their keys in order for your security guarantees to be real.
Also lets be honest with ourselves, a psbt (or a bunch of them) is like going back to 2009 wallet.dat files for Bitcoin key backups.
Saying some things are "kinda like" other things is not an argument against covenants. Try again.
I'm sorry I'm trying to make it relatable to something you've experienced before, but again, that's why I call for demonstration software.
Hey, recreate a vault that protects an mk3 generated seed using presigned transactions. See how well it goes for you.
So I thought about it right? You would generate the seed on the mk3, presign a transaction to a holding address. The holding address uses the timelock script. After the timelock, the mk3 can spend from the funds again, no no wait...because the key wasn't generated securely the presigned transaction never gets mined ah fuck and we don't have a "wait until I sign to start the timelock" op_code in Bitcoin script. Man, but Kruw you're so sure about this pre-signed transaction thing why don't you demonstrate for the class?
Look, if you know me, you know I like to hold back from being an asshole like this, but I don't know maybe this is what it takes to make a point?
I love being an asshole, no problem.
Irrelevant. Bitcoin is built on the assumption that users generate random secrets. Nothing matters if you discard this premise.
Okay. We'll see how relevant it is on the larger forum. I think its actually very relevant. "CTV vaults save you when your cold card fails you".
I think there's a bunch of node runners that are going to be very happy that this risk mitigation can be a possibility.
The logic makes sense, but not the story. Why is it needed?
Multusig mitigated single points of failure risks. Simple.
Simplicity speaks volumes.
Don't worry, I'm going to be taking the "code or shut up" approach for the next few months. I'll come back with a GUI so you can see what I'm talking about, although CLI demo software is currently available if you would like to get ahead of the curve.
110 was always about dismantling resistance to covenants and Bithereum non-sense generally
There are things coming from this that can be used for resistance.
For example:
lot=dead. Anyone proposes it we can point to BIP-110 to show what a dumbass move that is.Filteroors are back into the fold unless they hardfork. If you are looking for ossification, keeping them from forking off again is maybe the most impactful thing to do. Bring as many sides into the fold and enjoy/suffer infinite stalemate. It won't be fun though.
I think this was the trap for conservatives, you can't opt-in your way to making others opt out. The entire premise relied on miners earning less money by rejecting transactions the market was already paying for.
Core will be fighting down-hill, or not really fighting at all, all they have to do is open the gate to let the barbarians in. Incentives work in their favor.
This begs the question of how do conservatives discourage miners from upgrading, there's only 2 levers to pull: fear and greed. Core has greed on lock, so really that only leaves fear.
Fear requires plausible consequences, which conservatives has no means to inflict.
Even if we can educate the average Bitcoiner that Bithereum features are scams, will lose them money eventually, etc... that won't prevent the illusionists behind Core from pulling enough astroturf together to tantalize miners with upside.
I don't have a solution or a plan, seems intractable, need to ruminate more on the first-principles.
The 110 psyop feels like check-mate move at this point, we're all ETHheads now.
Sounds fatalistic, while you made the most important point here:
Then add that the entire premise was built upon taking away existing freedom to choose what goes in. It was never going to happen, unless people got bribed with dark pool moneys or there was a large hidden stash of miners sitting in aligned warehouses.
I think that if anything, the opposite method to what Luke did, e.g. smooching every miner, will be used for some quantum thing rather than CTV and I think that it'll come from the new "consortium" that Mike is gluing. Signature size growth will cause a miner bottom line improvement, and so will GSR if enough usage can be demonstrated.
Doing a wild fork isn't conservative at all, it's reckless. Let's not confuse the normie-political spectrums that some retards on twitter claim to subscribe to with those that align with a resilient, more static Bitcoin. Everyone that didn't want BIP-110 is more conservative than those that tried to push it through; and that includes Core.
Yes conservative as in let's not turn Bitcoin into Bithereum, 110 being a psyop to trap people with those proclivities and make them look retarded and did a great job
CTV is definitely next with resistance shattered, too much money in it for bullshit... Fake L2's, delegated apps, all the VC pressure is behind it
Let's agree to disagree on that; I'll keep your scenario in mind. If I would truly need Luke & Co's endless streams of bs to have honest Bitcoin, and there is no way to have it without them, we've been completely screwed from day 1 though. Better install knots and go sit on that new chaintip then.
Luke and Co weren't that though as we've concluded, they just co-opted conservatives as useful idiots. Not only was the fork not conservative, they left carve-outs for all the same shit they were against AND Luke himself is pro-covenants. It was all a troll and people bit.
I'm not fatalistic, but recognizing a phase change that's been unfolding for some time having catalyzed.
Vitalik fucked off to do his own thing because Bitcoin was too hard to change, the market has since patched that loophole and doesn't want new shitcoins. It wants to shitcoin up Bitcoin.
This could be spun, and will be, as a good thing since at the end of the day all that matters is 21M and Bitcoin being the world-reserve currency. The question becomes then whether one views those things as compatible or not. Philosophically they are not, technically though, they are.
Case in point technically, another thing 110 people were wrong about was the idea that everyone bears node costs. Appeals to disk use-age resonate with very, very few because very very few actually run nodes. Apparently they never read me on the 200M distribution ceiling.
This leaves us where the incentive to shitcoin up Bitcoin is greater than the incentive to resist that.
The one thing Luke and Co did have going for them was a mining pool of protest, but they torpedoed that brand.
Maybe another protest pool comes online, but anyone pointing hash at it will invariably earn less / lose more than Bithereum pools. Even then, that pool won't be able to prevent anything... at best it would only marginally increase the cost of disk use and occasionally slow down confirmation times for shitcoin op_codes. Maybe that's enough to deter that useage somewhat, but I think that requires the other phase change I see coming where mining is done at a paper loss anyway.
Exactly. Which is why, when it was first predicted that there would come a fork, I thought it a crazy thing because that contracts rather than expands influence. I was wrong about that though. Very wrong. My bad for thinking it was rational when it was more... idk.. spiritual?
The funniest thing is that one of those "L2" thingies prefered to have a tx in every block. This is why a pool with some custom funny algos, not just Ocean, but also f2pool and maybe even MARA as the polar opposite offering "custom blocks" to print pictures in a block explorer website is useful. Keep everyone with poor assumptions in their designs on their toes.
I did come across some initiative by Foundry the other day to start supporting SV2. That would be good if they really do it. Put template design closer to the miner, retain the risk pooling.
Bottom line the worry I don't share is about CTV. I think that some influential core people are skeptical or even refraining from stating their opinion. Most of it is "this doesn't really enable a lot of things we need".
OP_TXHASH authors are Steven Roose and Brandon Black, not Russell O'Connor and Brandon Black.
You can verify it in https://bips.dev/346/
Also, for some reason in the left index TXHASH looses the prefix "OP_".
I don't mind AI slop, but you need to double check it.
Is this an old page? It doesn't mention BIP-448 or OP_TEMPLATEHASH. IMO that proposal currently has the most momentum and odds of actually getting activated.
I believe it is maintained by Brian Hirschfield, and it is possible that he is using it as a learning exercise.
seeing those proposals I can't stop thinking of them as shenanigans for trap clueless people.
Ill take a look and read more about it to clarify what it is.
I always thought Dathon sounded rather like Dathan, who led a rebellion against Moses and got smoked in the Book of Numbers.
People think it's weird when I pay attention to names, but it's worked out for me so far.
Interesting connection
Good link, comments filled with all the usual FUD.
I think reading and talking about it is not enough. We need to build demonstration software so that regular users who were psyoped into being scared of it can instead of talking about outrageous hypotheticals, talk about their lived experience instead.
On that note, I would start with vaults as the first demonstration using the coldcard mk3 example as background for the demonstration
The funniest part is both sides think they're the freedom camp. One side says don't touch the rules, the other says covenants are how your keys survive your own hardware failing. Same fear, different cure. The fork circus just proved the loudest narrative wins, not the best technical case. That's the actual lesson this thread keeps dodging.
deleted by author