I’m not bending the knee to anyone 🤣 I will run old versions of core until there is an alternate implementation not run by the lunatic with the gas mask in the pic below But keep harassing people that do not want to change bitcoin with you retards…you guys are really winning everyone over

And you are certainly not acting like adults 🤣

You are running a software implementation developed by even bigger lunatics, some of whom visited Epstein’s island or ran creepy designer baby programs for him in secret. But you keep claiming the moral high ground, you’re doing great. 👍

Reading comprehension is not your strong suit Again I want an alternate implementation from people not associated with core or knots because both suck and have issues Meanwhile you bip110 guys are sounding more and more like the bitcoin cash retards always yelling about Epstein and CSAM

I have many differences with Luke, but in this case, and generally when it comes to Bitcoin, he is right.

> Again I want an alternate implementation from people not associated with core or knots Fair enough, I just pointed out that you choose the objectively worse option among the two. Mind you the current crop of Bitcoin devs has shipped all versions of Core since v25 and I doubt you’re running an earlier version. If you’re, then you’re running a software full of bugs and vulnerabilities. We bip110 advocates don’t want to change Bitcoin like Bcashers did, we want to return Bitcoin to a more sane state before the capture, while preserving node runners resources in the process. Bcashers didn’t give two shits about node runners. You’ve been eating core’s propaganda for quite a while. Anyway, peace. ✌️

I’m a 38 year old child psychopath and not gonna apologise for being one. 🤙

Well we share the same age 🤣 Again I think we all want bitcoin to succeed as money. I prefer to be conservative and feel we already have a mechanism to defend against spam. That mechanism is called transaction fees. The folks spamming the chain will run out of bitcoin It is a free market though so you guys are free to run whatever implementation you want as long as it does not violate consensus and if it does you will be forked off so that is the risk you choosing to take.

running 29.0

Why?

The proposed solution seems worse to me than the problem. Problem(s): nonmonetary data on chain; TapRoot seems to have introduced unknown, unknowns Proposed solution: temp softfork, limiting rules with only 55% signal threshold; with a very small client dev team maintaining code; some supporters claiming its an *emergency*, and even hinting at legal threats to devs/miners/others who don't join their team

The proposed solution seems worse to me than the problem. Problem(s): nonmonetary data on chain; TapRoot seems to have enabled unforeseen non-monetary use cases Proposed solution: temp softfork, limiting rules with only 55% signal threshold; with a very small client dev team maintaining code; some supporters claiming its an *emergency*, and even hinting at legal threats to devs/miners/others who don't join their team

The proposed solution seems worse to me than the problem. Problem(s): nonmonetary data on chain; TapRoot seems to have enabled unforeseen non-monetary use cases Proposed solution: temp softfork, limiting rules with only 55% signal threshold; with a very small client dev team maintaining code; some supporters claiming its an *emergency*, and even hinting at legal threats to devs/miners/others who don't join their team

The proposed solution seems worse to me than the problem. Problem(s): nonmonetary data on chain; TapRoot seems to have enabled unforeseen non-monetary use cases Proposed solution: temp softfork, limiting rules with only 55% signal threshold; with a very small client dev team maintaining code; some supporters claiming its an *emergency*, and even hinting at legal threats to devs/miners/others who don't join their team

nonmonetary data on chain > dilutes monetary premium and the main usecase for Bitcoin > bloats the timechain > burdens every node’s resources > creates legal/moral issues for each participant > creates centralising pressure temp soft fork > means conservative and careful deployment only 55% signal threshold > you can thank centralised mining for that, even one pool can veto the change if higher very small dev team > just like core, read hodlonaut’s Capture articles it’s *IS* an emergency and downplaying it as not is also a problem the legal threats will come from the establishment and the enemies of Bitcoin, not by the plebs, this one seems pretty easy to foresee

Does BIP-110 *band* scripts that in part are used for financial transactions? Why? Does a given Knots version stop working after two years? Why?

Does BIP-110 *band* scripts that in part are used for financial transactions? Why? Does a given Knots version stop working after two years? Why?

BIP110 doesn’t impact any financial transactions. There have been done multiple tests and simulations in this regard, so unless someone is purposely trying to trigger some known check, there’s 0.01% chance your normal financial transaction to be impacted in any way. Knots indeed stops working in 2 years if you haven’t been doing any updates in this period. This is basic housekeeping to make sure your software is secure from bugs and vulnerabilities. It’s only your money on the line, so I don’t see the issue here exactly.

Why do you post the same thing multiple times? 🤔

relay connect issues

With knots not working after two years, that is essentially forcing users to automatically upgrade. Not true for core. I can keep running 29.0, for as long as I want.

Per Maple AI, kimi k2.6: "Yes, BIP-110 would constrain certain Taproot scripts, and under specific circumstances it could render some UTXOs unspendable. **How it constrains Taproot scripts** BIP-110 proposes (among other things) to make the following invalid in tapscripts for blocks mined after activation: - **`OP_IF` and `OP_NOTIF`**: These opcodes would be disallowed entirely in tapscript, even in branches that are not executed. - **Large control blocks**: Taproot control blocks larger than 257 bytes would be invalid — this effectively caps the Taptree at 128 script leaves. - **Large data pushes**: Data pushes greater than 256 bytes would be invalid. **Could this make UTXOs unspendable?** Yes, but primarily for a specific edge case. BIP-110 includes a **grandfather clause**: UTXOs created *before* activation are exempt and can still be spent using old scripts. However, this protection does not fully cover: - **Pre-signed or timelocked transactions** created before activation but broadcast *after* activation. - UTXOs that rely **solely** on a now-invalidated script path (e.g., one using `OP_IF`) and have no alternative valid spending path (no key-path spend, no other valid tapleaf). If a Taproot output was constructed to force spending through a script leaf that BIP-110 invalidates, and that transaction is only revealed after activation, the consensus rules would reject the spend. With no valid path remaining, those funds would become unspendable for the duration of the softfork. This has led to criticism that the proposal risks a form of *de facto confiscation* for certain complex Taproot contracts, even though standard pre-activation UTXOs are technically grandfathered."

The point of not autoupdating is to avoid the risk of unforeseen bugs in the latest version that can incidentally knock you out of consensus. Not to make you easy pray for hackers. Imagine if your bank app didn’t update for years. But you can do it whatever you want, sure. It’s your money on the line after all.

No. I dont support Core version 30.0, by running 29.0. Luke or a small team of devs could *push through a consensus change* in knots that they are *sure* is best for the network. Forces users to follow without choice.

> Yes, but primarily for a specific edge case. As I said, 99.99% of users will never encounter such edge case. The other 0.01% had close to a year of prior notice to do something about it. If they are still impacted by this and that’s a big _IF_, they just wait 12 months until the soft fork expires and then they can again move funds. You can theoretically sabotage every BIP proposal by intentionally creating edge cases that violate checks to try and put a stick in the wheels. That doesn’t mean the rest of the network should be forced into a standstill because of this.

You really don’t understand how any of this works, do you?

Help me then: how is this wrong? ---> Luke or a small team of devs could *push through a consensus change* in knots that they are *sure* is best for the network. Forces users to follow without choice: after two years only the newest version works, right?

Who is gonna run this? I know I ain’t.

Changing consensus should be very very hard. Taproot upgrade was in retrospect probably not the right move. BIP-110 or the version - post one year - will also likely be problematic for issues that are currently hard to see/unforeseen. Default should be no change. Pushing this as an *emergency* or even an *urgency* is not based in facts and IMHO will be why BIP-110 fails.

I’m done interacting with you at this point. Good luck with everything.