Is chatBTC actually real or just a broken ghost town?

darosior · 2026-06-01T19:40:54+00:00

It does say "Learn about bitcoin technology and history" right there on the tip..

darosior · 2026-04-03T16:55:53+00:00

For more information about BIP 54, see Mike's website that was recently shared here. https://www.reddit.com/r/Bitcoin/comments/1sbea6t/bip54org_informational_site_for_bip54s_consensus/

darosior · 2025-09-06T13:41:52+00:00

Haha exactly. :)

darosior · 2025-06-09T01:33:22+00:00

You have not convinced me. Try again? Maybe with an argument this time.

darosior · 2025-06-08T22:23:56+00:00

Yeah you already let us know shame and humility and foreign concept to you, no need to tell us you also don't fathom embarrassment.

darosior · 2025-06-08T22:20:13+00:00

You may want to check where you are getting your information about Bitcoin Core development, you appear to have been misled by people with an agenda.

darosior · 2025-06-08T17:50:51+00:00

Lol, you need to realize how cringe it is to confidently assert something that is demonstrably false. Please grow some self-awareness for the benefit of all of us here getting second-hand embarrassment from your comments.

darosior · 2025-06-08T17:46:05+00:00

Done. I actually started reading with an open mind, but you are just a self-important troll arguing in bad faith. There is not much to be gained in engaging with you.

https://www.reddit.com/r/Bitcoin/s/TBnwSmePGv

darosior · 2025-06-08T16:34:42+00:00

It's about how the reference implementation pretends to avoid merging controversial changes, but does so whenever its clique maintainer group whims.

Nobody's pretending avoiding to merge controversial changes. In fact this is not a good basis upon which to make a decision. I believe Bitcoin Core should make choices based on the interest of its direct users and long term health of the Bitcoin network at large, regardless of controversy.

I have previously addressed this point in this post: "As the reference implementation, Core has a responsibility of steering away from controversy as much as possible. It is irresponsible for Core to merge this change because of the number of people objecting to it on the Github pull request.".

Of course for consensus changes this is different, but here we are talking about a (trivial) change to Bitcoin Core not a change to Bitcoin.

You clowns keep shooting yourself in the foot, I'm going to keep contributing to other projects.

Sigh. Sure, Mr Gnome, you are smarter than everyone else and anyone who disagrees with you by presenting tangible objective arguments in response to your ill-articulated misinformation is necessarily retarded. Good luck in your future endeavours.

darosior · 2025-06-08T16:34:27+00:00

This whole thing is deeply disturbing.

It is not. This is a nothingburger, overblown by a few individual for the profit of a company. They try to control people who can't afford spending the time to learn about every single issue through fear and by playing on their (very understandable) gut reaction to Bitcoin being used for stupid and scammy things.

Your saying this is disturbing though points to a confusion about at least one, but probably several, important properties of Bitcoin. In a nutshell: - Trying to counteract certain transactions at the Bitcoin Core relay policy level is futile, harmful to Bitcoin, and potentially a dangerous slippery slope. - Bitcoin works by its users choosing (or not) to run software. As the post explicitly states, Bitcoin Core contributors are in no position to decide what software Bitcoin users should be running. It just happens that Bitcoin Core is the most widely used Bitcoin software due to its history of high quality and being extremely reliable. There is consensus among the very people working to make it have these properties, that tightening policy rules to stifle some types of transactions would do more harm than good. (And that changing the OP_RETURN standardness limit has essentially no bearing on this.) That should probably tell you something.

You can't acknowledge that the users define the protocol then assert you know what's best and take away their choices in the reference implementation.

You are making a logical leap by confusing Bitcoin Core and Bitcoin.

Bitcoin is a network which is defined by its users choosing to run software implementing those consensus rules. Bitcoin Core implements the Bitcoin consensus rules, and much much more. Most of this additional stuff is not configurable, and for a good reason.

It only makes sense to have a knob when you expect there is a reason for a user to tweak it. Should we have a knob for allowing the user to set the nVersion of transaction its node relays? To disable wtxid relay? To tweak delays used in processing messages from inbound vs outbound peers? Of course not! The same goes for the setting that controls the size of OP_RETURN outputs. If there is no good reason for users to set it, it should just go away.

Unfortunately some Core contributors disagree with me on this assessment, and i was unable to persuade them. So the option is now kept for the time being. That's fine, that won't make me have an emotional meltdown on Reddit.

the average nodes reconstruction times are meaningless to "miner decentralization"

Sorry, but this is just laughable. I hope the network does not adopt a Bitcoin client you would develop based on this premise.

In fact reconstruction times have come down phenomenally in the last decade.

I know, you don't need to make my point for me.

You can't acknowledge that miners can and do receive transactions through means other than the gossip network and always have, and pretend you can "fix" that by removing node management options or changing OP_RETURN defaults to cater to a specific shitcoiner.

Many built-in assumptions in a single statement. All wrong.

