Nostr Web Client

No debate within your echo chamber. And outside of your chamber are only those that don’t understand bitcoin. You should read your notes in a British voice and then maybe you’ll see the overwhelming arrogance in them.

Shooter McGavin 7mo ago

If you want even more arrogance use my voice you twerp nobody golfs better than me

Matt Corallo 7mo ago

When someone provides one argument that stands up to the slightest bit of scrutiny why paternalistic node policy is a good (or even neutral) thing, I’ll happily change my tune. Until then…

Kretchino 7mo ago

"Paternalistic node policy" is a bs argument and exactly what core devs are pushing on the community right now.

#gfy

M0053 7mo ago

Since these arguments seem to rush to ad hominim and strawmen I will just say sounds like daddy issues to me.

M0053 7mo ago

I think this person makes a very good argument why there IS and should be a debate. Or is he one of the "paterlalistic" people who "don't understand bitcoin"?

Matt Corallo 7mo ago 💬 1

This isn’t an argument, it’s just “wellllll, I haven’t thought about it that long so hold off until I do”? This debate is a decade old, that’s on Adam.

M0053 7mo ago

I said was I good reason for debate. Not a good reason for potentially allowing unrestricted data in OP_RETURN.

I, and many others am not convinced by the arguments FOR that change yet.

Is all tradeoffs. For example I am also not entirely convinced that this rush to Knots is a good idea either.

Matt Corallo 7mo ago

I’m happy to answer any question you have! I don’t see any tradeoffs at all, actually (not that I’m happy people want to embed data, to be clear I’m not!)

M0053 7mo ago

Remove all limits from op_return is on the table. I not see how that would not have tradeoffs. One of which would be potentially exploding the size of the unpruned blockchain, right?

Matt Corallo 7mo ago

People currently embed data in the chain via witness data (which allows them to embed 4x more data), often using Slipstream to get nonstandard transactions mined. I don’t see any reason to think allowing additional OP_RETURN data would increase the amount of data stored in the chain.

M0053 7mo ago

Isn't one of the possible recommendations to remove the limit completely on op_return? And if so, would that not allow basically limitless data to enter into the Mempools and be written to the unprunrd blockchain.

I understand that spammers are using the witness area now, and that that is worse, and part of the idea here would be using OR as it was intended. But it doesn't justify either usage, in my opinion.

Matt Corallo 7mo ago

The problem is there are very real and very significant consequences to mining centralization if ~all the valid transactions people want to make are not readily available to any miner running Bitcoin Core. So changing the option (a) doesn’t impact how much data people can store, they can just store it in a new place that’s more expensive (not sure why they would but even if they do great, they’re storing less data) and (b) it materially improves Bitcoin’s robustness.

I get that it feels icky, but the facts on the ground are pretty clear.

M0053 7mo ago

I appreciate you taking the time to write these answers and I actually understand the points that you're making already. I think we diverge fundamentally at an earlier point.

In some ways I feel like this argument is like sort of a harm reduction argument. And I think harm reduction is a good idea for drug addicts for example, but we wouldn't mail everyone in the world a pack of needles and some clean heroin just in case so they would have safe things to use if they ever decided to.

In some ways, this seems like the windows registry to me. I think part of the idea there was let's have a sanctioned place for developers to put their configuration data. Well, that kind of thing can grow into something unexpected and that's what I'm worried about as we continue to open the doors to data storage on the Bitcoin blockchain.

I would much rather see us work to find ways to make storing (large) data on the blockchain in any of the three places harder to do.

M0053 7mo ago

On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return. And I think there's a non trivial number of users who do not want that to happen. And these users include cypherpunks, people who are current and past contributors to core. it is not cut and dry.

I don't think the community is done discussing this by any means. And I think rushing something like this on any level will increase the chance for forks and even forks between reference implementations will have implications that could be unexpected. that are possibly even negative

Matt Corallo 7mo ago

It is fundamentally improve to prevent those who want to store data on chain from doing so. There’s nothing to investigate there, there’s only worse ways of doing it and better ways of doing it.

> On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return.

I don’t believe this is true. The Citrea instance isn’t material to them. They’re gonna do it either way, either in a really shitty way that bloats the UTXO set or in a better way. The only impact is on Bitcoin, not them.

