Groups | Search | Server Info | Login | Register

Groups > comp.theory > #64889

Re: Termination Analyzer H correctly prevents Denial of Service attacks

Cross-posted to 3 groups.

Show all headers | View raw

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.

And, your claim that it solves the Halting problem for this case when 
the answer is demonstratably wrong, and you even admit to the basic 
facts that show this, show that you are just a hypocritical ignorant 
pathological lying idiot.

Remember, the question is described by the input to the decider halt 
when run.

It is a fact that your H(D,D) will return 0, that is what you claims are 
and that is what the code you have posted does.

If is a fact, that because of this D(D) will finish (and thus halt). You 
accept this fact, and it is demonstrable with your code.

Thus, BY DEFIHNITION, your H is wrong, and you are a liar for saying it 
is right as a Halt Decider.

Your arguments just prove that you don't understand what you are talking 
about.

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