<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Apr 12, 2026, 4:47 PM Adrian Tymes via extropy-chat <<a href="mailto:extropy-chat@lists.extropy.org">extropy-chat@lists.extropy.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Apr 12, 2026 at 12:22 PM Jason Resch via extropy-chat<br>
<<a href="mailto:extropy-chat@lists.extropy.org" target="_blank" rel="noreferrer">extropy-chat@lists.extropy.org</a>> wrote:<br>
> To John's point:<br>
><br>
> The halting problem implications are more severe than whether or not a task will finish, it includes not being able to know whether or not why block of code will ever be reached or not.<br>
><br>
> So it is not just whether a task finishes or not, but whether some function will be invoked or not, whether or not the machine will accept arbitrary inputs and test them as code, etc.<br>
<br>
I have run into the halting problem in practice, as knowing whether<br>
the program will halt.  Knowing whether a given function will be<br>
invoked...granted, this is a problem if you don't control the code and<br>
can't insert checkpoints.  When I'm developing some program, I<br>
generally can do that - though, as you note later, this is a specific<br>
case, not the general case.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">True. Though even with knowledge of the control flow and setting debugging break points, knowing what methods may be called isn't always trivial. Consider this block of code:</div><div dir="auto"><br></div><div dir="auto">x = 4;</div><div dir="auto">while (true) {</div><div dir="auto">   if (isGoodbachCounterExample(x)) { break; }</div><div dir="auto">   x += 2;</div><div dir="auto">}</div><div dir="auto">print x;</div><div dir="auto">foo();</div><div dir="auto"><br></div><div dir="auto">We don't know if foo() will ever be called because mathematicians don't yet know whether there exist any counter examples to Goldbach's conjecture.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> To Adrian's point:<br>
><br>
> There is much that can be done to minimize an attack surface, such as only connecting to trusted machines, validating input, using firewalls, activating the NX (no execute bit) to prevent arbitrary code execution, etc.<br>
<br>
Indeed, and it rather annoys me when people assume, imply, or outright<br>
declare that just because most people don't do that, nobody can ever<br>
do that - with the resulting massive advantage to any attacker.  I did<br>
that as part of my early career, and it is well known that people tend<br>
to get offended when you try to tell them that the life they<br>
personally experienced could not have happened (absent any evidence of<br>
a mechanism for false memories).<br>
<br>
> As to the halting problem implications, note that it is not the general case (any arbitrary programs cannot all be predicted), but the key word is general. There are software validation tools that can for limited specific cases, prove correctness, by brute force iterating over every possible program state.<br>
><br>
> That said, any modern operating system is far too complex a beat to run correctness provers against. Even if you were to only run one piece of proven software on some server, how do you know there is not an exploitable bug in the DNS, NTP, TCP/IP stack, firewall, TLS library, SSH, or any of the hundreds of other software libraries on which the server software and operating system depend?<br>
<br>
indeed.  Perfect cybersecurity for any sufficiently complex system is<br>
not practical.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, I think this is John's argument. If super intelligent AI can find exploitable bugs in code written by less intelligent people or agents, then things may inevitably become an arms race between AI hardening code and more intelligent AI breaking it.</div><div dir="auto"><br></div><div dir="auto">The saving grace is that it seems to require a higher intelligence to find a bug than the intelligence required to introduce a subtle one that is unseeable by that lower intelligence. So once we use the current generation of AI to harden software in common use, it will require greater and greater leaps in AI to find exploitable bugs, and assuming the latest generation of AI is always put to task to fix things before being made available to break things then we might enter an era of stability.</div><div dir="auto"><br></div><div dir="auto">But he is right to be concerned, if Mythos or some future AI is a quantum leap beyond current ones, it will be in a position to find bugs which no other previous AI or human engineer was able to spot. Bostrom listed hacking as one of the superpowers of superintelligence:</div><div dir="auto"><br></div><div dir="auto"><a href="https://alwaysasking.com/when-will-ai-take-over/#Superpowers_of_Superintelligence">https://alwaysasking.com/when-will-ai-take-over/#Superpowers_of_Superintelligence</a></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, there is a world of difference between "an attack is possible<br>
at all" and "an attack is likely enough to seriously worry about", let<br>
alone "this particular attack will definitely happen any time now".</blockquote></div></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
John confuses these three.  The ability of AI to discover this many<br>
vulnerabilities does not by itself move us out of the first category,<br>
no matter how much John insists otherwise.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's unclear to me what fraction of code Mythos looked at, but let's say any given software library has only a 10% chance of being exploited. That would put the chance of any system being vulnerable to close to 100% given how many individual programs and libraries any given modern machine is likely to contain.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I think the Battlestar Galactica remake gets this right. They learned their machine enemy could remotely hack and disable their military ships. To counteract this tactic, the humans had to strip all networking from their computers.<br>
<br>
Yeah...and then, if it were reality, the Cylons could take advantage<br>
of the resulting massive latency in human operations to pick apart<br>
their ships.  Getting the enemy to remove their advantages willingly<br>
is itself a form of attack.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">True.</div><div dir="auto"><br></div><div dir="auto">I would say all security imposes a cost to implement. I had to spend probably 15 minutes today doing captchas and 10 minutes waiting on OTP codes to be sent to my phone today, and 5 minutes resetting passwords. Lots of time wasted and latency introduced.</div><div dir="auto"><br></div><div dir="auto">Jason </div></div>