OK, this guy is out of control. Some of his posts look like he knows what he's talking about but many of them are just text-spun & "humanized" versions of the posts they are quoting.
BADEROLet's start with the most recent one, which is just a reconstructed version of the post he is replying to:
I'm afraid this PR is a lot worse than what it appears at first. It is not just removing the OP_RETURN limit (which is bad enough on its own since bitcoin is not a cloud storage!), but also it is removing the option user had to set/change that limit as well. In other words if this PR is merged and if you run the next version of bitcoin core you will no longer be able to choose which OP_RETURN size you want to relay (that choice should be yours to make), and instead you will be forced to use what the default setting is!
In fact things like this are the reasons why I've argued for the benefits of having a strong alternative implementation of the Bitcoin protocol to be used instead of core... At some point when the core devs keep refusing to fix exploits like what allows the Ordinals Attack to take place and then limit users' ability to set their own standard rules, the benefits of having an alternative implementation outweighs the disadvantages of it...
To be honest, this PR is worse than it first appears it eliminates not only the OP_RETURN size limit, which is already dubious because Bitcoin isn't designed to be a cloud storage service, but also the node operators' ability to set that limit themselves. That is significant until now, the -datacarriersize option allowed users to specify the type of data they wanted to relay. You will have no choice but to accept whatever default Core decides if this PR is merged. A decentralised system shouldn't operate that way
This directly connects to the bigger issue Core developers have demonstrated a lack of willingness to handle spam like attacks (such as Ordinals) and now they are also limiting the options available to node operators to defend against such misuse. For this reason, I've been arguing for some time that we need significant alternative Bitcoin implementations, not just as a backup plan but also as a practical check on Core's centralised decision making.
The post is pretty much just a text-spun version of pooya87's post with a "humanizer" involved, which messes with the punctuation and capitalization. It is not exactly plagiarism, and it doesn't
seem to be AI-generated either. Nevertheless, it should be deleted as spam as its not saying anything new.
#2 - Here is a post that is AI-generated but uses a "humanizer" to make it worse, lol:
It’suncommon and possibly worrisome if two ECDSA signatures produce identical u1 and u2 values during verification even though their r values differ since u1 = z / s mod n and u2 = r / s mod n in ECDSA, both u1 and u2 must match for the s values and the ratios z/s and r/s to produce the same result in both signatures you mentioned that the r values differ, which suggests that either the signatures were generated incorrectly or with forced equivalence, or the same s was used (which is uncommon and dangerous if it comes from reused nonces k) this behaviour is abnormal for standard ECDSA signing and may indicate improper implementation or reused randomness it may be intentional if you are intentionally simulating or creating signatures (for example, by granting access to only the public key)however, if this happened during actual signing it is worthwhile to audit your signing procedure for security vulnerabilities
When the grammar is fixed:
It’s uncommon and possibly worrisome if two ECDSA signatures produce identical u1 and u2 values during verification, even though their r values differ. Since u1 = z / s mod n and u2 = r / s mod n in ECDSA, both u1 and u2 must match for the s values, and the ratios z/s and r/s to produce the same result. In both signatures you mentioned that the r values differ, which suggests that either the signatures were generated incorrectly or with forced equivalence, or the same s was used (which is uncommon and dangerous if it comes from reused nonces k), This behaviour is abnormal for standard ECDSA signing and may indicate improper implementation or reused randomness. It may be intentional if you are intentionally simulating or creating signatures (for example, by granting access to only the public key). However, if this happened during actual signing, it is worthwhile to audit your signing procedure for security vulnerabilities.
Copyleaks: 100% AI-generated
GPTZero: 79% AI-generated
Sapling: 100% Fake
#3 - This one is so bad that he repeats the same run-on sentence twice:
Exactly you’re right Bitcoin Core can automatically determine and distribute the optimal number of CPU threads based on the system's available cores when par=0 is set by default setting a negative value, such as par=-1, instructs Core to (use all cores except one leave one free for other system tasks) This is more intelligent since it maintains the device's responsiveness, particularly if it is executing the node while performing other tasks in summary you're right unless you have a very specific performance tuning goal, it's usually not necessary to manually set par=N for the majority of users, the automatic behaviour (default par=0) is sufficiently optimised
In summary you're right unless you have a very specific performance tuning goal it's usually not necessary to manually set par=N for the majority of users the automatic behaviour (default par=0) is sufficiently optimised
He has a lot of other posts like this. I don't think he actually knows anything about Bitcoin but has mastered the art of pretending to not use AI, lol.