• Termination Analyzer H correctly prevents Denial of Service attacks

    From olcott@21:1/5 to All on Tue Jun 13 10:13:23 2023
    XPost: comp.lang.c, sci.logic

    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/




    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Tue Jun 13 10:16:08 2023
    XPost: comp.lang.c, sci.logic

    I didn't mean to post this here please respond to comp.theory or ignore

    On 6/13/2023 10:13 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/





    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tTh@21:1/5 to olcott on Tue Jun 13 19:18:21 2023
    XPost: comp.lang.c, sci.logic

    On 6/13/23 17:13, olcott wrote:

    // The following is written in C

    tth@redlady:/tmp$ splint following.c
    Splint 3.1.2 --- 05 Sep 2017

    following.c:4:4: Parse Error: New function scope inside function. (For
    help on
    parse errors, see splint -help parseerrors.)
    *** Cannot continue.
    tth@redlady:/tmp$


    --
    +-------------------------------------------------------------------+
    | https://danstonchat.com/1138.html | +-------------------------------------------------------------------+

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Wed Jun 14 19:13:21 2023
    XPost: comp.theory, sci.logic

    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.

    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.


    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Wed Jun 14 20:13:41 2023
    XPost: comp.theory, sci.logic

    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.

    This proves that from an actual computer programming perspective the
    algorithm of H eliminates the issue of the otherwise "impossible" input.

    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Jun 14 20:47:23 2023
    XPost: comp.theory, sci.logic

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Wed Jun 14 20:41:04 2023
    XPost: comp.theory, sci.logic

    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.

    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Jun 14 21:29:11 2023
    XPost: comp.theory, sci.logic

    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.

    The fact that D uses a copy of H, means that you need to take into
    account what H actually does when you evaluate D. Your logic starts by
    assuming that H doesn't abort, but it does, so the logic was unsound and
    based on a LIE. (Because that seems to be all you know how to do).

    That fact that some OTHER H, that you try to deceptively swap n, makes a
    D that overruns the system, has no bearing on the behavior of the D that
    uses the H that does abort.

    Obviously, you just don't understand that first principles of computer programming.


    This proves that from an actual computer programming perspective the algorithm of H eliminates the issue of the otherwise "impossible" input.


    But doesn't solve the halting problm. It just shows that you are willing
    to take a wrong answer as right.

    That shows you totally don't understand the meaning of Truth.

    Just like Chat GPT, if you don't know the answer to a question, you just
    make up a lie that seems convincing.

    This shows that you don't actually have any intelegence, artificial or otherwise, but are just a Hypocritcal Ignorant Pathological Lying Idiot.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Jun 14 22:23:16 2023
    XPost: comp.theory, sci.logic

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Wed Jun 14 22:38:51 2023
    XPost: comp.theory, sci.logic

    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* 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.

    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Jun 15 07:25:25 2023
    XPost: comp.theory, sci.logic

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Thu Jun 15 10:12:00 2023
    XPost: comp.theory, sci.logic

    On 6/15/2023 6:25 AM, Richard Damon wrote:
    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 keep getting confused by conflating two different levels of
    recursive invocation. When a program input has been specifically
    defined to confuse a termination analyzer it is correct to determine
    that the program behavior is malevolent.

    Prior to my work nothing could be done about inputs having a
    pathological relationship to their termination analyzer. Prior to my
    work Rice's theorem prevented this pathological relationship from being recognized.

    When H(D,D) returns 0 this means that the input does not halt or the
    input has pathological behavior that would otherwise cause the
    termination analyzer to not halt. This means that the program has either
    a non-termination bug or the program has malevolent behavior.

    --
    Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Jun 15 12:37:40 2023
    XPost: comp.theory, sci.logic

    On 6/15/23 11:12 AM, olcott wrote:
    On 6/15/2023 6:25 AM, Richard Damon wrote:
    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 keep getting confused by conflating two different levels of
    recursive invocation. When a program input has been specifically
    defined to confuse a termination analyzer it is correct to determine
    that the program behavior is malevolent.

    Prior to my work nothing could be done about inputs having a
    pathological relationship to their termination analyzer. Prior to my
    work Rice's theorem prevented this pathological relationship from being recognized.

    When H(D,D) returns 0 this means that the input does not halt or the
    input has pathological behavior that would otherwise cause the
    termination analyzer to not halt. This means that the program has either
    a non-termination bug or the program has malevolent behavior.

    NO, YOU have the levels reversed because you think "Fanstasy" is the
    Reality,

    The question is about the DIRECT EXECTUTION of the machine described by
    te input. The problem does not care ir H is able to "correctly simulate"
    its input, or if such simulation reaches a final state, that is just implementation detail.

    The ONLY question in view, is what the machine actually does when run,
    and since your H(D,D) returns 0, then the only possible behaivor of D(D)
    is to Halt.

    You "logic" is based on the Trumpian theory that we can ignore the
    actual facts of reality and just assert our own as being actually true.
    You claim H's simulation as "correct", when it doesn't meet the actual definition needed to use simulation as a replacement for actual
    behavior. You try to redefine the problem, but that just means your
    claims that you are working on the problem are lies.


    Note, since the DEFINITION of a Halt Decider is to decide on ALL
    Programs, no program can be consider "malevolent", as to be correct, the decidder MUST be able to CORRECTLY answer for any input, so an input
    that is can't handle just proves the decider fails to meet the specifitions.

    Just like Trump isn't the President because he didn't get the majority
    of the needed votes, your H isn't "Correctly Deciding" this input
    because the input Halts when it says it won't. You can't argue that it "Cheated", as the input is BY DEFINITON allowed to be a description of
    any possible machine, so no machine is "cheating" by existing.

    All you are doing is PROVING you don't understand the meaning of the
    problem by saying an input, that is fully valid, is somehow "incorrect".
    That is like Trump calling the fact that the vote tallies went against
    him as "massive voter fraud". You may not like the comparison. but it is
    true.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)