Thoughts at Random

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