Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Yes I have a Machintosh, please don't scream at me. -- Larry Blumette on linux-kernel


computers / comp.theory / Re: Halting problem proofs refuted on the basis of software engineering

Re: Halting problem proofs refuted on the basis of software engineering

<Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=35304&group=comp.theory#35304

  copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 03 Jul 2022 09:57:59 -0500
Date: Sun, 3 Jul 2022 09:57:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<20220702172644.00004e9c@reddwarf.jmc>
<orWdnUMI9ukU6F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702181010.000011c0@reddwarf.jmc>
<S8idnfNU_avS4F3_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220702182653.00003f52@reddwarf.jmc>
<r_qdndMhfIEBHV3_nZ2dnUU7_8xh4p2d@giganews.com>
<20220702192847.00000807@reddwarf.jmc>
<3O2dnX_5sOHXDF3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702194448.00005117@reddwarf.jmc>
<S-mdnfRt7a-LJV3_nZ2dnUU7_81g4p2d@giganews.com>
<20220702230537.00001259@reddwarf.jmc>
<avudncmA4ZtwX13_nZ2dnUU7_8xh4p2d@giganews.com>
<20220703152751.00001f74@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220703152751.00001f74@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Y72dndpURKjqM1z_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 393
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LFaAaWko/Hiw//uJB4Lm0jLGjuyjgSG7THz5QyPDutYC/QXZ+iGg/53SWCXqMF1sBa9aHhwu0KAg0Y8!OTfCcbpGURVBK11WGAMf+N+5dwChA9ZmCZDhZn0s19E/Ml0qbEXbXgHgqP3NlTFUopM5xhhOfVqn
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 18542
 by: olcott - Sun, 3 Jul 2022 14:57 UTC

