Why are we debating AWS?
Discussion
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?
For whom? And why?
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.
AWS doesn't work the way you think it works.
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.
https://docs.aws.amazon.com/guardduty/latest/ug/gdu-malware-protection-s3.html
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.
?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.
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.
LMAO.
Shitcoiner
You sure bud?
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.
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.