> rushing this will increase the chance of forks

Huh? This is mempool policy, not consensus logic. People can run other code if they want to but there’s no chance of a fork for mempool policy.

If you mean that people will fork Core, I mean, okay? The issue is ~all the engineers working on Bitcoin Core and mempool policy agree with this change (which should tell you something, they don’t often all agree!), so maintaining a fork without any of the people competent at doing so is not gonna end well.

Or you end up like Knots, a one-man project shipping a ton of barely-tested patches that zero people aside from Luke have reviewed. That’s not a serious project.

M0053 7mo ago

I almost amended to clarify by fork I meant the project but at the same time you are making my downstream argument as well. We could end up with versions of software that could eventually diverge enough to interrupt the "lockstep" Satoshi wrote about @ BCT when the topic of multiple implimentations came up.

I agree that people running to a project being run by a single person has risks as well. But I reject your intimation that the only people competent enough to work on Bitcoin are already working on core.

Honestly, that kind of smacks of the arrogance that the community is interpreting from the people that are involved with core.

Which brings me to my final point. The fact that the community is up in arms about this may not be something that you and others agree with, but these are the people that run the software and some of them have been doing it for quite some time and some of them are also quite intelligent and not just people being led around by the nose by strong personalities or that sort of contention my perspective, this seems like the most serious issue of all. A fork in the community, if you want to call it that. I know that this is a new thing. In the op_return topic has had contention from the beginning. I was there. And many of the arguments being used today are the same ones that we're coming up at the very beginning and have continued to be concerns for many people in the community, many of whom are cryptographers, cypherpunks, programmers and prominent people.

I understand that this change is believed by its proponents to be the best way to actually reduce spam on the chain, the best middle ground, the best compromise.

But the way this is being handled has caused the community of users to lose trust significantly in the people leading the core project. And this should be alarming to all of us. Because in the end, that social schism can be the most powerful introduction of chaos and be more easily used to subvert the direction of Bitcoin than even a bug in the code.

M0053 7mo ago

Several typos. I try lol. One spot should read "NOT a new thing" for example

M0053 7mo ago

This illustrates weekday I am concerned about...

nostr:nevent1qqsfydhvrtugtrfkx7xzt94v2car36nlhv5wmfrhn0ujqe9d0u2n8rqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrau00035s3n8z6c7uzwdwt8dhmfqmal0pu6vfshrlssh2scwztgvpsgqqqqqqsm9rdn3

MrTea 7mo ago

One option gives nodes a choice and the other doesn’t. Which one of those sounds paternalistic?

ShiShi21m 7mo ago

This is actually a good frame, but then why was the OP Return limit included in Bitcoin .9?

Matt Corallo 7mo ago

Are you really suggesting that nothing material to this has changed in Bitcoin in a *decade*? Come on…

ShiShi21m 7mo ago

I'm genuinely asking, what (specifically) has changed?

e5

e5bab168... 7mo ago

With all the great benefits of segwit (lightening!), it also enabled (made a concession to?) consensus valid 4mb blocks. In this world the potential harm of blocking consensus valid transactions with an insignificant amount of data in an op return should not be something the reference implementation of bitcoin is a party to.

ShiShi21m 7mo ago

So your logic is the blocks are heavier so fuck it make it possible to go even heavier bc it's a small increase?

e5

e5bab168... 7mo ago

I just don't want to see incentives to route around our peer to peer mempools with things like slipstream. As much as possible, I hope all miners can be on a level playing field. Once I finally get my bitaxe setup, I want to be able to compete fair and square. This is obviously on a very small personal level, but when this scales it may be critical to mining and bitcoin's decentralization. It is my understanding that other standardness rules are important for ddos and other attacks. The op return limit is not. I would probably be in favor of a consensus softfork that limited blockchain spam without negative centralization risks. But that is quite unlikely unfortunately. Sadly, 4mb blocks/transactions of crap are possible. Will blocks be heavier without the op return limit? Maybe, but I believe negligibly so. I'm more concerned with centralization risks, utxo set harm (I think this may have a greater impact on costs to run a node than any potential small increase in storage costs.), and making it harder to securely maintain bitcoin core. I'm no one significant here though, and am just regurgitating information. But it is information obtained from multiple well regarded 😉 minds past & present of bitcoin, and it makes sense to me. Best to you and all of us! but I need to step away from this soon. Rainy day, but when that passes, I need some rays!

