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/
// The following is written in C
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: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
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H would
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: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
On 6/13/23 6:51 PM, olcott wrote:When simulating termination analyzer H is presented with an >>>>>>>>>> input the
On 6/13/2023 5:32 PM, Richard Damon wrote:
On 6/13/23 11:17 AM, olcott wrote:When denial of service attacks define a pathological input >>>>>>>>>>>> that would
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.
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.
right answer is always: Must the simulation of the input be >>>>>>>>>> aborted to
prevent the infinite execution of H? Yes is the correct answer. >>>>>>>>>
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.
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.
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.
On 6/14/23 8:13 PM, olcott wrote:It is an easily verified fact that H does correctly abort its simulation
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:In other words (from H's point of view) the halt status of D is a
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H would >>>>>>>> be correct.
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:So, I guess you are admitting that a simulationg termination >>>>>>>>>>> analyzer isn't a "Halting Decider" per the Computabilty
On 6/13/23 6:51 PM, olcott wrote:When simulating termination analyzer H is presented with an >>>>>>>>>>>> input the
On 6/13/2023 5:32 PM, Richard Damon wrote:
On 6/13/23 11:17 AM, olcott wrote:When denial of service attacks define a pathological input >>>>>>>>>>>>>> that would
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.
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.
right answer is always: Must the simulation of the input be >>>>>>>>>>>> aborted to
prevent the infinite execution of H? Yes is the correct answer. >>>>>>>>>>>
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.
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.
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.
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:In other words (from H's point of view) the halt status of D is a
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H would >>>>>>> be correct.
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:So, I guess you are admitting that a simulationg termination >>>>>>>>>> analyzer isn't a "Halting Decider" per the Computabilty
On 6/13/23 6:51 PM, olcott wrote:When simulating termination analyzer H is presented with an >>>>>>>>>>> input the
On 6/13/2023 5:32 PM, Richard Damon wrote:
On 6/13/23 11:17 AM, olcott wrote:When denial of service attacks define a pathological input >>>>>>>>>>>>> that would
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.
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.
right answer is always: Must the simulation of the input be >>>>>>>>>>> aborted to
prevent the infinite execution of H? Yes is the correct answer. >>>>>>>>>>
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.
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.
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.
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:In other words (from H's point of view) the halt status of D is >>>>>>>> a self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H >>>>>>>>>> would be correct.
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:When simulating termination analyzer H is presented with >>>>>>>>>>>>>> an input the
On 6/13/2023 5:32 PM, Richard Damon wrote:
On 6/13/23 11:17 AM, olcott wrote:When denial of service attacks define a pathological >>>>>>>>>>>>>>>> input that would
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.
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. >>>>>>>>>>>>>>>
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.
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.
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.
On 6/14/2023 7:47 PM, Richard Damon wrote:
On 6/14/23 8:13 PM, olcott wrote:It is an easily verified fact that H does correctly abort its simulation
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:In other words (from H's point of view) the halt status of D is a >>>>>>> self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H
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:When simulating termination analyzer H is presented with an >>>>>>>>>>>>> input the
On 6/13/2023 5:32 PM, Richard Damon wrote:
On 6/13/23 11:17 AM, olcott wrote:otherwise cause the denial of service attack detector to >>>>>>>>>>>>>>> eat up system
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
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.
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.
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.
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.
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.
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:In other words (from H's point of view) the halt status of D is >>>>>>>>> a self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H >>>>>>>>>>> would be correct.
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:When simulating termination analyzer H is presented with >>>>>>>>>>>>>>> an input the
On 6/13/2023 5:32 PM, Richard Damon wrote:
On 6/13/23 11:17 AM, olcott wrote:When denial of service attacks define a pathological >>>>>>>>>>>>>>>>> input that would
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.
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. >>>>>>>>>>>>>>>>
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.
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.
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.
You must be a bot you are stuck on old arguments that do not apply toIt 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 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.
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:You must be a bot you are stuck on old arguments that do not apply to
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:When the input to H is defined to do the opposite of whatever H
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:In other words (from H's point of view) the halt status of D >>>>>>>>>> is a self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H >>>>>>>>>>>> would be correct.
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:When simulating termination analyzer H is presented with >>>>>>>>>>>>>>>> an input the
On 6/13/2023 5:32 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 6/13/23 11:17 AM, olcott wrote:
When denial of service attacks define a pathological >>>>>>>>>>>>>>>>>> input that wouldThe 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.
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. >>>>>>>>>>>>>>>>>
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.
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.
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. >>>>>>
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 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.
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:You must be a bot you are stuck on old arguments that do not apply to
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:When the input to H is defined to do the opposite of whatever H
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:In other words (from H's point of view) the halt status of D >>>>>>>>>>> is a self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H >>>>>>>>>>>>> would be correct.
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:When simulating termination analyzer H is presented >>>>>>>>>>>>>>>>> with an input the
On 6/13/2023 5:32 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/13/23 11:17 AM, olcott wrote:
When denial of service attacks define a pathological >>>>>>>>>>>>>>>>>>> input that wouldThe 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.
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. >>>>>>>>>>>>>>>>>>
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.
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.
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. >>>>>>>
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 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.
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:You must be a bot you are stuck on old arguments that do not apply to
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:When the input to H is defined to do the opposite of whatever H >>>>>>>> says it
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:In other words (from H's point of view) the halt status of D >>>>>>>>>>>> is a self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then H >>>>>>>>>>>>>> would be correct.
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:
When simulating termination analyzer H is presented >>>>>>>>>>>>>>>>>> with an input theOn 6/13/2023 5:32 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 6/13/23 11:17 AM, olcott wrote:
otherwise cause the denial of service attack >>>>>>>>>>>>>>>>>>>> detector to eat up systemThe 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
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. >>>>>>>>>>>>>>>>>>>
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.
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.
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. >>>>>>>>
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 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.
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:You must be a bot you are stuck on old arguments that do not apply to >>>>> the current issue.
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:In other words (from H's point of view) the halt status of >>>>>>>>>>>>> D is a self-
On 6/13/2023 9:59 PM, Richard Damon wrote:
On 6/13/23 10:47 PM, olcott wrote:Okay then you are saying that H should return 1 and then >>>>>>>>>>>>>>> H would be correct.
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:
When simulating termination analyzer H is presented >>>>>>>>>>>>>>>>>>> with an input theOn 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
otherwise cause the denial of service attack >>>>>>>>>>>>>>>>>>>>> detector to eat up systembugs 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
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. >>>>>>>>>>>>>>>>>>>>
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.
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 126:29:51 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,334,958 |