Skip to content

Starting with building binary fields based on input data, eventually will also entangle the input or data based from the input to the binary field(s).

Notifications You must be signed in to change notification settings

DigiMancer3D/Faux-Quantum

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

20 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Faux-Quantum

Starting with building binary fields based on input data, eventually will also entangle the input or data based from the input to the binary field(s).

Read more about the concept.

The idea of building a binary field based on other data without containing that data is the first tackle. The working version (hashlink below) encodes the input to a Base64 string so this string is reversable back to our input. We also find the dec value of the Base64, character per character, output as a long string. After that it uses the base64 or equivalent dec string to find the a-number then an acceptable vlaue range based off the a-number (low-low | low-high | high-low | high-high). The first binary field (the field core) is generated based on the acceptable value range determinations. The final field (the minable field) is generated based on the end result of the field core. Every 3rd & 4th line in the final field checks for filter pass possiblity based on the previous two lines.

Not being used nor coded-in yet, there is a programable section in the field core and final field during the filter-passes when a null-string is found. In order to use this section of the fields, the programable section needs be a series of options that's either on or off. The aviable room will differ per build.

Eventually field mining will be added to gain additional programmable sections as well as increase entropy of the field and gain new bit-positions.

The fields should be stored in Base64 or Base128. The Base-versions of the core and final field should be stored in seperate. The field core can be found in a single build final field but in a mined field with entropy will make finding the core much more difficult. A mined field without entropy will not make finding the core harder nor change the difficulty to retrace.

Not yet coded is the mining of a field. In the concept paper there's two main ways to mine the field but there's room to grow.

Entropy mining is using the Base64 of any selected sections or just the programmed sections to be used as the input to find another set of the same data as well as second field outputs (core and final). After this the two fields are merged (not yet determined in method for merging) for futhure entropy.

Non-Entropy mining has two methods, the first is entropy mining except the new block is placed either ontop or below the current block, this is switched or not switched per new final field block.

The second type of non-entropy mining is simply finding missing bit-combinations of the previous block and adding it to the top or bottom of the current block forming a larger new block.

The entropy in mining is through the programming sections of fields and the merging process (zipper | null-swaps | swap-spots | every-Nth | merge-Rebuild).

Another entropy process not yet coded is a No Knowledge Base Strings to use instead of the direct input. This is better explained in the concept paper.

A working early version of the Faux-Quantum Bits. Just click here.

What Can This Do Right Now?

    Build Zero-Knowledge-Proofs with low tech

    Build User Specific Binary Cores (up to 6 characters long)

    Determine Atomic Value of input (up to 28 characters)

    Build Corresponding Binary Field based on User's Core

    Define an abse64 [a - Base64], Binary Square, & Base64 Signature of the built User Binare Core

    Perform first wave of field mining, non algorithmic, logical comparision mining





What's Still Needed?

    Algorithmic Mining (field mining & entangled mining)

    Algorithmic Entangling to BIN Field

    Private BIN Core Signature

    Webb Data Storage based on Priv-BIN Core Signature locking

    Programable Field Input to Use During Mining & Core Building





What are Known Issues?

Binary Core becomes predictable on output after 7 characters:

After 7 characters the core output can be guessed based on if input is even or odd.

Binary Core doesn't output correctly.

The first line of the binary core build determines some of the remainder and is not always outpting correctly based on input.

Binary Field doesn't output correctly when binary core isn't outputing correctly.

Related to other known issue, the Binary field will not output correctly when the binary core isn't outputing correctly.


# Striked Out Items are No-Longer Issues or Added Features

About

Starting with building binary fields based on input data, eventually will also entangle the input or data based from the input to the binary field(s).

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages