Topic: Pipedream idea for an "ideal" cryptocurrency (Read 96 times)

Maybe you'll like an idea of consensusless cryptocurrency. Instead of consensus mechanism, it relies on quantum unclonability to solve double-spends. Although personal quantum computers are in a galaxy far, far away... there are theoretical works towards, for example, https://arxiv.org/abs/1711.02276

Sorry for the incredibly late reply.

The idea behind the "soft consensus" is that in the end data equality *will* be achieved, because for a given transaction, one state will prevail over the other and be forever propagated by the network. The clashing transaction will eventually be rejected because of the opportunity cost of endlessly propagating a clashing transaction which is not likely to prevail (and therefore pays out no fees). Also, as a node operator, you can't just tack the clashing transaction onto every set of preimages you send out to the network ad infinitum in hopes that it will eventually be accepted, because then every state you send would be considered invalid, and all of your transactions in the set would be rejected. Users and node operators can try as hard as possible to propagate a given transaction by splitting the fees and paying other node operators to accept the preimage, but there is a limit to how far it can go.

One thing I didn't mention in my original post is that there are no miners per se. The nodes are the miners. But they are not mining in the usual sense - i.e. solving pointless mathematical problems to no end - however they are still expending energy and bandwidth trying to propagate the transaction preimages they have received in order for them to get paid out before other node operators.

Also, fundamentally there is no distinction between users or nodes either. Nodes are just users who are trying to make money out of propagating transactions. Probably they would have servers, fast internet, and their own algorithms to try to optimise extractable value.

The good thing about such a cryptocurrency is that it does not require any "core" software to interact with the network. The only "rule" that exists is what a preimage should look like, everything else is irrelevant. There is no block reward, no difficulty adjustment, no block size limit.... it all happens chaotically like water flowing downhill.


The overall purpose of this exercise is to try to imagine a cryptocurrency with as few arbitrary design decisions as possible.
Bitcoin and other cryptocurrencies are basically just hundreds of arbitrary decisions cobbled together into something that works. It works, so I can't be that critical of it, but I think we can do A LOT better if we rethink from first principles, and try to avoid arbitrary design features.

Consensus is not about validity, it's about equality of data, which may be invalid and/or unordered. Although later you admit the need for a partial order to resolve conflicts, it's not clear what exactly you mean. There you can see how some projects aim to leverage a total order of potentially invalid data to get higher programmability & scalability: https://bitcointalksearch.org/topic/celestia-tia-the-future-of-modular-blockchains-5478975 Anyway, a node itself is not a resource of consensus, which has to be based off of something unforgeable. We had an entertaining thread about this recently: https://bitcointalksearch.org/topic/can-we-reduce-the-energy-consumption-of-pow-and-whether-it-is-necessary-5478152

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 use of a printing analogy in this description.
  Therefore it might help to visualise the system state as a piece of paper onto which transactions are printed, one on top of the other. Imagine each transaction looks like one of those "magic eye" 3D images, and they all get printed on top of one another, creating an unrecognisable mess.
- 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 like the system state.
- For someone with no information about the keys/addresses 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 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 realise the system state would be prohibitively huge if you scaled it up to 2.1e15 coins and 160 bit addresses like bitcoin. It would be something like 32000 TB. I am hoping there is a way to collapse the state down to some  kind of sparse representation like bitcoin. Or possibly have multiple chains operating in isolation which have smaller states, and then a way of merging smaller and larger state systems.

EDIT: I have a hunch that the encoding scheme would need to make use of Fast Fourier Transforms... just a hunch.


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