Thoughts at Random

The main idea: two joint cryptocurrencies are programmed such that one can be exchanged for the other as long as their product remains constant, thus tracking the minimal necessary volume of circulation required by a growing economy in a decentralized fashion.  0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 30.09.2021, and the current version may have been updated several times from its original form. 1 The issue 1.1 The only credible challenger to the current system of a centralised issuer of currency would be a decentralised system under the auspices of cryptocurrency. Alas, most of the time, the designers of these ingenious tools just went with “fixed supply is good enough” and left it at that, making cryptocurrency a great store of value, but a shonky unit of account. And how much worse this issue becomes when the user base is growing faster than the global economy (which of course it does)! 1.2 I’ve earlier e...

The main idea: enforce network security through social consensus whilst retaining a decentralised architecture.   0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 18.12.2025, and the current version may have been updated several times from its original form. 1.1 Let’s strip back as much as we can from the Nakamoto consensus, and re-build from there.  1.2 We have transacting nodes who store blockchains, and miners who work on existing chains by adding successive blocks, who then must compete for adoption by the nodes.  1.3 We have, so far, no proof of work, no adoption or consensus rule, no block time, and no block limit.  1.4 Indeed, suppose for now, that each node is entirely free to pick whichever chain they deem fit. We will narrow this freedom quite a bit in 1.24, but for now assume this is the case. 1.5 The first step to re-establish some order in this chaotic primordial soup is Rule one , ev...

The main idea: adopt a self-splitting token to mostly counter excessive appreciation or depreciation against the Dollar.  0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 06.11.2025, and the current version may have been updated several times from its original form. 1.1 So it’s not easy to come up with Tier 3 currency designs , but do these have to be as complicated as this one ? 1.2 Well yes, if you want a fully self-contained and indefinitely sustainable system. But can we cut a few corners to gain simplicity and legibility? 1.3 You create a given quantity of your token, and no more can ever be created after this point. You pool it all in an (ideally native) Automated Market Maker with a quantity of some reliable stablecoin (assume USD links). This is our price oracle. 1.4 The token reads its price against USD continuously, averaging on a running week basis, and comparing against the same running week average four...

The main idea: make the reward for mining each new block an inverse function of the block number in the chain.  0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 10.12.2024, and the current version may have been updated several times from its original form.  1.1 For those doubtless very few souls who are somehow still unconvinced by my  design of a cryptocurrency of dynamic supply , here's an alternative setup that can be bolted on with minimal effort into any bog-standard blockchain and still institute the basics of tolerable monetary supply management.  1.2 When new units of this cryptocurrency are awarded for the successful creation of a new block, just set this amount to a/n, where a was the initial issue at block one, and n is the order the new block has in the longest chain. Unlike some current setups, you will always issue new coins for new blocks, although the amount will be ever smaller. ...

The main idea: set the chance of being selected as a validator proportional to the square root of one’s stake, but allow reward to remain proportional to the stake itself. 0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 08.01.2025, and the current version may have been updated several times from its original form.  1.1 Let try to limit the alleged tendency of Proof of Stake systems to centralise around large holders (and optimise a few other issues as well) below. 1.2 To begin with, we let one’s probability of being selected as a validator be proportional to the square root of one’s staked sum, instead of the staked sum itself. To avoid the issue of numbers lower than one having squares larger than themselves, set the actual function to SQRT [1+ STAKE] - 1.  1.3 We have introduced an incentive for would-be validators to split their stakes into multiple wallets to, at the limit, recreate a linear relationship be...

0. This was originally posted 03.02.2025 and reluctantly retracted on 18.12.2025. The issue with the design is that it relies on secure time-stamps, without which it can't prevent double-spends from forcing the network to diverge, and "first seen" does not work here as it does for Nakamoto. Whilst the design might be salvaged by some more trickery and thought, I have reused elements of this deign in this alternative architecture, which I like better for now. 1.1 Since we’re after shaving time, you start by taking the Proof of Work out of the blockchain. You still need to hash the block’s contents with its predecessor’s hash to establish a sequence, but there are no further requirements made of the hash itself. This will become important for efficiently checking long chains soon. 1.2 Next, you allow all potentially double-spent transactions to be included in the chain without rendering the chain invalid. You still omit transactions that are invalid due to issues with sign...

 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...

0. This entry was originally posted on 22.01.2025, and retracted on 8.3.2025, though I still leave these up. The issue with the first design is that hash difficulty is exponential to the number of leading zeroes, so scoring chains by total count of leading zeroes would simply incentivize one-zero hashes. You can rescue this by scoring a chain as the sum of exp(K) over all blocks, with k being each block's count of leading zeroes for a hopefully time-neutral score. But then we're simply tracking the hashing time invested in any chain, so roughly the same (without controlling for computing power) as the VDF count system, at which point the critical issue with both designs emerges: they offer no protection again deep reorganizations. Nothing would stop a miner from accumulating VDF cycles on a stale block and potentially have this chain become equal to or even surpass the main one in terms of total cycles, at a catastrophic loss of information. Indeed, whoever runs their machine c...