This thread is not about an existing or soon-to-exist altcoin.
It's just a discussion about optimal/ideal cryptocurrency implementations.

I have been thinking about what an "ideal" might look like in terms of cryptocurrency implementations.
This is more of a dream I had, rather than a concise recipe on how to build a cryptocurrency.
It is probably unfeasible, except in my dreams, but I had to write it down.


WEIRD PIPEDREAM CONCEPT FOR THE "IDEAL" CRYPTOCURRENCY:

- The "state" of the system is stored publicly, however it appears to be a jumble of meaningless numbers.
  NOTE: I make heavy use of a "printing" analogy in this description.
  Imagine the system state is like a piece of paper onto which transactions (preimages) are printed on top of one another.

- The size of the system state is (num_coins)*(address_length). For example, if the total number of coins is 1 million (1e6) and an address is 100 bits (1e2), then the state is 100 million (1e8) bits in size = 12.5 MB (for example).
- An address can only contain one coin or no coin. A transaction simply consists of an origin and destination address.
- The state "encodes" only the current state of the ledger, not the historical state - nodes are welcome to save historical states, but it is not necessary.
- The "encoding" is obfuscated - to make a payment, a user first creates their signed funding transaction, then performs some kind of magical mathematical operation (TBD) that encodes their transaction into a piece of data the size of the system state - creating what we'll call a "preimage"
- The transaction preimage just looks like a bunch of garbled nonsense to anyone without the pubkeys of the origin/destination address.
- For someone with no information about the pubkeys involved, they can verify if the transaction is valid by downloading the latest valid system state, imprinting it with the transaction preimage, and seeing what the resulting "balance" is.
- It is possible to create overfunded preimages - known as "payment" preimages - as well as underfunded preimages - known as "invoice" preimages.
- The mechanism through which transactions are sent is by sending a payment preimage or invoice preimage to the payer/payee respectively, who then imprints this with their respective invoice or payment preimage to complete the full transaction preimage - i.e. balance = 0 - then submits it to the network.
  For example, if you want to send funds to an as-yet unknown address, you can just send the person the payment preimage through an encrypted channel, and then they can simply "imprint" their invoice preimage onto it.
  Or conversely, if you want to receive funds from an as-yet unknown address, you can just send the person the invoice preimage - no need to send through an encrypted channel since it doesn't represent any unsecured value - and then they can imprint their payment preimage onto it, then submit it to the network.
- After this, the transaction preimage can be sent to a node operator, who will imprint it onto the current system state.
- The system state is nothing more than the total sum of imprints of all prior transaction preimages starting with the genesis block - all of which is entirely obfuscated.
- An incongruous transaction preimage - i.e. a transaction preimage where the origin address contains no coin, or the destination address already contains a coin - will simply return a negative/positive balance (from the destination address) when the preimage is imprinted with the system state.
  In this way, even if a transaction preimage is imprinted twice (or a thousand times) onto the system state, the subsequent imprints will not cause problems.
- The system state is updated by way of gathering and imprinting transaction preimages in a completely unordered fashion. A multitude of transaction preimages could be gathered by a node operator, all imprinted together to form a "preimage set", and submitted to the network in one go. A preimage set is indistinguishable from a single preimage to someone without knowledge of the addresses/pubkeys.
- Even if there are millions of duplicate transactions - e.g. when one node operators system state is imprinted onto another node operators in order to settle two "tails" - the duplications will be invisible in the output.
- In this way, consensus is achieved, even though there is no blockchain to speak of. Even though the system is highly chaotic and unordered, the state is always valid.
- If a node operator attempts to proliferate a completely fabricated system state, it will be instantly recognisable to all users, since EVERYONE's coins would disappear.
- Node operators are incentivised not to proliferate old states, since they can be paid by users for updating the system state with new transactions. Most likely, users will submit overfunded transaction preimages that they send to node operators, who then imprint the preimage with an unfunded invoice, and imprint this onto the system state.
- Alternatively, users could request invoices from node operators for submitting their transaction to the network. If a user wanted to make certain their transaction would make it into the consensus system state, they could even pay multiple node operators with a single transaction.
- Note that at any time, anyone can add payment onto a preimage or preimage set. For example, if the receiver of a payment wanted to bump their transaction, they could resubmit it with additional payment.
- Additionally, node operators could use fees they've collected to pay other node operators to accept their preimage set.
- Conflicting states - i.e. double spends - are resolved automatically during imprinting. Imprinting is a non-commutative operation: if state alpha contains a transaction spending from address X to address A, and another state beta contains a transaction spending from address X to address B, then the order of the imprint operation will decide which of A or B receives the payment. If state alpha is imprinted onto state beta, then address B will receive the payment. If conversely, state beta is imprinted onto state alpha, then address A will receive the payment.
- Someone who wishes to surveil people's transactions can only do so by archiving all states and preimages/preimage sets he receives, and then imprinting them with new states and preimages/preimage sets, and comparing the difference, thereby building a model of the differences in time. It might be possible to surmise some transaction information this way, but it will be difficult and resource intensive.


I know all this probably sounds ridiculous and impossible to anyone who knows anything about cryptography. This is just a thought I had and I had to write it down and share it somewhere.
Please let me know what you think.Would love input from cryptography experts.

Cheers,
Tony