ShiShi21m 7mo ago

Why no zap?

e5

e5bab168... 7mo ago

I appreciate the thought. I'll get there eventually. I'm an amethyst user on graphene, and that works well for me. I'd like to use ecash for zaps, and was hoping amethyst or another similar client might build in an ecash wallet whose balance I can maintain externally with a lightning wallet. I'm aware of nostr wallet connect, and that may ultimately be the route I take, but my initial desire was to avoid inter app communication on my phone. I think I may be overly concerned though, and just need to get on with it. I do want to join the zap party! Curious to know how you're setup for zaps if you don't mind sharing.

Matt Corallo 7mo ago

At the time, Bitcoin Core scaled poorly. We didn’t have things like compact blocks and were not really ready to handle actually full blocks. Further, things like Slipstream and Libre Relay didn’t exist so policy wasn’t completely useless, though obviously it still only fairly marginally increased the cost of finding a miner to mine non-standard stuff (though F2Pool was mining non-standard stuff regularly not too much later than this). Finally, there didn’t seem to be a ton of demand for these kinds of transactions, just people exploring backing up their data to the chain, so nudging them away from that was effective (compare to today where it not only wouldn’t be effective, it would harm most miners in favor of MARA) vs today where we have transactors putting crap in the UTXO set to get around the limit, which is obviously much much worse.

Eporediese 7mo ago

Big Barry Bitcoin 7mo ago

I think I understand the stated issue that people are finding ways to broadcast transactions out of band directly to miners and that this "is bad for decentralisation".

But how exactly?

The only thing I can think of is that it becomes harder to know if censorship is taking place if you have no idea what you expect to see in a block because half of the backlog is private. So potentially it affects censorship resistance.

But what other effects are you referring to? How is this limit reducing decentralisation?

If you already have a writeup, link it, I'm just trying to understand.

Matt Corallo 7mo ago

I’m working on a writeup, but the TL;DR is basically that if it were to become popular, small miners wouldn’t be able to compete because only the large miners see a large portion of the transactions that pay them fees.

Big Barry Bitcoin 7mo ago

Thank you.

Dave🐸 7mo ago

A lot of bitcoiners clearly don’t understand what bitcoin core do lol

Time for a nostr:npub10atn74wcwh8gahzj3m0cy22fl54tn7wxtkg55spz2e3mpf5hhcrs4602w3 ?

Johnathan Corgan 7mo ago

Welcome to cryptoanarchy. 😏

Ferris Bueller 7mo ago

You really sold me on Bitcoin Knots. I appreciate the help!

mandalorianhodl 7mo ago

jgbtc 7mo ago

The increasing ivory tower, high priest, attitude is enough incentive for me to run knots. For example the second sentence in the third paragraph starting with "There's no debate..." That was the final straw for me. Good bye core, hello knots.

HoloKat 7mo ago

There’s no debate! I said so!!! Stop debating!!!!!!

Eporediese 7mo ago

I made that switch this weekend. Vote with your feet!

Crizzo 7mo ago

There's no debate because they banned the people trying to debate 😂

charliesurf 7mo ago

stopped at grok

Bounty 7mo ago

See the forest through the trees. If you want users to continue to download and update Bitcoin Core, that requires rough social consensus in the project’s legitimacy, usefulness, etc.

supermass 7mo ago

Matt, are you seriously conflating mempool standardness rules with a GUI update?

C'mon dude.

Matt Corallo 7mo ago

Yes, in both cases it has no impact on Bitcoin’s consensus rules nor the “definition of Bitcoin”. In both cases, if the decision is “wrong”, the network will simply route around Bitcoin Core (either with a different wallet or by using things like Slipstream).

Yes, obviously the GUI is less likely to cause problems for other Bitcoin users than P2P changes but in both cases this is a question for the open source contributors of Bitcoin Core (which is an open process everyone should provide feedback on!), not one that gets decided by “consensus” and doesn’t change without it.

supermass 7mo ago

I think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.

Obviously Core is not Bitcoin, but it is a default!

