And you’re so full of yourself that you thought you “got me”. It’s how I could tell you were not a builder.
You’re so funny. 😂
I just added ded and dead to my drinking game. 🍷🍷
Glad Guy is focusing on the real issues here. 👍
😂 of course. It was clear from his writing that he wasn’t a builder. Thought he needed to review his primer. Too funny. Look at him. Was hoping he would say feelings again so I could take another drink.
Oh, my! Bless your heart. I guess you don’t know how to respond when your usual bullying stops working.
The only feeling I’m getting is that cringe one where you’re watching someone in the movie embarrass themselves. And also starting to feel a bit sorry for you.
I explained to you how there is a risk of MEVil. I guess you can just pretend I never said it. Everyone else can see that I did and also see that you had nothing to say.
I got a nice glass of wine 🍷 here. I’m going to take a drink every time you say “feelings”. Don’t keep me waiting! 😆
I read you correctly, didn’t I? 😎
I look forward to your actual rebuttals when you have some.
You made no such case. You only made unsubstantiated claims that it was the same as P2SH.
I just pointed out that it was a false analogy to see if you could back it up. And you didn’t.
It seems you’re just parroting talking points given to you from other people. Just like that meme where the NPCs all download their latest update. Did you sit in on a talk once or twice and conclude you now know everything there is to know?
I often find that folks who see the world in superficial simplicity often have never built anything of value or complexity. Those who have usually realize that many of their preconceived assumptions were wrong.
By the way, what they didn’t discuss in that talk you attended:
Op_ctv can be used to expand time-based trading opportunities, options, futures, DLCs.
https://www.coindesk.com/layer2/2022/05/20/bip-119-unpacking-ctv-and-how-it-would-change-bitcoin/
https://bitcoinops.org/en/newsletters/2022/02/02/
Trading and marketplaces create opportunities for people to front-run transactions.
This creates MEV or MEVil, as some people term it. MEVil motivates miner centralization.
https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev/
Here’s a primer on MEV in case you forgot!
https://bitcoinmagazine.com/technical/mev-monster-bitcoin
Anyway my point is that it’s not clear that it’s necessary and we definitely don’t know that it’s safe. I can see that there is a potential risk. I just don’t know the severity of the risk and neither do you.
You didn’t show anything. You just made claims I didn’t know what I’m talking about. Ad hominem attacks are always the fallback, aren’t they?
It’s not on me to prove it’s necessary and safe. It’s on those advocating for it. And apparently that’s not you. 😂
Do you just jump into random convos and yell “you don’t know what you’re talking about!!” And then refuse to support you point when challenged? Pretty funny. 😄
Is CTV being used the wild right now? In Liquid? Somewhere else?
Hard for me to trust “it’s the same as” arguments because if it were the same then we wouldn’t need it.
Is there a document somewhere that provides an in depth review of the safety considerations?
What is the feature that it provides that you care most about?
This summarizes my lates thoughts. Important to also prove necessity.
nostr:note16zakjweexcw9hjawwxllrj702mnt3k9ve69lgq5am39q77vedzksnd8n4a
Do you know what percentage of users right now are connected to the top three relays?
My assumption is that it’s more than 90%.
If I’m right (>90%) then this gravity will be hard to fight. The large relays will become stronger through network effects.
I remember reading that the devs were going to try an inbox / outbox solution where the large relays would be used for addressing. Is that still the plan? I didn’t see any discussion on removing the dependency on the large relays.
Did I miss that? Is there a way to remove the client dependency on the large relays?
It’s for the reason you wrote this:
“1 large public, international relay: nos.lol, nostr.mom, relay.damus.io, etc. “
You seem to be saying that it matters which relays you use. That, if you don’t use large relays, then you will lose visibility and content.
If everyone prefers to connect to large relays, then the system will stay centralized and become even more centralized over time.
The only way nostr becomes more decentralized is if it DOESNT matter which relays you use.
This is architecture which promotes centralization over time:
“make sure to choose a large international relay”…
This would promote decentralization:
“just randomly choose any 10 public relays and you’ll never miss a post and all your followers will receive your content.”
Am I missing something? If it doesn’t matter which relays to use (we can choose randomly), then please let me know.
Just a reminder that anyone advocating to change bitcoin’s core protocol must show that the change is both necessary and safe.
A change is necessary only if it fixes an existential problem that cannot be fixed any other way. It’s not necessary if it addresses a potential future problem, or if we can add the feature elsewhere.
It’s safe only if we know that it cannot be abused to harm the overall bitcoin ecosystem. This includes encouraging centralization of miners or nodes, or undermining the power of nodes to govern the network.
We cannot accept “trust me”. Anyone advocating for a change must show their proof of work. And we must verify it. The core software is the most vulnerable part of the network.
Bitcoin is the world’s money and our hope for the future. It will survive only as long as we actively protect it.
This is what I was referring to when I said that nostr has “centralizing gravity”.
This guide essentially says that all users must connect to one of the large international relays.
Clearly having all users gravitate to a few large relays isn’t the best for freedom of speech and increases legal risk for those operators.
There could be many ways to fix this problem but it starts with acknowledging that it exists and working with the community to solve it. nostr:note1fsdpzetk474478euflyuj3ssqgcp0xeljj630459g7mn5gt68nxsmws3gg
You say it “appears to be safe”, but have put forward no justification to support that statement. You can’t say just say “trust me” to the bitcoin community. We need the “verify” part too.
“it’s *easier* to justify than a bunch of things we’ve already soft forked for.”
Sure, but you and I both know that’s not a real argument. Arguing that devs were more reckless in the past doesn’t justify additional reckless protocol changes. That past recklessness explains why we have the witness discount, more spam data in our timechain, and additional centralizing forces on miners.
Bottom line: if you’re advocating to change the core protocol, you have an obligation to demonstrate that it’s safe and necessary. You owe the community this. And since you have a highly visible platform, you have a duty to use a higher standard of care … a higher bar, if you will.
Great, I’m glad someone who does just showed up. Go ahead, tell me all the ways it can be used, and prove it’s both technically safe and also doesn’t disrupt the network ecosystem.
Ok, then prove to me that it can’t be abused.
You can’t prove a negative so to prove it can’t be abused, you must first list all classes of ways it can be used and then prove those can’t be abused.
Since you can’t list all the classes of ways it can be used, you can’t prove it can’t be abused.
So therefore your statement that you know the limits of it and that it’s safe is not true.
You don’t know the limits of it. If you did, you could tell me. Right?
Timelocks and multisig have classes of uses beyond lightning so you’re right, it would have been silly to reject them because we didn’t know of the potential of lightning. We already knew other ways they could be used. For example, shared custody.
It’s not just a hashlock, is it? If it were just a hashlock we could use pay-to-script-hash (P2SH).
Think about it more. You have everything backwards. In product design, we don’t build technology first and then hunt for a problem to solve. We first identify a human centered problem to solve and then design technology to make people’s lives better.
Imagine that you are a systems designer for a nuclear reactor. Would you agree to release a public API that could do a bunch of stuff that people will figure out later? No, you wouldn’t. Someone might accidentally melt down the core. Instead, you would make the most limited changes that you knew would be safe.
When I look at the bitcoin core protocol. I see something more important than a nuclear reactor. The core devs are one of the most centralized and dangerous systems in the bitcoin ecosystem. Unlike individual govts, they actually do have the power to destroy the entire network.
Let’s not “melt down” bitcoin’s core. Future generations are counting on us.
Op_vault is more limited and specifically designed to enable that one feature: vaults.
This article discusses vault as a subset of ctv.
But the fact that vault is a subset of CTV is not my point.
My point is that changes to the core protocol should be specifically limited in scope so that we can have more certainty that the change is technically safe, and also doesn’t disrupt the network ecosystem.
Maybe op_vault is the right approach to solve vaults, or maybe not. What makes it better is that it’s *specifically* designed to solve vaults.
CTV can be used and abused in more ways, including ways we don’t yet know.
It’s terrifying because nobody knows the limits of its use and therefore nobody can say with any certainty that it’s both (a) technically safe and (b) won’t disturb the network ecosystem.
My understanding is that taproot and segwit’s witness discount encouraged and increased the volume of arbitrary data stored on chain.
This expanded the market for things that use this data. More data, more junk, larger market.
Thereafter private apis to miners and pools developed to front-run and insert crap in the chain.
Private apis and out-of-band payments encourage mining centralization by giving unequal access to fees and disturbing the even playing field. This motivates miners to join the pool that has better access to these exclusive fees and encourages monopoly-like arrangements.
https://bitcoinmagazine.com/technical/the-witness-discount-why-some-bytes-are-cheaper-than-others
I know, but that’s terrifying isn’t it. It’s why we ended up inadvertently centralizing mining with Taproot and making it difficult for folks like me to periodically sync the blockchain on our small TOR nodes. Secret blocksize increase after fighting to keep it small.
Why not simpler still? Why not op_vault?
What specific use cases are your priorities? I’m sure the community had a top one. Why can’t we just focus on it first?
I’ve only heard from devs, “I think it’s safe”, which isn’t appropriate for the system that protects the world’s money. We need to be absolutely certain that it’s safe.
I’m not in favor of generic expanded capabilities to the core protocol where we don’t know the limits of how they will be used.
It would be better, IMHO, to pick specific use cases that the community wants and to then engineer the best, most limited change that meets that need. Vaults? Payment channels? Etc. We should design a change to do just that and only that.
We need to learn our lesson with Taproot and discounted witness data. Devs didn’t realize how it would be used for spam.
Devs aren’t omniscient and can’t predict all ways a change can be abused. Some of the abuses will even be indirect and attack the incentives underpinning key operations (like mining). Best to lock it down to reduce the attack surface area.
Always fun to see a good retest of the laffer curve. 🍿
The destruction seems so stupid it must be intentional, right?