This is a continuation of the line of thinking outlined in the previous post Adaptors Generalised. So consider that we wanted to only release a coin if a zero knowledge proof of knowledge (or ZkPOK) of the opening of a representation is known. A "representation" here is as
There's a relatively well known problem to engineers in the Lightning network, which few users or wallet developers have probably thought about (or maybe they have? I'm very glad to be wrong!). The problem is that being a Lightning user forces you to publish the utxos
Contents * Introduction * Agents on the savanna * Accidents and design * The fallacy of agency * It's not a fallacy if they're really out to get you * Agency-less agents in the P2P revolution Introduction Turning and turning in the widening gyre The falcon cannot hear the falconer; Things fall
To what extent might it be possible to have actions on the Bitcoin blockchain be enforced by verification of statements that involve generators other than the standard generator \(G\)? In general the answer seems like it should be "not at all", but it isn't trivial. I
Proof of being a satoshi millionaire. This file proves that I, as of block 861756, own 4 taproot utxos (that is, specifically unspent bitcoin) whose total value is between 1,000,000 and 1,262,144 sats. (Weirdly specific numbers? The proving system works for \(k\) to \(k + 2^n\
News
Migration of my blog to Ghost (previously I used strapi, and it was increasingly proving unusable for boring reasons I won't get into here) is currently ongoing. I will add more of the earlier articles as I get a chance. The URLs should not change. Thanks for bearing
Contents * Introduction * The Zerocoin generalisation - a false trail * Intuitions behind GK14 * More efficient 1 out of many proofs * n-ary instead of binary * Scaling of Bootle15 * Both space-efficient and linkable - Triptych * Some under-the-hood mathematics for Triptych * Why is the linking tag coefficient x^m? * Summary of technical procedure * Practical
Previous blogs in this mini-series: * Homework answer * Commit to a bit * RIDDLE It should be noted here that the first two of those are essentially required reading if you want to understand the algorithm explained here. And if you don't then just reading the first two introductory parts
Contents 1. Motivation 2. Summary of idea 3. Isn't this like X? 4. Sketch of practical use cases 5. Technical summary 6. Enforcing scarcity by preventing reuse 7. Anonymity set degradation vectors 8. Aren't the privacy promises a bit dodgy? 9. Some loose ends (Thanks to
This is the second in a set of loosely-coupled shorter blog posts. In the previous blog post, we discussed the answer to the puzzle 'how do you prove knowledge of the opening of a Pedersen commitment'? In this post, we're going to extend that, but before
A short post that while answering an earlier question, also leads into my next post(s) about a meatier topic. Talk from March 2022 on Sigma Protocols The talk I gave at "Advancing Bitcoin" in London, March 2022 was posted on vimeo here. The slides are here: sigmaproto2022sigmaproto2022.
Contents * Preamble * Science fiction Schnorr, again * Schnorr Multisignature * Fixing Problem 1 * Fixing Problem 2 * 2 round multisig in InsecureMuSig * The 4-way fork * The security proof of InsecureMuSig * The OMDL as a variant of the DL problem * Why InsecureMuSig doesn't work - Drijvers et al 2018 * The attack on