From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 23 Aug 2026 16:58:09 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wyI4l-0006dB-Ks for bitcoindev@gnusha.org; Sun, 23 Aug 2026 16:58:09 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-458326d2d9asf5723993fac.2 for ; Sun, 23 Aug 2026 16:58:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787529481; cv=pass; d=google.com; s=arc-20260327; b=PIzREyAqX/hYEZEOZPx1ExiLAhenj3j7WBtsyQGoxCJ2sbQ1FYEWpXH4fWo/YIVYpZ oiOD6c003MLiQ1g1lAwlMioiWVNfjYnkFjqvBHJHx32O6GfwYK6zc+09G93xtBdA1r6S AlmVnlFeJeI1OyGnwF8gPDWmMl66h5pCyM03v2eDNIXOGFOs2asqLgPFhRM9GiiONtKz Pf+ZSdsnZPkV47pZ6kSYr0+g6huFCeDpbL8r/khJOlM98ZyDALKHo8Wm0fXrQlNtk/Dh z1MwKXOWZkaDrqUretMSQcbbbu4ygjgWVJ67PYMio2pCFWEgDv4/6iGX6IxL2ukR4Wc9 Fl3A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=cnH+zZoDMSiCqLu+W9v9yXNXHaZ56lqszb6XuJJdUhM=; fh=AtQ4HBrQhZ5S6ZdbT3woFRJM2TjDfR5zHZPPgrNvV0U=; b=OZmXms7QIkg7lqJ5LBlbcdb9HAGwXvEJkNsPq5u+1eDDX0KVIh9fQS1beGLM1cSyQg G8FXFlmLap4INljGxZNQxhYnpabKQekq51FGKRvlqv5oW/SpmHIPm/upJwvXeTByMXp3 UdJmGZUFy9PEb8XNsX9kWHuTqLAxsGi09cWoKSKw39M9fC4JSksE6aMYl/NniW1Io4Kt TiBwlNyaBC23SwP6f94CfuQK5SkVs4RkbAlYuCDgV1mkl/X9lhJhq/K7Vld+SAdk9QZh tf+kTBqI5jBnCj4NsRQ/OTghVZBRSJs1hBZ9tbxZRB4OQd5fpKckgbNFBlCpuXc5MhqA Y2Xg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="Ae/3MFkF"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787529481; x=1788134281; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cnH+zZoDMSiCqLu+W9v9yXNXHaZ56lqszb6XuJJdUhM=; b=k5JG3SCj6fHGFp7nFZgfmaDlv/znw2Kq6/pjl9RjCUTnv5yAc5RXIbXQXGOqn66fHp w3/k0ZaeB7au83suemYwi+kOoeKLXgBLtGPWhrrgNe4D/inGGoj5sbVVUnzVO5As5dhQ rzCavgmgph7BSDkx7O7+C1D+eO4PfJ1U+TTi9dhxRUlU08PLkhA9OrdPUwYaCK9JcL6M 3KZYezfO9D3cA0vxY/mJk3K1MPyBHrLgrnz4L/LEaMsKLr9EycGtM9FAFIAmhhIVpqFS INCtfDHjtx2FL5toOWb8WvukNTaZbjuow3/Nl+PAVMJqzy7sFS8xsqbaSpmGytIpNjwQ XlXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787529481; x=1788134281; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:content-type :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:x-beenthere:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=cnH+zZoDMSiCqLu+W9v9yXNXHaZ56lqszb6XuJJdUhM=; b=kr448LF65vzgEfDeRgTZHIdnBV0Y+g0e5zDmWeCHL3mbrA0muN4KFC79BBPFJT1i+o ZmEYcbQwKGE69IL1BXhvu8ai4sSYg6ecz/vPwWFP0GSY8/hv7v63OoUhBN9bZTrcq0L7 u0x7WXJTBFLOqhcRaAX+UTqWXJvu3L0UqH9FEkTR5smUawMt5tJaz2fvlGSzRAmziQD4 IpIBz9gRl5RXhWIk0Sy5MxePnP5LNCT6N7DMOcEv31I+aYoH2RYp+QvaY4SM9mraKw3W op3kjIVeM3KaxVgaTsoXCN5H05kYD9ioqlpNA+KtTPDrHECn8EjOoWjsZ7Qt2qiuaXGQ sPbA== X-Forwarded-Encrypted: i=2; AHgh+RpDdt3O3pyI9v8gyFOk3LDU/VED1UqgZmqt7zkg6itBjxgZ9Ywyq+7qXDGLDJR0YZmD8rQD/4lVknA3@gnusha.org X-Gm-Message-State: AFuF++m1YSj+wjKnUMnVHvBVnHAhhmRL8ujpYml68QelOSkGh4KRNJUe iLs1U+SCYwNy/livm3dlnFG5ROfZU4lOyWfxJzEf8fdt4dPp/FhpJ0nz X-Received: by 2002:a05:6820:2202:b0:6b1:7338:639f with SMTP id 006d021491bc7-6b17338648amr9264193eaf.1.1787529481074; Sun, 23 Aug 2026 16:58:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdezJvLQ/bAUQ7KKkopNbFB1kMv6n5esZTKUspFuEmb0dg==" Received: by 2002:a05:6870:a693:b0:451:b6f0:d131 with SMTP id 586e51a60fabf-463d92c6e52ls167975fac.2.-pod-prod-07-us; Sun, 23 Aug 2026 16:57:55 -0700 (PDT) X-Received: by 2002:a05:6808:6905:b0:4a4:c12:46f6 with SMTP id 5614622812f47-4b2ef1db8c7mr28176256b6e.2.1787529475460; Sun, 23 Aug 2026 16:57:55 -0700 (PDT) Received: by 2002:aa7:d1c4:0:b0:69c:20b8:fa6f with SMTP id 4fb4d7f45d1cf-6a43261fcdamsa12; Sun, 23 Aug 2026 16:28:38 -0700 (PDT) X-Received: by 2002:a17:907:8990:b0:c20:3679:a2e6 with SMTP id a640c23a62f3a-c24925eb3ffmr1694003166b.10.1787527717120; Sun, 23 Aug 2026 16:28:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787527717; cv=none; d=google.com; s=arc-20260327; b=pW0waVyAYa0xZKXsTbRceY0Z74OiW1BEff2Z4LoquEWfRbcyOeFt+ej32rfItNfgck /t9YXmPg/UOTYf4mPEUKSeyGYoud+OAFUY5OVuK1c4W0EtpJqoghpbKRs/3FXIcKWNNy d5SWx+3lfs6hXy0qLbtijWS7P7g6D0BGqUV2WxoNhxZoZ0QhVfksTn1M8RjJkQJ+ViW1 hbojFqDXNLON5Ar2uVLuAXGsjcPzl5ucWcDybg7GJ+yPVRkoPtePccaet9mIuk+O0POo HAX7VqAc0SjXUVP93vS1XIB1C+BH4OqztSRDOTQaxXzzCAnJW0Bjs14MQxHFph1Kp3yk Y3aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=ZfJUfRs3KSnkIXXEBmo+fTUWhUsWHP11MwTCqm7Oryg=; fh=dlutK8OVSXZMvGs0yXMvRuJ80eEPgjdlF6Ndg5si4Pw=; b=QWpf2C5trHMHfhJJPvGFnxpsCqjzsNzEJfxB/EBFnKbRAjhKZKmNwtMjuJ34krNi16 fvXT4y5iDB85SQjgWUem/gUKtRzQfG4jX1r4eRHGQso14tjMfYyEeuJg8XN1cFfjdSZF IcMYanw0Pecmc11KUy9HfSxGWPe/muafcIX2B2k4pvXoc1Fl6dy8rGkvfAZ8qWATeHdA X1ChL9PGi0nZXGrqCPD65wD2eennwLyP2wjelHuxNBSXh/B9TxFRTglNl/zOI4Dyfe+K jki+a4Yeoc48o9GT82eYycOD54RwPWffl8jt11alGVy4D6OY6hZY/2t/EP2p0W6V4tFy NUTg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="Ae/3MFkF"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43166.protonmail.ch (mail-43166.protonmail.ch. [185.70.43.166]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-c249512fbb2si8150966b.3.2026.08.23.16.28.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 16:28:37 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) client-ip=185.70.43.166; Date: Sun, 23 Aug 2026 23:28:33 +0000 To: Alex From: "'conduition' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: =?UTF-8?Q?Re=3A_=5Bbitcoindev=5D_DropKick_=E2=9A=BD=EF=B8=8F_=2D_A_minimal_commit=2F?= =?UTF-8?Q?reveal_PQ_rescue_protocol?= Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: eb7a8647a0c686918226db23fe24402cb3174aa4 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------41ab364d885951ced9a363ac671dbe9c56ac04c0e91a0c1d7a85a812eb6f938b"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="Ae/3MFkF"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------41ab364d885951ced9a363ac671dbe9c56ac04c0e91a0c1d7a85a812eb6f938b Content-Type: multipart/mixed;boundary=---------------------fc32395383c12d002d6a553a3144d601 -----------------------fc32395383c12d002d6a553a3144d601 Content-Type: multipart/alternative;boundary=---------------------79178a03fa1bc504903d29d235de5f38 -----------------------79178a03fa1bc504903d29d235de5f38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Alex, > We need to have an already functioning PQC solution for Bitcoin itself, d= eployed, before any of commit/reveal can help, right? Yes. Two reasons: First, without on-chain PQC, making commitments would be impossible to do s= afely unless commitment are aggregated directly by miners into the coinbase= transaction. Second, without on-chain PQ-secure addresses, where would one even rescue c= oins to? Commit/reveal protocols are meant as a tool saving coins in an eme= rgency, not for everyday spending. PQ signature schemes are therefore needed as a prerequisite. regards, conduition On Saturday, August 22nd, 2026 at 1:46 PM, Alex wro= te: > Am I correct in understanding that commit/reveal always depends on someon= e else already having a valid PQC UTXO to spend? > So in other words, this can never be a solution for a (procrastinating Bi= tcoin system), only a solution for (procrastinating Bitcoin users). >=20 > We need to have an already functioning PQC solution for Bitcoin itself, d= eployed, before any of commit/reveal can help, right? >=20 > Den tors 20 aug. 2026 23:56'conduition' via Bitcoin Development Mailing L= ist skrev: >=20 > > Dearest friends, colleagues, and lurkers, > >=20 > > I would like to present for your consideration a new commit/reveal resc= ue protocol to save the coins of quantum procrastinators - those who take n= o action to move their coins to PQC-enabled wallets by Q-Day. > >=20 > > https://conduition.io/bitcoin/dropkick/ > >=20 > > The term "DropKick" is self-descriptive of its usage: Drop a hidden com= mitment somewhere on the blockchain, and reveal it later with an SPV-style = proof to Kick (spend) your legacy coins forward to a new PQ-secure wallet. > >=20 > > Background > >=20 > > As with any post-quantum commit/reveal protocol, DropKick uses the bloc= kchain as a trustless timestamping service to prove than an honest user had= earlier chronological knowledge of some secret witness to a quantum-hard o= ne-way function. The honest user hides a commitment in a block, waits for c= onfirmations, and later reveals her commitment to certify she knew the secr= et witness long before an adversary (like a quantum computer) could have do= ne so. Assuming this witness was indeed kept secret prior to reveal time, i= t is already too late for the adversary to forge an equivalent proof. > >=20 > >=20 > > This general mechanism also allows validators to distinguish an honest = bitcoin-holding procrastinator from a CRQC in many situations, and so procr= astinators can still authorize spending of their legacy UTXOs even well aft= er Q-day, provided the rescue protocol is deployed before Q-day as a new en= cumbrance on affected legacy coins. > > DropKick In One Paragraph > >=20 > > DropKick specifically is a commit/reveal protocol where the commitment = `H(H(w, Q), Q)` is hidden somewhere in a block, such as an OP_RETURN or ins= ide a taproot tweak. `Q` is a post-quantum public key, and `w` is the witne= ss to a one-way function `f`, such that `s =3D f(x)` is the script pubkey (= address) encumbering a coin. We can later reveal the witness `w` and a sign= ature from pubkey `Q` to authorize a spend, along with an opening proof sho= wing that the commitment was included in a prior block. The verifier checks= the commitment opening is valid and sufficiently old, checks `s =3D f(x)`,= and verifies the PQ-signature from `Q`. > >=20 > > See this section for the actual proving/verifying steps of the protocol= . > >=20 > > Features > >=20 > >=20 > > Generality: DropKick generalizes to any efficient [1] one-way function = based on knowledge asymmetries - things the honest user knows which the adv= ersary doesn't. In the context of Bitcoin, the one-way function would typic= ally be a computational pipeline that includes hashing of secret data unkno= wn to a CRQC, such as "BIP32 hardened derivation of an address" or "hashing= a public key or script to build an address" or "taproot key tweaking". Dro= pKick can be instantiated with different one-way functions to encumber diff= erent coins. > >=20 > >=20 > > Compatibility: DropKick can be deployed as a soft-fork, as it only tigh= tens spending validation rules, and does so only on certain UTXOs. > >=20 > > Confiscation: DropKick can be deployed without confiscating any coins, = if so desired, by deploying it as an encumbrance only on UTXOs with decidab= le knowledge asymmetries like hashed addresses (see this section). If one w= ishes to maximize the number of legacy coins rescued, DropKick can also be = deployed on undecidable knowledge asymmetries like BIP32-CKD. To be clear, = P2PK coins cannot be covered by DropKick or indeed by any rescue protocol, = as these UTXOs have no known knowledge asymmetries when a CRQC is in play. > >=20 > > Blockspace Efficiency: DropKick has near zero on-chain impact until rev= eal time, at which point the commitment opening proofs are included in a re= veal transaction spending the legacy coins. Opening proofs could be attache= d in an OP_RETURN for backwards compatibility, or for better efficiency the= proofs could be attached in a new transaction witness field which would al= low for the 4x segwit discount to apply. DropKick opening proofs are approx= imately the same size as SPV or OpenTimestamps proofs (less than a kilobyte= ) and those proofs can be reused to rescue multiple related UTXOs, e.g. coi= ns on the same address, or coins on addresses derived from the same seed. > >=20 > > Performance: DropKick opening proofs cost very little to verify: a few = hash invocations, about as fast to verify as an SPV proof or lamport signat= ure of the same size, and the cost of verification scales linearly with the= size of the proof. If one has `txindex=3D1` enabled, verification is even = faster. The only prerequisite data needed to verify the opening proof is th= e set of all Bitcoin block headers. Verifying the revealed witness `w` is e= xactly as efficient as evaluating the one-way function `f(w)`. > >=20 > >=20 > > Ergonomics: Procrastinator do not need to have their own PQ-safe UTXOs = available to execute a DropKick rescue: Users can delegate their commitment= s to untrusted third party servers called "aggregators" who do have PQ-safe= UTXOs. These servers take it upon themselves to aggregate the commitments = of other users together into a merkle tree, whose root they publish on-chai= n. Those aggregators can charge a salvage fee for their services if desired= , paid in-band from the rescued UTXOs, or up-front out-of-band. Procrastina= tors can shop between different aggregators, and anyone with PQ-safe UTXOs = can operate one. > >=20 > > Comparison to Lifeboat > >=20 > > DropKick competes directly with Tadge Dryja's Lifeboat/Lifejacket propo= sal (also see this older post), but DropKick aims for a different (lower) d= egree of security in exchange for a simpler implementation surface, more fl= exibility, and better efficiency. > >=20 > > The two protocols fulfill functionally similar roles, so I will take a = moment to compare and contrast DropKick and Lifeboat/Lifejacket. > >=20 > > DropKick includes some novel features which Lifeboat does not, such as = key certification (allowing things like RBF, or equivocation, by the honest= spender), or generalization to arbitrary one-way functions. Such developme= nts could be easily transferred to Lifeboat as well, so I will mostly ignor= e these minor differences here. > >=20 > > The fundamental difference between DropKick and Lifeboat is the commitm= ent ordering requirement. > >=20 > >=20 > > - Lifeboat requires procrastinators to (1) procure a PQ-secure UTXO, = and (2) upload a ~96-byte commitment in-the-clear in a new transaction, suc= h as in an OP_RETURN or inscription. Validators must index all such commitm= ents, so that they can chronologically order the revealed commitments later= . Reveals reference this index to authorize spending: Only the earliest val= id commitment for a given witness is allowed to spend the legacy coin that = witness unlocks. > > =20 > > - DropKick encourages procrastinators to hide commitments in merkle t= rees committed into blocks, such as via a merkle root posted in an OP_RETUR= N, or in a taproot-style key tweak. Reveals use SPV-style proofs to convinc= e validators that the commitment was included in a past block. Validators t= herefore do not (and cannot) index all commitments, and so there is no way = to confirm any one commitment was earliest. > >=20 > >=20 > >=20 > > By dropping the commitment ordering requirement, DropKick skips the nee= d for a new index database collecting all the commitments, and this frees u= s from putting commitments on chain in-the-clear. DropKick commitments can = be hidden off-chain, but anchored to the chain in merkle trees of arbitrary= size, which is the key feature that enables the new role of aggregators, a= nd means procrastinators don't need PQ-UTXOs to publish a commitment and re= scue their legacy coins. > >=20 > > To gain these benefits, DropKick sacrifices some security, by admitting= miner censorship attacks where miners can intentionally censor a reveal tr= ansaction to gain a chance to steal the procrastinator's coins. Lifeboat en= tirely avoids this class of attacks, whereas DropKick requires a somewhat l= oose game-theoretical argument that miners will converge on choosing not to= censor reveals, provided we enforce a long delay (days or weeks) between c= ommitment and reveal steps, and provided the procrastinator pays a proporti= onal fee to incentivize honest miners. We also have to assume no 51% reorg = attacks of course, as a malicious hashrate majority could easily censor any= reveal transactions and so steal coins. > >=20 > > However, if this security loss is acceptable, DropKick offers a much si= mpler and less complex engineering surface area, and supports rescuing user= s in more diverse situations than LifeBoat can (because PQ UTXOs are mandat= ory in Lifeboat). > >=20 > > LifeBoat's UX advantage over DropKick is that because of the ordering, = there is no long delay or value-proportional fee needed: Users only need to= wait a few blocks between commit and reveal stages, and they pay only regu= lar mining fees as usual. DropKick OTOH requires a delay proportional to th= e fraction of the UTXO one is willing to sacrifice to miners. E.g. if we as= sume users are willing to sacrifice 1% of their UTXOs, then we need to enfo= rce a reveal delay period of at least 100 blocks. See here for a derivation= of these parameters. > >=20 > > Conclusion > >=20 > > So that's it. > >=20 > > I'm submitting DropKick here as a sketch for consideration, not as a co= ncrete proposal. I am most interested to know if anyone can think of a bett= er mechanism to avoid miner censorship attacks, or if we can at least reduc= e the strength of the assumptions needed for DropKick to resist them. > >=20 > > regards, > > conduition > >=20 > >=20 > > [1]: The one-way function must be efficient so that verifiers can recom= pute it to validate reveal transactions without DoS risks. For example, BIP= 32 master key derivation via BIP39 is not considered efficient because it u= ses PBKDF2, whereas BIP32 CKD is efficient if restricted to a maximum deriv= ation depth. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send = an email to bitcoindev+unsubscribe@googlegroups.com. > > To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/ruufSzDPIml1W5hF-m_IJLeBzuhqey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDe= sW61FaU_asfj39Ri1QgSXtz7-OekEt6bbTvo%3D%40proton.me. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= O_i0gml6GTRro49f8c8jlCmgwOH5ZMDsJg4zxe-pX6akiGaibaFP7ilCTX90ZDfKORvmd3YlU4U= UZWkwI-NPlvEtY8eVAvCFqO_ckuMG7m8%3D%40proton.me. -----------------------79178a03fa1bc504903d29d235de5f38 Content-Type: multipart/related;boundary=---------------------5fe4b998cc48bdcaa841defdb04e8616 -----------------------5fe4b998cc48bdcaa841defdb04e8616 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Hi Alex,
<= span>
We need to have an already functioning PQC solution for Bitcoin itsel= f, deployed, before any of commit/reveal can help, right?
Yes. Two reasons:
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
First, without on-chain PQC, making co= mmitments would be impossible to do safely unless commitment are aggregated= directly by miners into the coinbase transaction.