On 7/3/2022 9:27 AM, Mr Flibble wrote:
> On Sat, 2 Jul 2022 17:13:01 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/2/2022 5:05 PM, Mr Flibble wrote:
>>> On Sat, 2 Jul 2022 16:26:45 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/2/2022 1:44 PM, Mr Flibble wrote:
>>>>> On Sat, 2 Jul 2022 13:41:14 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/2/2022 1:28 PM, Mr Flibble wrote:
>>>>>>> On Sat, 2 Jul 2022 12:30:03 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/2/2022 12:26 PM, Mr Flibble wrote:
>>>>>>>>> On Sat, 2 Jul 2022 12:15:58 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/2/2022 12:10 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 2 Jul 2022 11:42:48 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/2/2022 11:26 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 2 Jul 2022 10:34:34 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This much more concise version of my paper focuses on the
>>>>>>>>>>>>>> actual execution of three fully operational examples.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H0 correctly determines that Infinite_Loop() never halts
>>>>>>>>>>>>>> H correctly determines that Infinite_Recursion() never
>>>>>>>>>>>>>> halts H correctly determines that P() never halts
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As shown below the above P and H have the required
>>>>>>>>>>>>>> (halting problem) pathological relationship to each
>>>>>>>>>>>>>> other:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For any program H that might determine if
>>>>>>>>>>>>>> programs halt, a "pathological"
>>>>>>>>>>>>>> program P, called with some input, can pass
>>>>>>>>>>>>>> its own source and its input to
>>>>>>>>>>>>>> H and then specifically do the opposite of
>>>>>>>>>>>>>> what H predicts P will do. No H
>>>>>>>>>>>>>> can exist that handles this case.
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really need software engineers to verify that H does
>>>>>>>>>>>>>> correctly predict that its complete and correct x86
>>>>>>>>>>>>>> emulation of its input would never reach the "ret"
>>>>>>>>>>>>>> instruction of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Halting problem proofs refuted on the basis of software
>>>>>>>>>>>>>> engineering*
>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408 add
>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000
>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff
>>>>>>>>>>>>> call 00000476 Input_Halts = 0
>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408 add
>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3
>>>>>>>>>>>>> ret Number of Instructions Executed(16120)
>>>>>>>>>>>>>
>>>>>>>>>>>>> As can be seen above Olcott's H decides that Px does not
>>>>>>>>>>>>> halt but it is obvious that Px should always halt if H is
>>>>>>>>>>>>> a valid halt decider that always returns a decision to its
>>>>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its
>>>>>>>>>>>>> caller (Px) and is thus invalid.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Your false assumptions are directly contradicted by the
>>>>>>>>>>>> semantics of the x86 programming language.
>>>>>>>>>>>>
>>>>>>>>>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _Px()
>>>>>>>>>>>> [00001192](01) 55 push ebp
>>>>>>>>>>>> [00001193](02) 8bec mov ebp,esp
>>>>>>>>>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001198](01) 50 push eax
>>>>>>>>>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [0000119c](01) 51 push ecx
>>>>>>>>>>>> [0000119d](05) e8d0fdffff call 00000f72
>>>>>>>>>>>> [000011a2](03) 83c408 add esp,+08
>>>>>>>>>>>> [000011a5](01) 5d pop ebp
>>>>>>>>>>>> [000011a6](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0021) [000011a6]
>>>>>>>>>>>>
>>>>>>>>>>>> _main()
>>>>>>>>>>>> [000011d2](01) 55 push ebp
>>>>>>>>>>>> [000011d3](02) 8bec mov ebp,esp
>>>>>>>>>>>> [000011d5](05) 6892110000 push 00001192
>>>>>>>>>>>> [000011da](05) 6892110000 push 00001192
>>>>>>>>>>>> [000011df](05) e88efdffff call 00000f72
>>>>>>>>>>>> [000011e4](03) 83c408 add esp,+08
>>>>>>>>>>>> [000011e7](01) 50 push eax
>>>>>>>>>>>> [000011e8](05) 68a3040000 push 000004a3
>>>>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2
>>>>>>>>>>>> [000011f2](03) 83c408 add esp,+08
>>>>>>>>>>>> [000011f5](02) 33c0 xor eax,eax
>>>>>>>>>>>> [000011f7](01) 5d pop ebp
>>>>>>>>>>>> [000011f8](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0039) [000011f8]
>>>>>>>>>>>>
>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>> address address data code language
>>>>>>>>>>>> ======== ======== ======== =========
>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec mov
>>>>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push
>>>>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push
>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call
>>>>>>>>>>>> 00000f72
>>>>>>>>>>>>
>>>>>>>>>>>> H: Begin Simulation Execution Trace Stored at:11202b
>>>>>>>>>>>> Address_of_H:f72
>>>>>>>>>>>> [00001192][00112017][0011201b] 55 push ebp
>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001198][00112013][00001192] 50 push eax //
>>>>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push
>>>>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
>>>>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
>>>>>>>>>>>> Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>
>>>>>>>>>>>> H knows its own machine address and on this basis it can
>>>>>>>>>>>> easily examine its stored execution_trace of Px (see above)
>>>>>>>>>>>> to determine: (a) Px is calling H with the same arguments
>>>>>>>>>>>> that H was called with. (b) No instructions in Px could
>>>>>>>>>>>> possibly escape this otherwise infinitely recursive
>>>>>>>>>>>> emulation. (c) H aborts its emulation of Px before its call
>>>>>>>>>>>> to H is emulated.
>>>>>>>>>>>>
>>>>>>>>>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3
>>>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
>>>>>>>>>>>> Number of Instructions Executed(880) == 13 Pages
>>>>>>>>>>>
>>>>>>>>>>> If H wasn't a simulation-based halting decider then Px()
>>>>>>>>>>> would always halt; the infinite recursion is a
>>>>>>>>>>> manifestation of your invalid simulation-based halting
>>>>>>>>>>> decider. There is no recursion in [Strachey 1965].
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> In other words you are rejecting the concept of a simulating
>>>>>>>>>> halt decider even though I conclusively proved that it does
>>>>>>>>>> correctly determine the halt status of: (see my new paper)
>>>>>>>>>
>>>>>>>>> No I am rejecting your simulating halt decider as it gets the
>>>>>>>>> answer wrong for Px() which is not a pathological input. Px()
>>>>>>>>> halts.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> I just proved that H(Px,Px) does correctly predict that its
>>>>>>>> complete and correct x86 emulation of its input would never
>>>>>>>> reach the "ret" instruction of this input because of the
>>>>>>>> pathological relationship between H and Px.
>>>>>>>
>>>>>>> Wrong. Px() is not a pathological input as defined by the
>>>>>>> halting problem and [Strachey 1965] as it does not try to do
>>>>>>> the opposite of what H decides.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Your lack of comprehension does not actually count as any
>>>>>> rebuttal at all.
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> As shown below the above P and H have the required (halting
>>>>>> problem) pathological relationship to each other:
>>>>> [snip]
>>>>>
>>>>> P does but Px does not. I am talking about Px not P.
>>>>>
>>>>> void Px(u32 x)
>>>>> {
>>>>> H(x, x);
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>> }
>>>>>
>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>> Input_Halts = 0
>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>> Number of Instructions Executed(16120)
>>>>>
>>>>> As can be seen above Olcott's H decides that Px does not halt but
>>>>> it is obvious that Px should always halt if H is a valid halt
>>>>> decider that always returns a decision to its caller (Px).
>>>>> Olcott's H does not return a decision to its caller (Px) and is
>>>>> thus invalid.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> >
>>>>
>>>> Your false assumptions are directly contradicted by the semantics
>>>> of the x86 programming language.
>>>>
>>>> *x86 Instruction Set Reference* https://c9x.me/x86/
>>>>
>>>> void Px(u32 x)
>>>> {
>>>> H(x, x);
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>>
>>>> _Px()
>>>> [00001192](01) 55 push ebp
>>>> [00001193](02) 8bec mov ebp,esp
>>>> [00001195](03) 8b4508 mov eax,[ebp+08]
>>>> [00001198](01) 50 push eax
>>>> [00001199](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000119c](01) 51 push ecx
>>>> [0000119d](05) e8d0fdffff call 00000f72
>>>> [000011a2](03) 83c408 add esp,+08
>>>> [000011a5](01) 5d pop ebp
>>>> [000011a6](01) c3 ret
>>>> Size in bytes:(0021) [000011a6]
>>>>
>>>> _main()
>>>> [000011d2](01) 55 push ebp
>>>> [000011d3](02) 8bec mov ebp,esp
>>>> [000011d5](05) 6892110000 push 00001192
>>>> [000011da](05) 6892110000 push 00001192
>>>> [000011df](05) e88efdffff call 00000f72
>>>> [000011e4](03) 83c408 add esp,+08
>>>> [000011e7](01) 50 push eax
>>>> [000011e8](05) 68a3040000 push 000004a3
>>>> [000011ed](05) e800f3ffff call 000004f2
>>>> [000011f2](03) 83c408 add esp,+08
>>>> [000011f5](02) 33c0 xor eax,eax
>>>> [000011f7](01) 5d pop ebp
>>>> [000011f8](01) c3 ret
>>>> Size in bytes:(0039) [000011f8]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000011d2][00101f7f][00000000] 55 push ebp
>>>> [000011d3][00101f7f][00000000] 8bec mov ebp,esp
>>>> [000011d5][00101f7b][00001192] 6892110000 push 00001192
>>>> [000011da][00101f77][00001192] 6892110000 push 00001192
>>>> [000011df][00101f73][000011e4] e88efdffff call 00000f72
>>>>
>>>> H: Begin Simulation Execution Trace Stored at:11202b
>>>> Address_of_H:f72
>>>> [00001192][00112017][0011201b] 55 push ebp
>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp
>>>> [00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
>>>> [00001198][00112013][00001192] 50 push eax // push Px
>>>> [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
>>>> [0000119c][0011200f][00001192] 51 push ecx // push Px
>>>> [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
>>>> H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
>>>> Stopped
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of Px (see above) to determine:
>>>> (a) Px is calling H with the same arguments that H was called with.
>>>> (b) No instructions in Px could possibly escape this otherwise
>>>> infinitely recursive emulation.
>>>> (c) H aborts its emulation of Px before its call to H is emulated.
>>>>
>>>> [000011e4][00101f7f][00000000] 83c408 add esp,+08
>>>> [000011e7][00101f7b][00000000] 50 push eax
>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3
>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
>>>> Input_Halts = 0
>>>> [000011f2][00101f7f][00000000] 83c408 add esp,+08
>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax
>>>> [000011f7][00101f83][00000018] 5d pop ebp
>>>> [000011f8][00101f87][00000000] c3 ret
>>>> Number of Instructions Executed(880) == 13 Pages
>>>
>>> I see you wish to pointlessly go around in circles. Oh well.
>>>
>>> Px() is not a pathological input as defined by the halting
>>> problem and [Strachey 1965] as it does not try to do the opposite of
>>> what H decides.
>>>
>>> Px() always halts so your H gets the answer wrong.
>>>
>>> /Flibble
>>
>> I found that my reply did not make it to all the groups so I posted
>> it again.
>>
>> *This general principle refutes conventional halting problem proofs*
>> Every simulating halt decider that correctly simulates its input
>> until it correctly predicts that this simulated input would never
>> reach its final state, correctly rejects this input as non-halting.
>
> Your H does not "correctly predict" that Px() does reach its final
> state and so should accept the input as halting.
>
> /Flibble
>

(x86 Instruction Set Reference* https://c9x.me/x86/

The semantics of the x86 language conclusively proves that the above
code is correct. People that disagree with verified facts are either
incompetent or liars. Since you cannot even understand that the return
statement in Px is unreachable code, (to every simulating halt decider
H) you would be incompetent.

--
Copyright 2022 Pete Olcott

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

SubjectRepliesAuthor
o Halting problem proofs refuted on the basis of software engineering

By: olcott on Sat, 2 Jul 2022

123olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor