Thoughts at Random

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 was originally posted on 22.10.2025, and retracted shortly thereafter on 14.11.2025, though I still leave these up. The design proposed here was simple, indeed so simple that it does very little monetary management, but mostly serves as a gauge of the natural interest rate. If demand for money increases, the market turns consols in but we quickly adapt and slash the price until equilibrium is restored. The only actual money being created would be in the short period before full equilibrium is reached, after which we are left with higher rates. Now, the system can be salvaged quite easily by adding a second step, where the monetary authority separately conducts open market operation on FX such as to target a stable price (yield) for these consols. But by now we're just doing standard central banking without the frills, so nothing particularly novel here, and in case the alternative model does this and more. 1 The setup 1.1 Let’s rejig one of my earlier mechanisms to come u...

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

0. This entry was originally posted on 09.02.2024 and retracted on 17.12.2025 when I finally bothered the check the expected outcome function. Fine, I get it. 1.1 You and a bunch of others have recorded your expectations that a given event will happen or not in the future, with the event being binary, and predictions in the form of 0 – 100%.  1.2 Further, each of you has put some money towards the pool. No odds were given to you when you did either of these things. 1.3 Now how you score the predictions and allocate the pool: the pool is allocated in weighted fashion, where each participant’s weight is the product of their contribution and the probability they assigned to the event (probability of occurrence if the event occurred, and one less that if the event didn’t occur). 1.4 With bets were made at different points in time, a bit more thought is required. Naively, one may just add a third term to the weight product there, this being the total time outstanding, but I fear there m...