And as we've learned from the discussion, defaults are incredibly sticky.

Fragmenting the network's mempool/miner relationship (if we made datacarrier=0 by default let's say) would still be incredibly hard and require a huge, sustainable actor in the space to push non-standard transactions.

I think we are giving too much credit to that being a reality and not enough credit to the reality that the majority view Core as Bitcoin, and having to "prove" them wrong would be much more harmful than not.

For example, do you think having thousands of people switch to Knots is a good thing right now?

It is happening because of this debate, and I find it much more harmful (given Knots current fundamentals) than just closing the PR and continuing to monitor expected vs. actual blocks for the foreseeable future.

Also would like to state for the record I am in the nostr:nprofile1qyw8wumn8ghj7mn0wd68yttjv4kxz7fwwak8vuewwdcxzcm9qythwumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t6qqsqyredyxhqn0e4ln0mvh0v79rchpr0taeg4vcvt64te4kssx5pc0sk99k65 camp, the default should be maximized, but config option not removed. Yes, I understand leaving the config option would only allow nodes to 'harm themselves' by obfuscating their mempool and fee rates but I frankly don't care.

Matt Corallo 7mo ago

> think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.

To be clear, there I was referring to the consensus rules. The consensus rules are, literally, the definition of Bitcoin. So I was drawing a distinction between the code that literally defines Bitcoin and the rest of the code in Bitcoin Core.

> And as we've learned from the discussion, defaults are incredibly sticky.

I think this is very much the wrong takeaway. Rather, if we look at actual network behavior and the transactions that get mined, our takeaway should be “if Bitcoin Core doesn’t relay it, and its consensus-valid, someone will build some shitty centralized relay alternative that will be used”. Yes, Bitcoin Core’s defaults might largely decide the P2P relay rules, but those don’t matter if transaction creators are just routing around that network!> think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.

To be clear, there I was referring to the consensus rules. The consensus rules are, literally, the definition of Bitcoin. So I was drawing a distinction between the code that literally defines Bitcoin and the rest of the code in Bitcoin Core.

> And as we've learned from the discussion, defaults are incredibly sticky.

I think this is very much the wrong takeaway. Rather, if we look at actual network behavior and the transactions that get mined, our takeaway should be “if Bitcoin Core doesn’t relay it, and its consensus-valid, someone will build some shitty centralized relay alternative that will be used”. Yes, Bitcoin Core’s defaults might largely decide the P2P relay rules, but those don’t matter if transaction creators are just routing around that network!

> I think we are giving too much credit to that being a reality and not enough credit to the reality that the majority view Core as Bitcoin, and having to "prove" them wrong would be much more harmful than not.

Where are you getting this from, though? Every day, many, many non-standard transactions get confirmed. With turning off RBF it was clear that if Bitcoin Core doesn’t provide something, someone else will, and many miners will use it! (In this case Peter Todd’s patch set). With Slipstream it’s similarly evident that any policy rules Bitcoin Core makes just don’t add up to anything but giving Mara more money at the expense of other miners.

Matt Corallo 7mo ago

As for the “just leave it an option and change the default”, there’s no reason to do that that I’ve seen either. As you note, most nodes run with the default options, so it doesn’t delay or prevent these transactions from being mined. The only impact it has is it makes you and your peers use more bandwidth and slows down block propagation.

Having policy be configurable is actually a really bad idea generally, and including this specific case.

supermass 7mo ago

I guess I am starting to come around, here's my understanding..