Second, without on-chain PQ-secure addresses, wh= ere would one even rescue coins to? Commit/reveal protocols are mean= t as a tool saving coins in an emergency, not for everyday spending.=

PQ signature schemes are therefore needed as a prereq= uisite.

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">regards,
conduition
On Saturday, August 22nd, 2026 at 1:46 PM, Alex <alexhultman@gma= il.com> wrote:
Am I correct in understanding that commit/rev= eal always depends on someone else already having a valid PQC UTXO to spend= ?

So in other words, this can = never be a solution for a (procrastinating Bitcoin system), only a solution= for (procrastinating Bitcoin users).

We need to have an already functioning PQC solution for Bitc= oin itself, deployed, before any of commit/reveal can help, right?

Den tors 20 aug. 2026 23:56'conduition' via Bitcoin Deve= lopment Mailing List <bitcoindev@googlegroups.com> skrev= :
Dearest friends, colleagues, and lurkers,

I would like to present = for your consideration a new commit/reveal rescue protocol to save the coin= s of quantum procrastinators - those who take no action to move their coins= to PQC-enabled wallets by Q-Day.


The term "DropKick" is self-d= escriptive of its usage: Drop a hidden commitment somewhere on the b= lockchain, and reveal it later with an SPV-style proof to Kick (spen= d) your legacy coins forward to a new PQ-secure wallet.