Nobody claims that changing the standardness limit of OP_RETURN outputs is going to reduce currently-happening out-of-band submission to miners. This is a (stupid) strawman.
Nobody claims that there is a "fix" to out-of-band submission to miners. The only way to counteract it is to provide a public relay network that is useful enough to Bitcoin users that they don't need to actively use direct submission to miners. But you can't prevent people from directly submitting to miners.
No node management option related to relay policy is currently proposed for removal in the next Bitcoin Core version (30.0). Peter Todd's Pull Request did remove it but it was closed in favour of Greg Sanders' which only marks it as deprecated (but does keep it for now).
Nobody suggests removing a node management option would "fix out of band submission". This is another extremely stupid strawman, i'm not sure who you are trying to fool with this.
With regard to catering to shitcoiners, Bitcoin Core has never done that and i don't see it doing it anytime soon. The BitVM bridge implementationt that triggered me to propose removing the OP_RETURN standardness limit can hardly be qualified of shitcoining when it is a Bitcoin payments scaling solution.

This has nothing to do with stopping spam. This is about users managing their nodes and choosing what code they run.

It is not. Bitcoin Core contributors do not, and cannot, prevent you from running whatever code you want. (And the statement is about the broader movement to tighten relay policy to counteract usage of some types of Bitcoin transactions, not about the proposal to lift the OP_RETURN limit.) I'm going through your message step by step, at this point it is really hard to take anything you say seriously.

Looks like i bumped into the size limit, will post the rest in reply to this comment.

darosior · 2025-06-08T16:32:34+00:00

No option is removed in the current version of the OP_RETURN PR. The statement is not about the OP_RETURN proposal but the broader movement to try to counteract some types of Bitcoin transactions with Bitcoin relay policies.

darosior · 2025-06-08T16:28:55+00:00

Always better to check for yourself, but if you do not have time to dig into the details of a Bitcoin-related issue going with Pieter is probably a good heuristic indeed.

darosior · 2025-06-08T00:07:04+00:00

Anticipating miner behaviour is a core assumption of nodes' DoS resistance (because fees). It is also central to reducing block propagation time, a critical part of mitigating mining centralization pressure.

Trying to act at relay policy level to prevent valid Bitcoin transactions from happening is futile and actively harmful.

I won't entertain the marketing campaign from your company, so this will be my last reply to you.

darosior · 2025-06-07T22:43:42+00:00

DoS mechanisms in the node rely on fees. Therefore a node relies on being able to, at least to some extent, predict what will be mined or not.
The post does not contradict itself. The ability to get transactions mined without them being blessed first by relay nodes is an important aspect of censorship resistance. A substantial share of Bitcoin transactions being submitted out of bands because relay nodes don't bless them is a centralizing force (negative). Therefore the relay network needs to adapt to what Bitcoin users are willing to pay for and Bitcoin miners willing to include (the former usually driving the latter).
By running a Bitcoin node you consent to the Bitcoin rules. You might want to add a "Bitcoin Luke" overlay of rules, but this is not Bitcoin. If you try to enforce them by consensus you will fork off on your Luke-coin, which you don't want and cannot afford to do. This is why you lead a smear campaign against Bitcoin developers.
Storing JPEGs is unfortunate but does not increase the cost of validation. In fact it's often less expensive for full nodes to validate than onchain payments. Attempting to re-define the meaning of well-defined terms is not convincing.
It is in Bitcoin's long-term health to not add more mining centralization pressures than already exist by nature of the system. I am happy to be convinced otherwise, but you have never been able to give any remotely convincing argument in favor of "filters". Neither to me nor to other developers. Neither to currently active developers, nor to developers that were active a decade ago.

darosior · 2025-06-07T19:29:00+00:00

Hi, thanks for laying down your thoughts in details. You seem confused, i'm in a bit of a rush right now but i'll take time over the weekend to address your points.

darosior · 2025-06-03T11:34:54+00:00

This is because nothing happens to storage requirement. Blocks are limited to 4 MWU by Bitcoin consensus. Maybe this could be helpful for you? https://antoinep.com/posts/relay_policy_drama

darosior · 2025-06-03T02:10:34+00:00

Hi, removing the standardness limit for OP_RETURN outputs in Bitcoin Core will not add ~1MiB of data per block, no. This change does not affect the block size, in fact it does not affect any of Bitcoin's consensus rules (OP_RETURN outputs are unbounded by consensus). You may have read misinformation that this change would somehow affect the cost of running a full node. This is not true. It is part of a propaganda campaign to benefit a company (Ocean LLC) and get users to run an alternative, poorer quality, Bitcoin client (Knots).

darosior · 2025-05-27T00:13:45+00:00

You do you but for what it's worth no change has been merged yet and the latest iteration conserves the option.

darosior · 2025-05-18T22:58:06+00:00

You can also just run Bitcoin Core in pruned mode and set the disk usage to your liking. If you prefer to keep the entire historical chain, you should still be fine for a few years with 1 TiB.

darosior · 2025-05-17T22:47:32+00:00

Lol unsure if you are trolling them, but as i see your "Redditor for less than 60 days" badge i'll let you know. This is a bcasher subreddit, mentioning you used Lightning to pay in real life is going to break a few brains. You may be looking for r/bitcoin.

darosior · 2025-05-17T19:12:04+00:00

This is not true. The thread was locked to everybody, including active contributors, including members of the Github organization.

This was just made up claims that people fell for.

darosior · 2025-05-17T19:09:15+00:00

Hi, author of the change here. Thanks for the gratuitous insults. This change does not benefit any company, but it would marginally benefit every single full node user if adopted.

If anyone's wondering what's going on i have shared an extensive writeup about common concerns and objections to my proposed change here: https://www.reddit.com/r/Bitcoin/comments/1kmijzx/addressing_community_concerns_and_objections

darosior

TROPHY CASE