Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Mon, 12 May 2025 22:30:46 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <00f3a128e8ac35841ece8b6b4a01d75449bede14@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvp1fm$3r5li$4@dont-email.me>
 <b049926b61baa5d69d11655a8af06e537b7acd71.camel@gmail.com>
 <vvqga9$gldn$3@dont-email.me>
 <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com>
 <vvql3p$gldn$15@dont-email.me>
 <cb999b6746607a1445c196e485a2c1124eaee8b5.camel@gmail.com>
 <vvqnev$i5d0$3@dont-email.me>
 <07c4f2302645a7e58957b5e5bffed80397a6ddae.camel@gmail.com>
 <vvr0ot$k9nu$1@dont-email.me>
 <04bd32e2a5572305de0376f9569172932ffb252f.camel@gmail.com>
 <vvr2ov$khl4$2@dont-email.me>
 <72f8c8295d3a0ff265a67b0de838516ade16c6d5.camel@gmail.com>
 <vvr6lj$lieg$1@dont-email.me>
 <8667c45172be6519444525c30d280cde06d77e2b.camel@gmail.com>
 <vvr8dj$lu2b$1@dont-email.me>
 <7281f97665272ea0eb85e56940648f6c807b0b8e.camel@gmail.com>
 <vvralq$me5h$1@dont-email.me>
 <f5a9ca0c0edaeb582b14c3babee27e25d41fc953.camel@gmail.com>
 <vvrgmf$n9a9$4@dont-email.me>
 <d3eedafd84b780cdb0bd63c8afd0aa92209136ab@i2pn2.org>
 <vvrk67$o2ab$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 13 May 2025 02:50:19 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="118633"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vvrk67$o2ab$2@dont-email.me>
Content-Language: en-US
Bytes: 5875
Lines: 101

On 5/11/25 9:51 PM, olcott wrote:
> On 5/11/2025 8:15 PM, Richard Damon wrote:
>> On 5/11/25 8:51 PM, olcott wrote:
>>> On 5/11/2025 7:33 PM, wij wrote:
>>>> On Sun, 2025-05-11 at 18:08 -0500, olcott wrote:
>>>>> On 5/11/2025 5:50 PM, wij wrote:
>>>>>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote:
>>>>>>> On 5/11/2025 5:11 PM, wij wrote:
>>>>>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote:
>>>>>>>> [cut]
>>>>>>>>>>> ZFC corrected the error in set theory so that
>>>>>>>>>>> it could resolve Russell's Paradox. The original
>>>>>>>>>>> set theory has now called naive set theory.
>>>>>>>>>>>
>>>>>>>>>>> I corrected the error of the HP that expects
>>>>>>>>>>> HHH to report on behavior that is different
>>>>>>>>>>> than the behavior that its input actually
>>>>>>>>>>> specifies.
>>>>>>>>>>
>>>>>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error?
>>>>>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes that is an error because the behavior that
>>>>>>>>> the input to HHH(DDD) specifies is the behavior
>>>>>>>>> that HHH must report on.
>>>>>>>>
>>>>>>>> If so, how do we know a given function e.g. D, halts or not by 
>>>>>>>> giving it to H,
>>>>>>>> i.e. H(D)? Wrong question (according to you)?
>>>>>>>
>>>>>>> H and D is too vague and ambiguous.
>>>>>>> We know that the input to HHH(DDD) specifies
>>>>>>> a non-halting sequence of configurations.
>>>>>>>
>>>>>>> We know that the input to HHH1(DDD) specifies
>>>>>>> a halting sequence of configurations.
>>>>>>>
>>>>>>>> Instead, every time we want to know whether D halts or not,
>>>>>>>
>>>>>>> When we intentionally define an input to attempt
>>>>>>> to thwart a specific termination analyzer THIS DOES
>>>>>>> CHANGE THE BEHAVIOR.
>>>>>>>
>>>>>>> If we let people run uploaded programs on our
>>>>>>> network we need to know if these programs are
>>>>>>> going to halt.
>>>>>>>
>>>>>>> Unless HHH(DDD) rejects its input as non-halting
>>>>>>> HHH will continue to eat up network resources.
>>>>>>
>>>>>> But, according to POOH, if D going to eat up network resources, it 
>>>>>> have to
>>>>>> happen when we run POOH(D), because you said D's halting property 
>>>>>> only
>>>>>> valid to H.
>>>>>>
>>>>>
>>>>> If we want to prevent this kind of denial of service
>>>>> attack HHH must be able correctly handle inputs that
>>>>> are trying to thwart it or HHH fails.
>>>>>
>>>>> When HHH is our official denial of service attack
>>>>> preventer it either rejects its input DDD as non
>>>>> halting or it gets stuck in recursive emulation
>>>>> thus fails.
>>>>>
>>>>> It always has been the requirement that a termination
>>>>> analyzer was required to report on the behavior that
>>>>> its input actually specifies.
>>>>>
>>>>> This is a subtle nuance of functions computed by
>>>>> models of computation that no one bothered to
>>>>> pay attention to because they didn't know it made
>>>>> any difference.
>>>>>
>>>>
>>>> Is DDD a virus?
>>>>
>>>
>>> If on a real system an input tried to fool the
>>> denial-of-service-attack detector IT WOULD FAIL.
>>>
>>> Prior to my work a denial-of-service-attack detector
>>> WOULD FAIL. It would not know to reject DDD.
>>>
>>
>> But DDD doesn't do a denial of service, so it is a false positive.
>>
> 
> When HHH is a denial-of-service-detector and DDD
> is trying to fool HHH into getting stuck in recursive
> emulation thus causing denial-of-service HHH is not fooled.
> 

But we aren't doing a DOS detector, that has a different criteria, as 
generally is allowed to have false positives (and even false negatives).

You are just showing that it has always been a strawman, and you were 
never actually working on the problem you claimed, by have been lying 
for all these years out of your ignorance of what you have been trying 
to talk about.