Background

As with any post-quantum commit/reveal protocol, DropKick = uses the blockchain as a trustless timestamping service to prove than an ho= nest user had earlier chronological knowledge of some secret witness= to a quantum-hard one-way function. The honest user hides a comm= itment in a block, waits for confirmations, and later reveals he= r commitment to certify she knew the secret witness long before an adversar= y (like a quantum computer) could have done so. Assuming this witness was i= ndeed kept secret prior to reveal time, it is already too late for the adve= rsary to forge an equivalent proof.


This general mechanism also allows validators to distinguish an honest = bitcoin-holding procrastinator from a CRQC in many situations, and so procr= astinators can still authorize spending of their legacy UTXOs even well aft= er Q-day, provided the rescue protocol is deployed before Q-day as a new encumbrance on affected legacy coins.

DropKick In One Paragraph=
DropKick = specifically is a commit/reveal protocol where the commitment H(H(w, = Q), Q)=E2=80=8B is hidden somewhere in a block, such as an OP_RETURN= or inside a taproot tweak. Q=E2=80=8B is a post-quantum publi= c key, and w=E2=80=8B is the witness to a one-way function f=E2=80=8B, such that s =3D f(x)=E2=80=8B is the scr= ipt pubkey (address) encumbering a coin. We can later reveal the witness w=E2=80=8B and a signature from pubkey Q=E2=80=8B t= o authorize a spend, along with an opening proof showing that the co= mmitment was included in a prior block. The verifier checks the commitment = opening is valid and sufficiently old, checks s =3D f(x)=E2=80= =8B, and verifies the PQ-signature from Q=E2=80=8B.

