Let me sit back and see what the two of you make of it.

option8: sorry about the noise - BigEd and I like to poke at each other sometimes...

To summarize: from the standpoint of information science, there is no direct way to prove 8-bitness.

But there may be a 'sidechannel'. Perhaps there is a way to extract that information based on statistics and some other task that leaks that information while providing some other benefit to the user.

P.S. For instance: a list of gas stations you use with times you gas up provides a lot of information about where you live, whether you have a job, and roughly what kind of a car you have. Is there something your 8-bit users do that others don't? Buy floppy disks, maybe...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Wow.

So, yes, I know a modern machine can emulate a 6502, including all the hardware bugs, perfectly. I'm less concerned with that than the idea that a thing was done in 6502 assembly, or barring that, a period-correct implementation of BASIC. I can plug values into a BASIC program, let it run, and get the results. Or, I can write a faster version of the same algorithm in python, and get the results in 1/1000th the time. The python script will give me faster, but noticeably different, results.

Looking for that algorithm.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Let me try again. A simulator of a processor is a detailed model of said processor, containing the same registers, datapaths, and instructions. When correctly implemented, there can be no detectable difference; a program executing on a simulator has identical execution path and side effects as the same program running on real hardware. (In fact, 'real' hardware is a simulation of binary logic, built with analog transistors on a silicon wafer).

Given that, there is absolutely nothing you can do to see if you are running on 'real' hardware or emulated virtual hardware, or 100 guys with calculators. Any quirks can be faithfully simulated.

The quirks you've brought up are bugs. There is no reason a BASIC floating point division should give you a different result than Python's; if the IEEE 754 standard (from 1985) is followed carefully, both should be same - especially since modern hardware handles floating point directly. And again, relying on undocumented bugs of poorly-implemented software is probably not a good idea - and has nothing to do with detecting what processor you are running on anyway.

P.S. There is nothing inherently 'faster' about Python as compared to BASIC. I wrote a BASIC implementation for the Atari ST that was pretty much as fast as C in most situations.

P.P.S. There is no algorithm possible. Any algorithm can be run on anything, including a simulation of an entirely different machine (maybe within another simulation). It's turtles all the way down with information theory.

The only hope is a 'sidechannel', as I mentioned before - something that is reasonsably unique to a particular execution environment, that the user may be coerced into providing you, or even voluntarily prove to you in exchange for some benefit, perhaps... The way I put up with my browser spying on me in exchange for the joy of arguing with BigEd here. Confirmed by statistics, perhaps. I would need more information.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

A simple example:
python -


AppleSoft BASIC -


After poking around in BASIC, I've knocked together this proof-of-concept proof-of-work "algorithm":



The BASIC code


eventually prints "15429"

in python


results in... well, I've let it run, and haven't been patient enough to let it get to a result.

If I add "print f" into the pow() function, it outputs

How does it help you to find out if I ran your code on a real Apple 2 or an Apple simulation on my Linux x86 box?

BigEd, I concede. Perhaps we should be talking about how many cycles a Z80 takes vs. 6502, as this is going nowhere.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

option8, let's check the premises, as I suspect one of us is misunderstanding something.

Proof of work algorithms don't do what you think they do. They do not offer proof that any individual has done any work - not at all. They prove that altogether all the participants, on average, perform a certain number of hashes. But an individual miner can get lucky on the first try, performing hardly any work, and satisfy the system.

Nor do proof of work algorithms have anything to do with the speed of the participants. You could compute a winning result on an abacus - unlikely as it is. So your idea of a 6502 being slower than modern chips or python being faster, again, have nothing to do with proof of work or proof of 6502.

You are focusing on rounding errors and 'quirks' as proof terms. That is not how proof of work algorithms work. The only important thing is the result - it does not matter how you got it as long as it satisfies the system. They are not really algorithms, they are specifications and you are free to code them any way you like, and run them on any device you want.

I suggest you forget about 'proof of work', as it does pretty much the opposite of what you want. Nonces and difficulty have no business here - they exist for a very specific and very different reason.

How to prove that someone has a 6502? It is an entirely different problem than proof of work. You cannot ask them to solve some kind of a problem as it does not help (any processor can do that). You don't care about statistical measures - you want to know if a specific participant has access to a real 6502.

You seem to be ok with providing some code for them to run, apparently on an Apple 2 machine. Apparently, for some reason, they do. Why? Do you trust their results? Proof of work is there explicitly to eliminate trust. What are you trying to accomplish, and what are the rules?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

According to https://docs.python.org/3/tutorial/floatingpoint.html, Python uses binary floating point. They explain how adding 0.1 three times is not equal to 0.3, and later advise:

Binary floating-point arithmetic holds many surprises like this. The problem with “0.1” is explained in precise detail below, in the “Representation Error” section. See The Perils of Floating Point for a more complete account of other common surprises.
...
Why is that? 1/10 is not exactly representable as a binary fraction. Almost all machines today (November 2000) use IEEE-754 floating point arithmetic, and almost all platforms map Python floats to IEEE-754 “double precision”. 754 doubles contain 53 bits of precision, so on input the computer strives to convert 0.1 to the closest fraction it can of the form J/2**N where J is an integer containing exactly 53 bits.


The Perils of Floating Point.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

EDIT: enso beat me to it but here's an example anyway:
Just for context, Python doesn't use decimal internally, probably because it would be much slower without hardware support. Here's a Python program to demonstrate the rounding error:
x should be 100,000 after 1,000,000 iterations but is actually 100,000.00000133288

Python has decimal numbers built in if you need them: which results in x equal to 100,000 exactly.

Yeah. I've changed the rules a bit since I started down this road - and all the [s]bickering[/s] friendly banter hasn't helped

I'm trying to work out a way of authenticating that some operation has been done on a vintage computer (Apple II) and not on a modern computer.

Ideally, this would also exclude emulators - but that's a different challenge. If the proof were based on some quirk specific to the 6502, then it would be applicable to a wider range of participants, but limiting to Apple II by way of Applesoft or something else specific in ROM is acceptable.

The proof-of-concept I posted above is just that - showing that a modern language running on a faster machine will give a different result, based solely on doing the same calculations. The ultimate "proof of work" is still to be determined.

There's a previous thread which touches on detectable differences between Basics, as seen in simple floating point calculations, linking in turn to related investigations and discoveries:

Comparison of the different floating point formats.

So if we were to find ourselves in front of a Basic prompt, and wondered which Basic it was, there are some ideas there for tests to run. (A bit like calculator forensics.)

No... what you empirically and anecdotally demonstrate (not prove in any sense of the word) is that some implementation of floating point is different from another. You then propose to somehow identify that one is 'faster' and more 'modern' without any rational basis. This is not even wrong.

I am out.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!