ChainFS is a new generation filesystem that uses the security of the
secp256k1 algorithm combined with the double and add algorithm, to form
the basis of the secure ChainFS file system with built in 
better-than-RAID redundancy, integrity checking and collision detection between the Infinity -> G-Node and the Infinity -> Satoshi-Node ECC Point
AST Trees.  Features an ulta-scale O(1) persistent map implementation. Java is used for this proof-of-concept, which will then be ported to C for
implementation as a new Linux O(1) filesystem based on g-nodes and s-nodes.

Disclaimer

This project is for educational and research purposes only. The authors are not responsible for any misuse or unethical activities performed using this tool.

This project is intended solely for educational purposes to help individuals understand the principles of cryptography and blockchain technology. It is important to recognize that attempting to generate Bitcoin wallets in the hope of randomly finding one with a balance is not a feasible strategy. This same logic applies to any tool that tries to work in any way the same as this.

The number of possible Bitcoin wallet combinations exceeds 76 trillion, making the odds of discovering an active wallet astronomically low. To put it into perspective, you are statistically far more likely to win the lottery every day for the rest of your life than to recover even a single wallet with funds—even over the course of a decade.

File Integrity, Redundancy and G-Node <-> Satoshi-Node Collision Detection System

New S-Node backup and collision detection created based on S-Nodes.  These
S-Nodes are created from Satoshi Nakamoto's Point on the Curve instead
of from the G-Node.  S-Nodes are the equivalent of Wallet Secret Keys
but offset by (S-Node Point - G-Node Point).  This will result in faster
collision detection than in the original system O(log n).  By achieving
Order Log N search times, ChainFS now achieves high levels of data integrity
protection in addition to fast access times.  In the event of a collision,
ChainFS will calculate the G-Node value of the Satoshi Nakamoto Point through
Subtraction (equivalent to the Satoshi Nakamoto Wallet Secret Key).  This
will allow full cross-referencing between the G-Node tree and the S-Node
(Satoshi-Node) backup tree.  Note that even though the collision system is
Order Log N, because there are more Secret Key Wallets available and Satoshi
Nodes than twice the number of Atoms in the Universe, the likelihood of 
a collision is extremely small and the Curve remains 100% Secure.

Important Note on Bitcoin, Ethereum, and USDT Secret Key Wallet Address 
to Secret Key Mapping Worker Processes

This is necessary for G-Node collision detection purposes to make sure 
each G-Node used for every single, file, index and data storage item in 
the filesystem isn't already in use by a Secret Key wallet holder (since 
there is a 1-1 mapping between Secret Keys and G-Nodes).  However, since 
there are more secret key wallets available than Atoms in the Universe 
on the Elliptic Curve that Bitcoin, Ethereum and USDT share (as well as 
every single Ethereum token), this should not be a concern to anyone that
it launches a background Bitcoin and Ethereum and USDT to Secret Key mapping 
worker than runs 24/7 continuously forever using the properties of the 
Elliptic curve to store the data, which then recursively requires more
Bitcoin etc. <-> Secret Key address mapping work (for filesystem G-node 
collision detection).

V2 Features:

- Lists all Bitcoin, USDT and Ethereum addresses for each filesystem G-node number (wallet software
  refers to these numbers as secret keys, however for the ChainFS filesystem, these are index
  nodes used for store and filesystem metadata, which also serve a dual purpose as a collision
  detection system via a Bitcoin, USDT and Ethereum mapping worker that maps every address for
  every G-node found to it's G-node number (secret key in wallet terms)
- These are listed for cross-referencing with address lists to resolve any G-node collisions 
  (secret key <-> Used Bitcoin/Ethereum addresses).
- If funds are found on any ChainFS node, work is in progress to automatically transfer these
  funds to special custodial account nodes so that the funds can be returned to the rightful
  owner.
- Keep in mind that the chances of a collision are low, even if ChainFS has to create a large
  number of G-nodes recursively to operate.  This is because the number of available nodes
  is larger than the number of Atoms in the Universe.
- All users of ChainFS can safely use as many G-nodes (wallet software calls these wallets)
  since the number of possible wallets is so huge that no-one can fathom the number.
- As ChainFS works it builds maps of Bitcoin and Ethereum addresses to G-nodes (typically
  called secrets key).  This is a recursive process because as it creates nodes, it finds the
  addresses, which it then has to store back in the G-node system using the double and add
  algorithm.
- It creates a transaction command log of all addresses that it needs to map out then an 
  NLPProcessor background task seamlessly reads them and adds the addresses to the G-node tree.
- Because of the amazing properties of the Bitcoin elliptic curve, all lookups are Order One,
  which means incredibly fast, so any conflicts with existing funded or unfunded Bitcoin,
  Ethereum or USDT wallets are immediately logged for custodial resolution.
- As mentioned earlier, the Bitcoin, Ethereum and USDT elliptic curve is so secure that even
  with a Bitcoin, Ethereum and USDT mapping process running 24/7 continuously forever, the
  chances of a collision are so low due to the endless availability of secret key wallet addresses
  (there are more wallet addresses available than grains of sand).

Advanced Filesystem Features:

- OverlayChainFS: Joins n ChainFS systems over your LAN, WAN or internet via ssh 
  or the native OverlayChainFS protocol
- Achieves O(log(N)) network performance for the G, PKx and PKy trees 
  including bidirectional Public Key <-> G Multiplier O(1) integrity and file 
  conflict checks.
  links between the numbered Sparse G AST folder tree (G, 1G, 2G ->2^256G) 
  and the numbered Sparse PKx/y AST folder tree (public key: pkx1, pkx2 etc. ->
  pkx2^512) (public key: pky1, pky2 etc. -> pky2^512) 
  to ensure that your files don't conflict with other OverlayChainFS 
  system users' files
- All intermediate G Point operation results stored in AST trees for enhanced
  filesystem integrity checking and validation (all G paths are known)
- ChainFS filesystem natively maps the G Point Paths, viewable using the
  standard Linux find command for enhanced filesystem repair capabilities.
- Local ChainFS systems achieve better than O(log(N)) (achieves O(log((1))
  performance with the g tree <-> pk tree (public key) bidirectional link files to
  ensure that there aren't any conflicts with other users.
- Features expert level O(log(1)) Modular Division and Modular Square Root to 
  ensure that all aspects of the ChainFS and OverlayChainFS systems are validated,
  including the Modular Multiplication.  Point Doubling is validated via the native
  Point Halving system.
- Features a validation and repair mechanism which utilizes Modular Mathematics
  to repair any inconsistencies in both the ChainFS and OverlayChainFS systems.
- Advanced file integrity checking mechanisms via the Modular Mathematics Module

Standard Features:

- Stores one file per g folder
- Ability to store more files than the number of subatomic particles in the
  universe  (2^256 files supported in g-mode)
- Ability to store media files alongside the g-mode files in g-mode2
- Global distributed redundancy built in along with fast access times to any file
  and associated metadata
- More redundancy than RAID systems
- Each file gets its own special g node  (storing in g mode)
- Universal distributed RAID redundancy provides a 100% guaranteed no data loss
- Ability to locate photos and videos at dedicated g nodes (storing in g2mode).
  Note that with g2mode, the parameters must include the g node number in addition
  to the media file name
- You can also store your favorite novels and ebooks securely in g2mode to prevent
  them from being lost
- The g nodes will be arranged in a double and add AST tree node for efficiency

Planned features: maintain a second AST tree of incomplete nodes (pk AST tree)
these are notes that are missing the g metadata files, with the tree leaves and 
nodes based on the double and add algorithm using the public key number). These
are also stored using the secure secp256k1 algorithm and the double and add method
but note that the g metadata in this tree is incompatible with the g metadata
in the g tree.
A sync class will be created that syncs
any nodes that match between the g tree and this new pk tree to complete the
required chainfs metadata (x,y,y^2modp etc.).  This second AST tree can also be
used for offline backup in case the internet goes down, and the data can be
sent to your distributed backup systems to guard against data loss (similar to
RAID systems, but with more features).  This will form the pk double and add
AST tree.
 
To store files in the system you must convert them to base p in numerical form
and then use the StoreBaseP class so that each file will be stored at the correct
node.  Even though it uses a folder per file, there are 2^256 folders available
so even if you took all the files in the universe, it still wouldn't use up all
the folders available in chainfs.

Any files that have been stored in distributed mode but have missing g-mode metadata
should be placed in pk AST tree until the data can be synched with the g AST 
tree.

Filesystem limits:

Maximum folder count limit in chainfs: 2^256

Standards based:

Works with existing Linux tools:

rsync - restore your chainfs from backups on your LAN, WAN, or from the internet
      - may also be used to backup your chainfs to your LAN, WAN, or to the internet
      - any new chainfs nodes will automatically be created in the correct places
        in the fs ASTTrees
scp   - can be used as an alternative to rsync
find - find an existing file or metadata file
ls - list your files