He went off the deep end. Effen crazy.

Yeah? Sounds like a good argument. Jimmy song too? Samson Mow?

BDS

Why?

Bad actor?

@npub1s33s...252p has a long history of being a bad actor in the Bitcoin space. He has so many videos discussing the virtues of Bitcoin and why people should adopt it. Have you seen his views on freedom? The guy actually thinks I should be free to run whatever FOSS software I want on hardware I own. He's also advocating for running alternative software if I agree with his position. Not by force, but by choice! Can you believe it? What a bad actor.

Its you who should not be taken seriously.

Wrong

Yeah… all of that while FUDing an defaming all the way through. You bad actor too?

Indeed! I check with the core team They said “he is retarded” CHECKMATE! View quoted note →

I love a good appeal to authority instead of a break down of the actual arguments.

Who's authority? I have my own node impl better than knots or core.

GitHub

GitHub - average-gary/bitcoin-garrys-mod: Bitcoin Garry's Mod

Bitcoin Garry's Mod. Contribute to average-gary/bitcoin-garrys-mod development by creating an account on GitHub.

You should run it.

Jimmy knows what a IDE is. Not so sure about Samson. He seems clownish.

Defaming? Sounds like a statist to me.

Maybe I will!

Outside of the inflooenser yada yada. Are we saying that the Read-only containers that AWS hosts DOESN'T scan for malware? Because that would be a very big attack surface for them. If so, would not the contiguous bytes of a malware file not fit the fingerprint of the fuzzy hash digest they would check against? Meaning rightly or wrongly, they would assume the transaction being verified is a malware executable and kill the VM? Is that truly not an attack vector? I kind of don't even understand how that's not within the realm of possibility. Again I AM NOT SAYING THE MALWARE IS EXECUTABLE. Just that the fingerprint could read as such to the hypervisor watchdog.

Stenography and data obfuscation to avoid malware detection is a pretty well understood concept in cyber security. Red teams across the globe easily hide malware in all kinds of arbitrary places. And if you're deploying a payload of malware, it doesn't need to be contiguous. BREAK llama 3 reply below about non-contiguous data and malware. Yes, there have been several historic malware campaigns that leveraged non-contiguous data to deliver a payload and bypass detection. Here are a few examples: Stuxnet (2010): Stuxnet was a highly sophisticated computer worm that targeted industrial control systems, particularly those used in Iran's nuclear program. It used a technique called "data hiding" to conceal its payload within non-contiguous areas of the hard drive, making it difficult to detect. Duqu (2011): Duqu was a malware campaign that used a similar technique to Stuxnet, hiding its payload in non-contiguous areas of the hard drive. It also used a "dropper" file to load the malware into memory, making it harder to detect. Flame (2012): Flame was a highly complex malware campaign that used a technique called "fragmented malware" to deliver its payload. It broke its payload into smaller, non-contiguous pieces and stored them in different locations on the infected system, making it difficult to detect. Havex (2013): Havex was a malware campaign that targeted industrial control systems, particularly those used in the energy and manufacturing sectors. It used a technique called "data fragmentation" to break its payload into smaller, non-contiguous pieces and store them in different locations on the infected system. BlackEnergy (2015): BlackEnergy was a malware campaign that targeted industrial control systems, particularly those used in the energy sector. It used a technique called "non-contiguous memory allocation" to load its payload into memory, making it harder to detect. NotPetya (2017): NotPetya was a highly destructive malware campaign that used a technique called "kernel-mode rootkit" to hide its payload in non-contiguous areas of the hard drive. It also used a "dropper" file to load the malware into memory, making it harder to detect. These malware campaigns demonstrate the use of non-contiguous data to deliver a payload and bypass detection. They often employed techniques such as: Data hiding: Concealing the payload within non-contiguous areas of the hard drive or memory. Data fragmentation: Breaking the payload into smaller, non-contiguous pieces and storing them in different locations. Non-contiguous memory allocation: Loading the payload into non-contiguous areas of memory. Dropper files: Using a separate file to load the malware into memory, making it harder to detect. These techniques made it challenging for traditional signature-based detection methods to identify the malware, and highlighted the need for more advanced detection methods, such as behavioral analysis and anomaly detection.

