Re: Termination Analyzer H correctly prevents Denial of Service attacks

Subject	Re: Termination Analyzer H correctly prevents Denial of Service attacks
Newsgroups	comp.theory, sci.logic, comp.ai.philosophy
References	(14 earlier) <u6dl33$5c39$1@dont-email.me> <wctiM.2$I68a.1@fx43.iad> <u6dok6$5lv4$1@dont-email.me> <IPtiM.5$33q9.2@fx35.iad> <u6dq7h$5pop$1@dont-email.me>
From	Richard Damon <Richard@Damon-Family.org>
Message-ID	<pCuiM.5$EuDd.4@fx02.iad> (permalink)
Organization	Forte - www.forteinc.com
Date	2023-06-14 22:23 -0400

Cross-posted to 3 groups.

Show all headers | View raw

On 6/14/23 9:41 PM, olcott wrote:
> On 6/14/2023 8:29 PM, Richard Damon wrote:
>> On 6/14/23 9:13 PM, olcott wrote:
>>> On 6/14/2023 7:47 PM, Richard Damon wrote:
>>>> On 6/14/23 8:13 PM, olcott wrote:
>>>>> On 6/14/2023 5:42 PM, Richard Damon wrote:
>>>>>> On 6/14/23 10:41 AM, olcott wrote:
>>>>>>> On 6/14/2023 6:35 AM, Richard Damon wrote:
>>>>>>>> On 6/13/23 11:28 PM, olcott wrote:
>>>>>>>>> On 6/13/2023 10:18 PM, Richard Damon wrote:
>>>>>>>>>> On 6/13/23 11:12 PM, olcott wrote:
>>>>>>>>>>> On 6/13/2023 9:59 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/13/23 10:47 PM, olcott wrote:
>>>>>>>>>>>>> On 6/13/2023 8:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/13/23 8:06 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/13/2023 5:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/13/23 6:51 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/13/2023 5:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/13/23 11:17 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> The purpose of solving the halting problem is to 
>>>>>>>>>>>>>>>>>>> determine non-halting
>>>>>>>>>>>>>>>>>>> bugs and non-halting malevolent software. My system 
>>>>>>>>>>>>>>>>>>> achieves that
>>>>>>>>>>>>>>>>>>> purpose for the halting problem's otherwise 
>>>>>>>>>>>>>>>>>>> impossible input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is only when the halting problem is construed as 
>>>>>>>>>>>>>>>>>>> providing a correct
>>>>>>>>>>>>>>>>>>> yes/no answer to a self-contradictory question that 
>>>>>>>>>>>>>>>>>>> the halting problem
>>>>>>>>>>>>>>>>>>> cannot be solved.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // The following is written in C
>>>>>>>>>>>>>>>>>>> //
>>>>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to 
>>>>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>> 07   if (Halt_Status)
>>>>>>>>>>>>>>>>>>> 08     HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> 09   return Halt_Status;
>>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>>> 14   D(D);
>>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Execution Trace
>>>>>>>>>>>>>>>>>>> Line 14: main() invokes D(D)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> keeps repeating (unless aborted)
>>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that 
>>>>>>>>>>>>>>>>>>> simulates D(D)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>>>>> D correctly simulated by H cannot possibly reach its 
>>>>>>>>>>>>>>>>>>> own line 09.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When termination analyzer H is intended to prevent 
>>>>>>>>>>>>>>>>>>> denial of service
>>>>>>>>>>>>>>>>>>> attacks is presented with an input D that has been 
>>>>>>>>>>>>>>>>>>> defined to have a
>>>>>>>>>>>>>>>>>>> pathological relationship to this termination 
>>>>>>>>>>>>>>>>>>> analyzer, it correctly
>>>>>>>>>>>>>>>>>>> aborts the simulation of this input that would have 
>>>>>>>>>>>>>>>>>>> otherwise caused H
>>>>>>>>>>>>>>>>>>> to never terminate until system resources have been 
>>>>>>>>>>>>>>>>>>> exhausted, crashing
>>>>>>>>>>>>>>>>>>> the system.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *The halting problem is an issue with denial of 
>>>>>>>>>>>>>>>>>>> service attacks*
>>>>>>>>>>>>>>>>>>> https://medium.com/coinmonks/ethereum-what-is-gas-and-why-do-we-need-it-88bcd7fc191d
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The whole system is right here:
>>>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It compiles with the 2017 version of the Community 
>>>>>>>>>>>>>>>>>>> Edition
>>>>>>>>>>>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except that preventing "Denial of Service Attacks" is 
>>>>>>>>>>>>>>>>>> part of the requirement, just as giving the right 
>>>>>>>>>>>>>>>>>> answer. It needs to do BOTH, and the right answer 
>>>>>>>>>>>>>>>>>> isn't based on its simulation, but the actual behavior 
>>>>>>>>>>>>>>>>>> of the machine. Thus, trying to excuse the wrong 
>>>>>>>>>>>>>>>>>> answer as being due to a prevention of a "Denial of 
>>>>>>>>>>>>>>>>>> Service" is just an admissioon that the problem 
>>>>>>>>>>>>>>>>>> actually is IMPOSSIBLE.
>>>>>>>>>>>>>>>>> When denial of service attacks define a pathological 
>>>>>>>>>>>>>>>>> input that would
>>>>>>>>>>>>>>>>> otherwise cause the denial of service attack detector 
>>>>>>>>>>>>>>>>> to eat up system
>>>>>>>>>>>>>>>>> resources and crash the system H detects this attempt 
>>>>>>>>>>>>>>>>> and thwarts it.
>>>>>>>>>>>>>>>>> *This conclusively proves that H is correct*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *How pathological inputs are currently handled*
>>>>>>>>>>>>>>>>>   If a set of instructions ( in the smart contract) is 
>>>>>>>>>>>>>>>>> executed on the
>>>>>>>>>>>>>>>>>   Ethereum Virtual Machine, it cannot predict how long 
>>>>>>>>>>>>>>>>> these will run
>>>>>>>>>>>>>>>>>   for, at the beginning. If a set of instructions run 
>>>>>>>>>>>>>>>>> forever, they can
>>>>>>>>>>>>>>>>>   freeze this blockchain and use up all the resources. 
>>>>>>>>>>>>>>>>> This is similar to
>>>>>>>>>>>>>>>>>   a DoS (Denial of Service) attack. Each computation on 
>>>>>>>>>>>>>>>>> the Ethereum
>>>>>>>>>>>>>>>>>   Virtual Machine requires some predetermined amount of 
>>>>>>>>>>>>>>>>> gas (which one
>>>>>>>>>>>>>>>>>   has to buy with real money).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (https://medium.com/coinmonks/ethereum-what-is-gas-and-why-do-we-need-it-88bcd7fc191d)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope. The decider is responsible to handle possible 
>>>>>>>>>>>>>>>> "Denial of Service Attacks", and the presence of them 
>>>>>>>>>>>>>>>> just points out the FUNDAMENTAL problem with your 
>>>>>>>>>>>>>>>> solution method. It has long been know that just relying 
>>>>>>>>>>>>>>>> on "Simulation" has significant issues for halt 
>>>>>>>>>>>>>>>> deciding, but since you have chosen to not look at 
>>>>>>>>>>>>>>>> history, you are just making the same mistakes made long 
>>>>>>>>>>>>>>>> ago.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The CORRECT answer is ALWAYS the behavior of the Actual 
>>>>>>>>>>>>>>>> Machine, which in this case Halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Therefore, H(D,D) saying that D(D) doesn't halt is just 
>>>>>>>>>>>>>>>> making H wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Claiming the wrong answer is right is just a LIE.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When simulating termination analyzer H is presented with 
>>>>>>>>>>>>>>> an input the
>>>>>>>>>>>>>>> right answer is always: Must the simulation of the input 
>>>>>>>>>>>>>>> be aborted to
>>>>>>>>>>>>>>> prevent the infinite execution of H? Yes is the correct 
>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, I guess you are admitting that a simulationg 
>>>>>>>>>>>>>> termination analyzer isn't a "Halting Decider" per the 
>>>>>>>>>>>>>> Computabilty Theory, since for those, the correct answer 
>>>>>>>>>>>>>> is always based on the actual behavior of the 
>>>>>>>>>>>>>> machine/input described by the input to the decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You KNOW that fact, as you have quoted that defintion, 
>>>>>>>>>>>>>> though admittedly, while you blaim others for just quoting 
>>>>>>>>>>>>>> "learned by rote" statements, the statements you quote are 
>>>>>>>>>>>>>> probably just quoted by rote without ever actually 
>>>>>>>>>>>>>> learning what they mean.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But, with your admission that your machine uses the WRONG 
>>>>>>>>>>>>>> criteria, you have just proven that you have been lying 
>>>>>>>>>>>>>> for the past decade that you have actually been working on 
>>>>>>>>>>>>>> the ACTUAL Halting Problem of Computation Theory as 
>>>>>>>>>>>>>> discussed by Turing, Linz, et all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All you have done is proved that you are the Hypocritical 
>>>>>>>>>>>>>> Ignorant Pathological Lying Idiot that you are. Perhaps 
>>>>>>>>>>>>>> even Insane, as you seem to think that by just repeating 
>>>>>>>>>>>>>> your lies that eventually someone will belive them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The alternative answer (remaining stuck in recursive 
>>>>>>>>>>>>>>> simulation until
>>>>>>>>>>>>>>> the system crashes) is so utterly moronic that I don't 
>>>>>>>>>>>>>>> believe that you
>>>>>>>>>>>>>>> believe it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that isn't what H does, it aborts its simulation 
>>>>>>>>>>>>>> and gives the WRONG answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are the MORON to think that an incorrect answer must 
>>>>>>>>>>>>>> be right because you don't know any other possible answer. 
>>>>>>>>>>>>>> IT is YOU how doesn't actually understand the Liar's Paradox.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We could downgrade the answer to my answer from 15 years 
>>>>>>>>>>>>>>> ago, H aborts
>>>>>>>>>>>>>>> the simulation and return BAD_INPUT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even this downgrade is (to the best of my knowledge) 
>>>>>>>>>>>>>>> better than anyone
>>>>>>>>>>>>>>> else has ever done because it provides the exact 
>>>>>>>>>>>>>>> criterion measure for
>>>>>>>>>>>>>>> this return value that cannot be fooled by Rice's theorem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And you show that you totally don't understand anything 
>>>>>>>>>>>>>> about logic.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You just don't understand any of the basics of that which 
>>>>>>>>>>>>>> you talk about.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because H(D,D) would remain stuck in recursive simulation 
>>>>>>>>>>>>> unless it
>>>>>>>>>>>>> aborts this simulation and in this case H is a termination 
>>>>>>>>>>>>> analyzer used
>>>>>>>>>>>>> to detect Denial of Service attacks what do you think that 
>>>>>>>>>>>>> H should do
>>>>>>>>>>>>> with input D?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Then it would fail to be a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> Once H is programmed to abort its simulation, it needs to 
>>>>>>>>>>>> analyze calls to H as if that call will also abort its 
>>>>>>>>>>>> simulation, since it will.
>>>>>>>>>>>>
>>>>>>>>>>> Okay then you are saying that H should return 1 and then H 
>>>>>>>>>>> would be correct.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> H SHOULD have returned 1, but if you change H to do that, you 
>>>>>>>>>> now have a new D and for that one (the one built on an H that 
>>>>>>>>>> returns 1 for H(D,D)) D(D) will be non-halting, so that H 
>>>>>>>>>> should have returned 0.
>>>>>>>>>>
>>>>>>>>> In other words (from H's point of view) the halt status of D is 
>>>>>>>>> a self-
>>>>>>>>> contradictory question even though it is not self-contradictory
>>>>>>>>> within other contexts. A question is not complete unless the 
>>>>>>>>> context is
>>>>>>>>> included.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It doesn't matter what it is "from H's point of view", what 
>>>>>>>> matters is what it actually is, which is measured by what 
>>>>>>>> happens when the actual machine is actually run.
>>>>>>>>
>>>>>>>> Yes, the context matters, and every H creates a DIFFERENT 
>>>>>>>> context, so every H needs to take ITSELF into consideration, and 
>>>>>>>> not assume that D calls some other variation of H, because it 
>>>>>>>> doesn't, not if this H is the one that you want to claim is 
>>>>>>>> correct.
>>>>>>>>
>>>>>>>> Your problem is you are stuck in a world of make-believe. You 
>>>>>>>> presume things that are not true, and show that in such a 
>>>>>>>> fantasy world, your machine is correct. The problem is, that 
>>>>>>>> isn't how Truth actually works. You need to start from actual 
>>>>>>>> established facts when you reason about things.
>>>>>>>>
>>>>>>>
>>>>>>> When computer science theory diverges from the reality of software
>>>>>>> engineering it is the reality that take precedence and the theory 
>>>>>>> that
>>>>>>> is out of touch with reality.
>>>>>>
>>>>>> So, you are admitting that you aren't followong the actual Theory,
>>>>>>
>>>>>> Thus you are admitting that you have been lying that you have 
>>>>>> been, for DECADES.
>>>>>>
>>>>>> You just don't understand the nature of the problem, or many of 
>>>>>> the things you talk about, because you don't understand the nature 
>>>>>> of Truth or Logic.
>>>>>>
>>>>>>>
>>>>>>> When both Boolean return values are the wrong answer then this 
>>>>>>> proves
>>>>>>> that the question itself is incorrect.
>>>>>>>
>>>>>>
>>>>>> Nope, because the question isn't What answer should H return to be 
>>>>>> correct, but what is the behavior of the machine at the input.
>>>>>
>>>>> When the input to H is defined to do the opposite of whatever H 
>>>>> says it
>>>>> will do then the halt status question posed to H is self-contradictory
>>>>> even if it is not self-contradictory when posed to any other 
>>>>> termination
>>>>> analyzer.
>>>>
>>>> Nope, because the program H must exist before the program D does, so 
>>>> the pnly self-contradictory question is how to design H to succeed. 
>>>> This is what makes a correct H impossible.
>>>>
>>>> I think part of your problem is you don't even understand what an 
>>>> actual program/machine is. It isn't just some nebulous definition of 
>>>> desired behavior, but needs to be actual detailed step-by-step 
>>>> instructions of what is going to happen based on the input.
>>>>
>>>> Your "Hypothetical" H that both correctly simulates its input, but 
>>>> also stops and gives an answer just isn't possible to do in an 
>>>> actual program. You have been given the challenge to show how it 
>>>> does both, and have ducked that, persumably because you know it is 
>>>> impossible.
>>>>
>>>> Once you define your H as an actual machine, then the answer to the 
>>>> behavor of D is well defined, easily determined, and it will be the 
>>>> opposite of whatever H gives as an answer.
>>>>
>>>>>
>>>>> Furthermore it is an easily verified fact that H does correctly 
>>>>> thwart a
>>>>> denial of service (DOS) attack by the halting problem's pathological
>>>>> input. This proves that the halting problem issue has been overcome in
>>>>> at least this one case.
>>>>>
>>>>>
>>>>
>>>> It may "thwart" a denial of service attack (cause by bad code in H), 
>>>> but it doesn't give the correct answer. It convicted an innocent party.
> 
>>> It is an easily verified fact that H does correctly abort its simulation
>>> of D (that specifically targets H) because the alternative is that D
>>> causes the system to exhaust its resources and crash.
>>
>> You have the problem wrong, since H DOES abort is simulation, D Halts 
>> so H, after aborting its simulation needed to return 1.
>>
>> You just don't understand how programs work.
>>
> You must be a bot you are stuck on old arguments that do not apply to
> the current issue.
> 
> When H is a termination analyzer that prevents denial or service attacks
> H correctly detects that D specifically targets H in its denial of
> service attack on H. Then H correctly thwarts this DOS attack.
> 
> Now that I have every detail boiled down to 100% entirely verified facts
> no rebuttal can possibly work. Anyone attempting such a rebuttal will
> look increasingly more foolish.
> 


The first fact you fail to verify is that you are even working on the 
right problem, which becomes the source of many of your lies, and that 
seems to be because you have made yourself intentionally ignorant of the 
field you are claiming to be an expert in, but that just makes you the Fool.

H might be able to determine that if H doesn't abort its simulation, 
that its simulation will go on forever, but that isn't the question of 
the halting problem, or even "Termination Analysis". Thus, you are just 
working on Strawmen.

The question for those is, what does the actual program do when run, and 
since, if you decider meets the requirements of being a decider, it 
will, that means the program is a halting program.

The only case where D(D) doesn't halt, is the case where H(D,D) fails to 
abort is simulation and return an answer, which means THAT H just fails 
to be a decider at all.

Thus, there is no H that "correct" determines its input is non-halting, 
as any version of H that tries to label ITS D as non-halting, creates a 
D(D) that is Halting. And any version of H that doesn't stop its 
simulation fails to answer and thus fails to be a decider, so can't be a 
correct halt decider.

Your because you think that somehow a Turing Machine (or equivalent) can 
do two different things when run with the same machine can you try to 
justify your answer, but such a thing is impossible.

You logic seems to be based on assuming the impossible can happen, and 
is thus invalid.

You are just proving that you have lost all grip on reality and just 
believe in your faerie tales, making you a Hypocritical Ignornant 
Pathological Lying Idiot.

Back to comp.theory | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-13 10:17 -0500
  Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-13 18:32 -0400
    Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-13 17:51 -0500
      Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-13 18:57 -0400
        Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-13 19:06 -0500
          Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-13 21:02 -0400
            Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-13 21:47 -0500
              Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-13 22:59 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-13 22:12 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-13 23:18 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-13 22:28 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-14 07:35 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-14 09:41 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-14 18:42 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-14 19:13 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-14 20:47 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-14 20:13 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-14 21:29 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-14 20:41 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-14 22:23 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-14 22:38 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-15 07:25 -0400
                Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-15 10:12 -0500
                Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-15 12:37 -0400
  Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-13 19:28 -0400
  Re: Termination Analyzer H correctly prevents Denial of Service attacks Zach <efftard2@mail.net> - 2023-06-17 12:34 -0700
    Re: Termination Analyzer H correctly prevents Denial of Service attacks olcott <polcott2@gmail.com> - 2023-06-17 14:58 -0500
      Re: Termination Analyzer H correctly prevents Denial of Service attacks Richard Damon <Richard@Damon-Family.org> - 2023-06-17 16:16 -0400

csiph-web