Groups | Search | Server Info | Login | Register

Groups > sci.logic > #254384

Re: Termination Analyzer H correctly prevents Denial of Service attacks

Cross-posted to 3 groups.

Show all headers | View raw

On 6/14/23 11:38 PM, olcott wrote:
> On 6/14/2023 9:23 PM, Richard Damon wrote:
>> 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.
> 
> *Termination Analyzer H prevents Denial of Service attacks*

But doesn't get the right answer to the Halting Problem.

> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_prevents_Denial_of_Service_attacks
> 
> It is an easily verified fact that termination analyzer H does correctly
> thwart what would otherwise be a successful denial of service attack
> when presented with input D having the halting problem's pathological
> relationship to H.
> 
> This proves that the halting problem's pathological input is not an
> issue for actual software systems.
> 

It might thwart a DOS attack on itself, but the program that it flags, 
if run as an independent program, will HALT, and thus not present a DOS 
attack on the system, so its answer is a FALSE POSITIVE.

You logic is exactly like Trumps that since he got more votes for him 
then any other Presidential Candidate before him, must have one the 
election, and thus there must have been election fraud to keep him from 
being elected President.

It is not answering the actual question in front of it, and thus the 
answer it gives is not relevent to the actual question.

Your repeating this claim, dispite its errors being made clear, just 
show that you are a Hypocritical Ignorant Pathological Lying Idiot.

You "brag" about not having studied the fields and thus not being 
poluted by their errors, and then decry people saying "Learned by Rote" 
statements, when you then reply back with Rote Recitation of statements 
you do not understand as justification of your work, and then promptly 
ignore the requirements in those statements, and violate the principles 
of the field, because you are just ignorant of the actual facts.

You live in a fantasy world where things just don't work as they 
actually do and you think you are in reality.

You are just totally lost.

Back to sci.logic | 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

csiph-web