Right... Again I am not talking about activation or deployment... The point is FOR the malware to be found. THAT is the attack. The reflexive response. I don't care about embedded data, steganographic or otherwise. You literally CAN'T put contiguous bytes together to trip Malware detectors now because of the PUSHDATA limit (unless Side-channeled obvsly).

Also, can we not throw AI outputs at each other? Especially when it completely misses the point the other person is making?

It's fairly easy to evade existing malware signature detection. It's whackamole.

My point was contigousness of data is irrelevant.

Why are we debating AWS?

Because 29% of BTC nodes are hosted on AWS. This signature detection would kill the VMs running Core on those servers. Meaning 29% of the network suddenly goes offline.

And my point was that it IS relevant to the point I was making. Which again, is not "malware activating due to blocks having packages embedded in them" My point is if you want to shut the airport down you don't hide the gun, you wave it around so everyone can see.

This misses my point.

Speak plainly. What's the point?

So is bitcoin the airport in this analogy?

And?

Yes, in this analogy, the bitcoin network would be the airport. The malware would be the gun.

What's the risk?

For whom? And why?

We only need one node for bitcoin to survive. It's not ideal but it would still work

AWS doesn't work the way you think it works.

?WAIT. ARE YOU SAYING PEOPLE USING A CENTRALIZED PLATFORM FOR BITCOIN ARE AT RISK IF AWS SUDDENYL DISLIKES BITCOIN. SOMEONE SHOULD FIX THAT.

Absolutely. But there's ownership risk then there's intentional disruption. I mean if someone found an exploit to target node runners through their specific ISP *cough* Shinobi *cough* that would also be bad and tough to mitigate.

I am not talking existential. I am talking adoption progress.

For exchanges that use them for feerate, for economic nodes for transaction broadcast utility, for miners for gossip relay, kind of a lot of things.

It absolutely does. I have pulled their docs many times to show their guard dog service kills VMs if malware is signature identified. I feel like you may be thinking first order effects and not secondary and terceary effects. I swear I am not as dumb as I look, and I don't take Luke, Mechanic, Murch, Antoine, Voskiul, or any other dev or talking head at face value. I take what they say and check it for validity.

How do you scan encrypted content, genius?

When you have to validate the content, also genius.

Nodes don't validate OP_return content, moron.

Oh, you don't know what you are talking about, cool.

GuardDuty Malware Protection for S3 - Amazon GuardDuty

Learn how to use GuardDuty Malware Protection for S3 to detect if a newly uploaded file to your selected Amazon Simple Storage Service (Amazon S3) ...

These docs? And we've gone over the whackamole with malware signatures. My previous company worked the red team for DoD. I promise you don't understand the cloud like you think you might. I also welcome all AWS bitcoin nodes failing. My sats remain safe.

Damn, cold Gary.

LMAO. Shitcoiner

You sure bud?

GitHub

bitcoin/src/script/solver.cpp at 919e6d01e93a57d991ed456bc67c43605583ada8 · bitcoin/bitcoin

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

We're soft as a society.

Yes. "We don't care" doesn't mean "bytes not read" on validation. The bytes don't magically disappear. They are pruned post script read.

Can you show me what lines of code read the OP_RETURN data?

This actually took we quite a while because the serialization, Output definitions, and where it is added to the output stream is like 4 different files. SERIALIZE_METHODS is a macro that writes both nValue and scriptPubKey(including the OP_RETURN and all its data push to the transaction output stream.

GitHub

bitcoin/src/primitives/transaction.h at 919e6d01e93a57d991ed456bc67c43605583ada8 · bitcoin/bitcoin

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

💯💯 Looking forward to the crash out. can we get a pool going on the date?

Need to unpack that macro more

Just think logically, if the data is retrievable later (the whole point of saving the arbitrary data in the first place) it has to be saved somewhere and passed to the next node. Yes, for the purposes of creating and parsing UTXOs the OP_RETURN data is not needed but, it is still read and written to memory.

Right be what are you deserializing as indicatea the intent. There is already case law on this.