pull down to refresh
122 sats \ 3 replies \ @justin_shocknet 8 Mar freebie
Covenants might be fine if they weren't overwhelmingly pushed by shitcoiners that claim they can scale self-custody of Bitcoin to billions with some unresolvable VCash token
The gist is we can consolidate all of Bitcoin into 1 UTXO- because muh virtualization
There don't seem to be many sane proponents who will disavow these clowns... Probably because it doesn't have a usecase beyond vague ideas around efficiency that can't be quantified since we haven't even glimpsed saturation of current technology
reply
210 sats \ 1 reply \ @ursuscamp 9 Mar
Your Covenant Derangement Syndrome is quite severe.
reply
0 sats \ 0 replies \ @justin_shocknet 9 Mar
Preferable to the shitcoin mind virus consuming you with bad ideas, go peg yourself
reply
0 sats \ 0 replies \ @StoneCodlHodl 9 Mar
Is recommend you read the linked article. CTV opens no more shitcoin holes than exist already in Bitcoin. But CTV is the safer route, and gives us superior Vaults, and more efficient lightning channel opens.
CheckTXHashVerify, however does open more dangerous features, including recursive covenants
reply
241 sats \ 0 replies \ @freetx 8 Mar freebie
I'm not against covenants, its just that I question if they will fundamentally solve some of the issues.
-
Certain problems have an economic component that there is no way to engineer around. For example, suppose you said "I want to quickly onboard LN users and immediately provide them with balanced channel so they can instantly send/receive LN" - This is not a solvable problem at the moment given the economic component. LSPs would have to lock up huge amounts of sats to fund "onboarding the world". Unfortunately I don't think covenants will help with that class of problem.
-
There are certain problems that you can create a technical solution for, but results in complex UX/UI experience that may doom it to never being used. To be honest, I think many covenants fall into this category. Its not clear how its going to practically work.
-
Negative or flat outcomes. Any new OPCODEs will be used in ways thats hard to predict. Are we sure we are not just incentivizing some other problem somewhere else? (ie. we free up X% of blockchain space by using covenants, but enable Y% new blockchain growth by shitcoiners using new features? Is the net outcome worth it?)
-
Lastly, and this is the most nuanced, certain classes of problems inherently involve custodial relationships. When you give your fiat to someone to onboard into LN, you are already in a custodial relationship. You can't "atomic swap" your fiat note into LN in a trustless way....therefore if thats the case, then solutions like Liquid / Fedimint, Cashu already exist and provide a solution. In other words, the "last mile problem" is inherently custodial. Further, because of the economic realities mention in #1, its not clear how that relationship ever really becomes "non-custodial"? Yes if you onboard $1000 USD via a CEX you can convert that into non-custodial LN / mainchain money....but what about $5 USD? Point being: What are we even solving?
reply
100 sats \ 4 replies \ @Coinsreporter 8 Mar
So, you wanna say that covenants would serve as a condition for transactions on Bitcoin.
First of all, why do we need such conditions? Are we giving control to someone else? Or will covenants enhance the security of Bitcoin transactions? IMO, we don't need covenants.
reply
50 sats \ 0 replies \ @tetsu_tamasi 8 Mar
No. Nobody can put conditions on your bitcoin address under your keys. You set up your new covenant address (like a taproot or any other) and just for that address you set the conditions for Bitcoin that will be received there- how bitcoins send to that address can be spend - to which addresses they can go from there - conditions for one hop into the future. Lets say they can go to three addresses. And on those addresses you can set conditions again (if they all CTV addresses). You can make whole trees of transactions from there. That would be definitely useful for lightning. CTV is the simplest covenant implementation. We don’t need anything more complicated than that. Fuck the shitcoiners, they trying to mud the water.
Also im a retard and you should get more technical info on it.
reply
0 sats \ 2 replies \ @Malachi17 8 Mar
Conditions: I need to send you money. Other condition, you need to send me money. Situation addressed. ;)
reply
0 sats \ 1 reply \ @Coinsreporter 8 Mar
That's what I was saying. There's no need to put 'no reason condition'.
reply
0 sats \ 0 replies \ @Malachi17 8 Mar
Yes, I was agreeing.
reply
0 sats \ 3 replies \ @gzuuus_ 8 Mar
I need to look at the details, but my biggest concern with whatever proposal of covenants is that by setting conditions they can limit or even prevent you from having control over your addresses. Edge cases and "creative" censorship can happen.
reply
125 sats \ 0 replies \ @ursuscamp 9 Mar
The restrictions is what makes them powerful. Those restrictions allow you to remove trust. There are already many types of spend restrictions in Bitcoin, such as multisig or OP_CSV or OP_CLTV.
reply
0 sats \ 1 reply \ @tetsu_tamasi 9 Mar
LOL, NO
You set conditions on your addresses. You receive Bitcoin from adress A to your adress B - if there is a covenant on it (how can be spend) it is set by you.
reply
0 sats \ 0 replies \ @gzuuus_ 9 Mar
What if the government only allows you to use BTC that are "compliant", and for them to be that way they have to be at an address with a covenant that limits how you can move your utxo, those limits are not set by you. It's just a possibility... But without a doubt, anything that limits or restricts your ability to move your utxos freely must be considered with great caution. In any case I am not against it, I would simply like to understand all the implications that this would have.
reply
0 sats \ 0 replies \ @hasherstacker 8 Mar
An interesting topic
reply
0 sats \ 0 replies \ @SaToSHiWoMaN 8 Mar outlawed
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.