[RETRACTED] On a small-change blockchain-less cryptocurrency

 0. This entry was originally posted on 27.10.2025, though I’d been sitting on it for a while by that point. I posted it as I came up with a potentially better alternative that still promises immediate finality and no need to store anything beyond the current UTXO set, but would be better defence against double-spending. This was retracted upon posting due to obsolescence. 

1 The ask

1.1 Cryptographically signed transactions cannot be faked. If you see one, it has happened. The issue is that some would try to double-spend the same coin by hiding some earlier transactions and making it look as if that coin never left their possession. A hard problem to solve. But if you see it, it happened. 

1.2 Let’s see if we can’t build an experimental blockchain-less cryptocurrency design around this fact. It would rely on an unproven defence against double-spending and should probably be marketed as a small-change network suitable for use with sums small enough that no one would mind losing. If the defence is good enough, maybe it will grow from there.

2 The network

2.1 Every user of this network would be a full node, and every full node would store the UTXOs of all other nodes it is aware of. We’ll see that it would be in the node’s own interest to store their own full history of transactions, from genesis to current UTXO, but this is not strictly required.

2.2 All transactions are broadcast to the network. 

2.3 If a node is online at the time and receives the broadcast, it compares the transaction to its UTXO set for the two relevant nodes. If the new transaction’s inputs match its stored UTXO set, it overrides this with the new UTXO set. Otherwise, if there are one or more steps missing from what it last saw to what its seeing now, it stores both UTXO sets until such time as it can reconcile the intermediate steps. 

2.4 Two nodes transact on a fully peer-to-peer basis. To do so, they compare UTXOs as per above (again, those that cannot be filled in are retained) and, crucially, query one-another about their transaction history. I request your 100 most recent transactions, and you mine. If I can reconcile what UTXO(s) I have of you with these, all good to go. If not, I request 1’000 more, then 10’000 and so on. 

2.5 If one node cannot reconcile at least one UTXO it was storing before the transaction was attempted with the full set of history provided by the other node, that is evidence of the other attempting to double-spend, and the transaction is called off. The same applies if anything I receive from you contradicts my transaction (same inputs but different outputs, etc.).

2.6 If the transaction fails thus, the missing transaction is broadcast again to the network, helping it get into the set of nodes who may have missed it the first time.

2.7 If this was just due to shonky recordkeeping from the other node, all good, just include the missing transaction and try again.

2.8 But if you can’t do that because you have the same input going into two different outputs (double spend), then you will never transact with any other that is aware of this transaction, effectively burning all funds in the wallet, not just the offending double-spend. 

2.9 Nodes also randomly pair with one-another, which kicks off the same process sans the transfer of funds. Indeed, you cannot attempt two transactions without one such random pair in between. You can go for as many random pairings as you like, this is just the bare minimum.

2.10 If two nodes sync and find contradictory transactions due to a third party, both transactions are voided, and both nodes must take the hit in their current UTXOs. 

3 Why would this work (dishonest nodes)

3.1 Double spending in this setting relies on your ability to transact in quick succession with two nodes who are unaware of the other’s transaction.

3.2 You can’t know which node was offline or didn’t receive the broadcast for any reason when you transacted the first time. Trying this would be akin to a game of chance with poor prospects, given the necessary quick succession that two double-spending transactions should be attempted in.

3.3 But you are dastardly, so you send the first transaction and then send the second one to another node setup by yourself, to launder the funds. Since the second node was just setup, it is ignorant of the state of the world, and will take your transaction (as well as your set of UTXOs) for gospel. Good on ya.

3.4 But be sure that all successful double-spend that go through will eventually come to light through random pairing or transactions between honest nodes. When they do, you will either be still using the node that generated the double-spend, in which case your funds will be locked forever. Or, you will be using one of your aliases, in which case you will at least lose the double-spent funds. 

3.5 In all cases, double-spending will be unprofitable, as it will aways lead to at least 100% losses, if not more. 

3.6 Maybe one could set up successive nodes to launder funds ad infinitum, and attempt to stay ahead of the pairings wave. Dubious prospects of success, and nothing that a requirement to undertake some one-hour VDF could alleviate anyways.

4 Why would this work (honest nodes)

4.1 Now let’s focus on honest nodes. What can you do to make sure that you are aware of a double-spend transaction as it comes through? Remember, once it comes through, you will eventually lose the funds as the pairing process will uncover the double spend. So, it is in you interest to do what you can to vet these before you accept.

4.2 Pairing, of course, is what you do. If you’ve been offline for any amount of time, pair a lot before you transact. Pair all the time. The more you do, the fewer the chances you won’t know of enough transactions to be able to reject a double-spend when it is attempted.

4.3 Note then, how protecting against loss of funds is entirely within your control and requires bandwidth and like, just being online man.

5 How is this superior to blockchain designs?

5.1 Immediate finality is allowed, although double-spends will still affect you a long time after they succeed, if they do. 

5.2 Each node is only required to hold their own full transactions history, and the set of as-of-yet-unreconciled UTXOs of the other nodes, far less onerous requirements than making a redundant copy of all transactions ever made. You could run this from your phone.

5.3 No hashing shenanigans required, and the network is still fully asynchronous.

5.4 No equivalent to a 51% attack. 

5.5 Good scalability, although the ability of random pairing to uncover double spends with a growing number of nodes (most of which legacy nodes no longer active) does come into question.

5.6 It would be worth hard-coding requirements for nodes to come online for pairings at least once a year, if only to limit legally nodes clutter.