See th= is section for the actual proving/verifying steps of the protocol.

Features

Generality: DropKick generalizes to any effic= ient [1] one-way function based on knowledge asymmetries - things the h= onest user knows which the adversary doesn't. In the context of Bitcoin, th= e one-way function would typically be a computational pipeline that include= s hashing of secret data unknown to a CRQC, such as "BIP32 hardened derivat= ion of an address" or "hashing a public key or script to build an address" = or "taproot key tweaking". DropKick can be instantiated with different one-= way functions to encumber different coins.

Compatibility: DropKick can = be deployed as a soft-fork, as it only tightens spending validation = rules, and does so only on certain UTXOs.

Confiscation: DropKick can be deploy= ed without confiscating any coins, if so desired, by deploying it as= an encumbrance only on UTXOs with decidable knowledge asymmetries l= ike hashed addresses (see this section). If one wishes to maximize th= e number of legacy coins rescued, DropKick can also be deployed on undec= idable knowledge asymmetries like BIP32-CKD. To be clear, P2PK coins ca= nnot be covered by DropKick or indeed by any rescue protocol, as these UTXO= s have no known knowledge asymmetries when a CRQC is in play.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
Blockspace Efficienc= y: DropKick has near zero on-chain impact until reveal time, at which p= oint the commitment opening proofs are included in a reveal transaction<= /i> spending the legacy coins. Opening proofs could be attached in an OP_RE= TURN for backwards compatibility, or for better efficiency the proofs could= be attached in a new transaction witness field which would allow for the 4= x segwit discount to apply. DropKick opening proofs are approximately the s= ame size as SPV or Open= Timestamps proofs (less than a kilobyte) and those proofs can be reused= to rescue multiple related UTXOs, e.g. coins on the same address, or coins= on addresses derived from the same seed.