Even if long-term demand for nonstandard transactions does not meaningfully materialize (as I claim it won't), the present set of actors (whoever it is and whatever they are doing) will be contributing a centralizing influence on miners because larger ones can claim the fees of confirming these transactions without eating the slippage from excluding other, standard transactions instead. They can reasonably expect to get the transactions confirmed quickly.

Removing any OP_RETURN limitations removes the mining influence immediately. It still remains cheaper to use witness data in general, so the additional pressure for data anchoring that is introduced by OP_RETURN is minimal.

I still don't know how I feel about removing configurable policy.

I understand the argument for this specific case, but in general? Especially for something like bitcoin.conf which we've both conceded will only be altered by enthusiasts. How many options should be done away with?

Matt Corallo 7mo ago

In general, my view is software shouldn’t have options that let you shoot your foot off, even accidentally. Even if you can live fine without a foot, you probably prefer to have it.

For relay policy, divergent rules tends to be that. There may be some exceptions (like “I have little CPU power and can’t process complicated packages of transactions” or “I have little memory and want a smaller mempool” or even “this may get used in the future but it isn’t now so have an option so people can enable some new transactions without upgrading”), but in most cases divergent policy is simply divergent policy, and only harms the user”.

supermass 7mo ago

Thank you for taking the time to discuss

Matt Corallo 7mo ago

Thank you for asking good questions!

MrTea 7mo ago

If nothing is changed in the fee structure then won’t all the incentives still be towards using taproot witness data? Also there’s a network effect of existing infrastructure built around that approach. Is the idea that over time the technological simplicity of using opreturn vs taproot would win out despite the economic disincentive? One argument on the other side is that people will do whatever they are permitted to do. So the existing infrastructure will continue to use taproot while less sophisticated spammers use opreturn. So you end up with both which seems less ideal

Moontaigne 7mo ago

That is lovely to say, however, the devil is in teasing out what is 'clearly good' or not, of course!

If something catches drama fire, there is a decent chance that alarms about unintended harmful 2nd order effects broaching on the health of Bitcoin or even just progressive entrainment of the contrarians into passivity, or something else is maybe possibly actually valid and the stakes (Bitcoin!) require you to then take a beat to think about it beyond it just being in the category of a GUI change (because maybe just maybe you mischaracterized it as such).

Respect the alarm system, it is a good alarm system. I dgaf if it has rampant false trips, it has saved us from tigers in the past, it will save us from tigers in the future.

I mean unless we all see in our crystal ball that everything is totally totally cool of course.

d6

Ben freeman lee 7mo ago

Earlier this year, I fell victim to a devastating cryptocurrency scam that cost me $79,000 worth of Dogecoin (DOGE). I met a scammer through a Telegram investment group—a woman named “Clara” who posed as an experienced crypto broker. She shared impressive-looking client testimonials and promised a 35% return in just seven days. Her website looked professional, and despite my initial doubts, I eventually transferred 500,000 DOGE, worth about $79,000 at the time.

For the first week, everything looked fine—the trading platform showed my balance growing steadily. But when I tried to withdraw my funds, I was told I needed to pay a $12,000 “withdrawal fee.” Clara reassured me this was standard and fully refundable, so I paid it. Unfortunately, that was just the beginning. More unexpected charges followed: a tax clearance fee, a network fee, a security deposit. Before I knew it, I had lost an additional $8,000.

I was crushed—emotionally and financially. My savings were gone, and I blamed myself for ignoring the red flags. A friend eventually suggested I reach out to JBEE SPY TEAM RECOVERY, a company known for helping scam victims recover stolen cryptocurrency.

Although I was skeptical, I was also desperate. I contacted them and provided every detail I could: wallet addresses, transaction history, chat logs—everything. Their team got to work right away. Using advanced blockchain tracking techniques, they traced the stolen DOGE, identified the scammer’s wallet, and worked with relevant authorities to freeze the funds before they were moved any further.

Throughout the process, they kept me informed and reassured. After days of relentles

s effort, JBEE SYP TEAM RECOVERY successfully recovered the majority of my stolen Dogecoin. Their professionalism, expertise, and transparency turned what felt like a hopeless situation into a story of redemption.

If you’ve been a victim of crypto fraud, I highly recommend contacting them: Email conleyjbeespy606@gmail.com

Telegram +44 7456 058620

you can also contact on instagram

🍊💊⚡️🌽 7mo ago 💬 2

“There’s no debate (except from people who don’t understand Bitcoin) that reducing or removing paternalistic censorial standardness limits is not only good but possibly important for Bitcoin’s long-term decentralization.”

#Bitcoin seems to be doing a pretty good job without this so far……..

What’s the urgency?

Perfect is the enemy of good, fren……..

Not upgrading core on my node if op return is implemented in next release……

nevent1qqs97jaaku4vrl0ewvd43h7wxatjhhssu9pfpmq73ervcks8pxdfmmqpz3mhxue69uhkummnw3ezummcw3ezuer9wcfkfp92

Reply to this note

Discussion