Performance: DropKick opening proofs = cost very little to verify: a few hash invocations, about as fast to verify= as an SPV proof or lamport signature of the same size, and the cost of ver= ification scales linearly with the size of the proof. If one has txindex=3D1=E2=80=8B enabled, verification is even faster. The only prerequi= site data needed to verify the opening proof is the set of all Bitcoin bloc= k headers. Verifying the revealed witness w=E2=80=8B is= exactly as efficient as evaluating the one-way function f(w)= =E2=80=8B.
=
Ergonomics: Procrastinator do not need to have their o= wn PQ-safe UTXOs available to execute a DropKick rescue: Users can delegate= their commitments to untrusted third party servers called "aggregators" wh= o do have PQ-safe UTXOs. These servers take it upon themselves to ag= gregate the commitments of other users together into a merkle tree, whose r= oot they publish on-chain. Those aggregators can charge a salvage fee for t= heir services if desired, paid in-band from the rescued UTXOs, or up-front = out-of-band. Procrastinators can shop between different aggregators,= and anyone with PQ-safe UTXOs can operate one.

Comparison to Lifeboat

DropKick competes directly with Tadge = Dryja's Lifeboat/Lifejacket proposal (also see this older post), but D= ropKick aims for a different (lower) degree of security in exchange for a s= impler implementation surface, more flexibility, and better efficiency.

The two protocols f= ulfill functionally similar roles, so I will take a moment to compare and c= ontrast DropKick and Lifeboat/Lifejacket.

DropKick includes some novel features which Lifebo= at does not, such as key certification (allowing things like RBF, or= equivocation, by the honest spender), or generalization to arbitrary one-w= ay functions. Such developments could be easily transferred to Lifeboat as = well, so I will mostly ignore these minor differences here.

The fundamental difference betw= een DropKick and Lifeboat is the commitment ordering requirement.

  • Lif= eboat requires procrastinators to (1) procure a PQ-secure UTXO, and (2) upl= oad a ~96-byte commitment in-the-clear in a new transaction, such as in an = OP_RETURN or inscription. Validators must index all such commitments, so th= at they can chronologically order the revealed commitments later. Re= veals reference this index to authorize spending: Only the earliest valid c= ommitment for a given witness is allowed to spend the legacy coin that witn= ess unlocks.
  • DropKick encourages procrastinators to hide commitments i= n merkle trees committed into blocks, such as via a merkle root posted in a= n OP_RETURN, or in a taproot-style key tweak. Reveals use SPV-style proofs = to convince validators that the commitment was included in a past block. Validators therefore do not (and cannot) index all commitments, and so th= ere is no way to confirm any one commitment was earliest.

    • By dropping the commitment ordering req= uirement, DropKick skips the need for a new index database collecting all t= he commitments, and this frees us from putting commitments on chain in-the-= clear. DropKick commitments can be hidden off-chain, but anchored to the ch= ain in merkle trees of arbitrary size, which is the key feature that enable= s the new role of aggregators, and means procrastinators don't need PQ-UTXO= s to publish a commitment and rescue their legacy coins.

    To gain these benefits, DropKick sacrifices some security, by admitt= ing miner censorship attacks where miners can intentionally censor a= reveal transaction to gain a chance to steal the procrastinator's coins. L= ifeboat entirely avoids this class of attacks, whereas DropKick requires a = somewhat loose game-theoretical argument that miners will= converge on choosing not to censor reveals, provided we enforce a l= ong delay (days or weeks) between commitment and reveal steps, and provided= the procrastinator pays a proportional fee to incentivize honest miners. W= e also have to assume no 51% reorg attacks of course, as a malicious hashra= te majority could easily censor any reveal transactions and so steal coins.=

    However, if this security loss is acceptable, Dro= pKick offers a much simpler and less complex engineering surface area, and = supports rescuing users in more diverse situations than LifeBoat can (becau= se PQ UTXOs are mandatory in Lifeboat).

    LifeBoat's= UX advantage over DropKick is that because of the ordering, there is no lo= ng delay or value-proportional fee needed: Users only need to wait a few bl= ocks between commit and reveal stages, and they pay only regu= lar mining fees as usual. DropKick OTOH requires a delay proportional to th= e fraction of the UTXO one is willing to sacrifice to miners. E.g. if we as= sume users are willing to sacrifice 1% of their UTXOs, then we need to enfo= rce a reveal delay period of at least 100 blocks. See here= for a derivation of these parameters.

    Conclusion
    <= br>
    So that's it.

    I'm submitting DropKic= k here as a sketch for consideration, not as a concrete proposal. I am most= interested to know if anyone can think of a better mechanism to avoid mine= r censorship attacks, or if we can at least reduce the strength of the assu= mptions needed for DropKick to resist them.

    regards,
    conduition


    [1]: The one-way function must be <= i>efficient so that verifiers can recompute it to validate reveal trans= actions without DoS risks. For example, BIP32 master key derivation via BIP= 39 is not considered efficient because it uses PBKDF2, whereas BIP32 CKD is= efficient if restricted to a maximum derivation depth.

    --
    You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
    To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/ruufSzDPIml1W5hF-m_IJLeBzuhqey6= CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61FaU_asfj39Ri1QgSXtz7-OekEt6bbTv= o%3D%40proton.me.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/O_i0gm= l6GTRro49f8c8jlCmgwOH5ZMDsJg4zxe-pX6akiGaibaFP7ilCTX90ZDfKORvmd3YlU4UUZWkwI= -NPlvEtY8eVAvCFqO_ckuMG7m8%3D%40proton.me.
-----------------------5fe4b998cc48bdcaa841defdb04e8616-- -----------------------79178a03fa1bc504903d29d235de5f38-- -----------------------fc32395383c12d002d6a553a3144d601 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------fc32395383c12d002d6a553a3144d601-- --------41ab364d885951ced9a363ac671dbe9c56ac04c0e91a0c1d7a85a812eb6f938b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqLghIJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfDH4foqtTipABERemFXUGKMs/MYAKwKWdf2qqh oq6k/xYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABE9gD5AaeQkr/LI02MkTRW 8mlPmYStY2DSaDumSJWIWt761EoA/jDWkhl46aM2EfExltG6zkVEt6A7etne MZJvWUHwDqQG =r8Ew -----END PGP SIGNATURE----- --------41ab364d885951ced9a363ac671dbe9c56ac04c0e91a0c1d7a85a812eb6f938b--