From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 18 Sep 2026 09:53:49 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x7bqN-0002ll-Nq for bitcoindev@gnusha.org; Fri, 18 Sep 2026 09:53:49 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-482966c4f4fsf3134527fac.1 for ; Fri, 18 Sep 2026 09:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1789750421; x=1790355221; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=D/HjMPS6KF3derk165ZcSug93xTa6+Mlvt87g2siHb0=; b=bFuZWJ2bVv7zXCX5FA6UCwBfSmQjGKXiVlcFDcWmFAzcNgKfhYtq2XvGflwZOG/3YC fJCkcxIfjUF1XPXMycQq9xA94lXQMR/C/Ladm2/CTk+ZZ6J72U6y8AW0dDFRRLTpwgQj CnXuGqnr/TcCwzIFtT9O/oL3A9YfkUNxiFxmD3Sb+94f2Uv7og0C1qkLYKjgva6kC4/Q fchSdnnCA6Ikzkd43m+mng1k4NXsXHeBi0RbtKH1jmnp7kH16jYt/rQfxPZz0T44eB7I rXoBYrZTSfJoImLRGZam4xvRNHcPvNijIxr2dYev0yZ/XuPT3w8Y+MVarUZipGIw15Qx w0IQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789750421; x=1790355221; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=D/HjMPS6KF3derk165ZcSug93xTa6+Mlvt87g2siHb0=; b=nfpt985uGekbRZs4es/GzvgkttVI+QRMpPpsJn+bdcJGK54gDLCGz1w3rALX+h3h76 BFShTk9P+ftx2osZMNcpPZ++vHjbOnFweLDqPqJNFLhT8ACplDbbaGsOxiKU1mcZ6pqQ sPUkRasWY5VuAGSSglB1AovPPKfhBK+lffjNp7JgzL/xtYlRhbBshEwQ5TC3WKbjkccv GijeVvfFJr4ZBTmA+TM3oc/5OcoWrL2RYXR00CMgkOME4tnPTfAdsIYVGexXr8+sTdfw Ua3LW0lKuUT8/5URKKBKDWasH5peaaur087A9gZ3LUpH9YaBxg6FGjTUWNGuOsNBM2Un 8yCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789750421; x=1790355221; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=D/HjMPS6KF3derk165ZcSug93xTa6+Mlvt87g2siHb0=; b=KTlPUlwEh346cNMvY+tgxqmTK7Awzk19G+hDK07+DDCtpLRDnVbNqeAu6FFmiDIOMG ZaR+bv0lryLS2P3xlxDtNbf7IzelmVsM4Q5H0GqBuwny9r3639x2UhCMri1Fxnq2N/rg 8lN1VzlbA9QxJtiHxARa+/Pj6fM0qPFIvZLjQOKoXOxvqwxevEuKTebvlNZahYZwAL/3 GIaJP0DhBTYaqbZF0ZeGK8vx+34LJvX27fboVyTF+a6nCEERnny/IUMwY4MLoL8wuXRQ iOuGvAMzm3u4+sxUkHLnX8KA6v+cRtXAlGGYaBCP9EPk7FvWJVMo93kiBGITnoGcxC8M /yOg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvByDxkIf/OuIUVc0lMcKCTPENTT1ekkcy3vPYLxwQ6+SM4KgiwN41A22afGtfogPYOLQrm9q6d+WccNa@gnusha.org X-Gm-Message-State: AFuF++npvJP6rSh4IVxuX+tIu++gZTGoq68opZ2oxf52c8x/7hvAGjbA emasgNvaIcwC+vQfNXRLfsMDVbBi/a0WC4ArAlS6elHwEqcVEhnmqYKo X-Received: by 2002:a05:6870:51c6:b0:470:e96b:43e9 with SMTP id 586e51a60fabf-486df93ab3fmr2865129fac.21.1789750421362; Fri, 18 Sep 2026 09:53:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLde4iw2RUwfjis0+BvM+Dw1/gGtJk/+Aai9/Rz2NENBadg==" Received: by 2002:a05:6870:2d2:b0:478:683d:a9dd with SMTP id 586e51a60fabf-485749f0faels3732820fac.1.-pod-prod-05-us; Fri, 18 Sep 2026 09:53:32 -0700 (PDT) X-Received: by 2002:a05:6808:4f47:b0:4a3:fefb:899b with SMTP id 5614622812f47-4ccf5376645mr3928816b6e.7.1789750412303; Fri, 18 Sep 2026 09:53:32 -0700 (PDT) Received: by 2002:a05:690c:e190:10b0:84a:c43b:38df with SMTP id 00721157ae682-8944af103e0ms7b3; Fri, 18 Sep 2026 09:51:16 -0700 (PDT) X-Received: by 2002:a05:690c:6d81:b0:894:b231:79bc with SMTP id 00721157ae682-897374104f6mr10835557b3.59.1789750275698; Fri, 18 Sep 2026 09:51:15 -0700 (PDT) Date: Fri, 18 Sep 2026 09:51:15 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <0521d915-8613-47ea-ad44-6eaeaa5a6ed0n@googlegroups.com> In-Reply-To: References: 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?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_131690_185385045.1789750275397" X-Original-Sender: antoine.riard@gmail.com 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: -0.5 (/) ------=_Part_131690_185385045.1789750275397 Content-Type: multipart/alternative; boundary="----=_Part_131691_630680991.1789750275397" ------=_Part_131691_630680991.1789750275397 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Conduition, Thanks for your Dropkick proposal. Found the time to have a cursory read of your ideas, it's all interesting. I think the problematization of the issue in plain terms of knowledge asymmetry sounds an interesting analytical foundations to evaluate rescue protocols. With my earlier idea of a certificate-based rescue protocol, the intuition is very similar with what I'm calling a "proof of knowledge anteriority". With the notable difference than rather to rely on a derivation secret like parent BIP32 xprivs one generate a new secret (e.g a random preimage) counter-signed by a ECC key. It's true the security of this scheme relies on a "decaying assumption" as it's invalidated by the occurence of the Q-day, though on the other hand it's an "open set" of secret asymmetry, whatever the address type evaluated. Now, digging a bit about your proposal, and how it's sharing some limitation with Lifeboat. On the delay, it's not clear if you're proposing the delay to be "gentleman's agreement" enforced by the aggregator ? If yes it doesn't sound very robust in face of an adversarial one, and note the "toxicity" of the information, i.e the commitment tx, you cannot delegate to a N number of aggregator, as a single enough not complying is enough. Generally, I'm thinking be it Lifeboat of Dropkick, they're both vulnerable to some class of time-dilation attack [0], where a miner and PQ adversary can go to forge a hashrate-good chain, sybil the target victim and trigger her or him to reveal her reveal tx, too earlier from the "real" chain time. Once the victim is sybilled, one has a selfish mining advantage, and this is realistic to consider if the rescued coins are of a significant amount. As you're observing the aggregator is very at risk to be the object of a distrubuted denial-of-service. While micro-payment can be a solution, there is always the risk of proof inflation cost, where a third-party inflate the asked rate for micro-payment beyond what lowest economic users can afford for the proof, leveraging a asymmetrical factor in her or his benefice as it's a common ressource. A classic when you have to evaluate lightning dos attack. This might be also delicate to have secure opening proof, as the commitment transaction witness txid could be altered before it's included in the chain (e.g one can go to modify the witness stack), though it sounds a user could re-compute an opening proof. There is the risk of "binding malleability" if the opening proof can be malleated to point to another commitment tx at spending or be plainly invalidated while the carrying transaction would stay valid (some "half-state" issue). Anyway, those are the few constraints and weaknesses that I can think of while doing a brief read of your DropKick proposal. To be clear,=20 I do think there are trade-offs affecting any rescue protocol, and there are not specific to DropKick or Lifeboat. Overall, it's a very interesting formalization of the issues. Best, Antoine OTS: cc1d5b4a3d0ed137fc3778ff2d72c35814d9aec8d2b8e74279740d6e726901e0 [0] https://arxiv.org/abs/2006.01418 Le Monday, August 24, 2026 =C3=A0 12:58:01=E2=80=AFAM UTC+1, conduition a = =C3=A9crit : > Hi Alex, > > We need to have an already functioning PQC solution for Bitcoin itself,= =20 > deployed, before any of commit/reveal can help, right? > > > Yes. Two reasons: > > First, without on-chain PQC, making commitments would be impossible to do= =20 > safely unless commitment are aggregated directly by miners into the=20 > coinbase transaction. > > Second, without on-chain PQ-secure addresses, where would one even rescue= =20 > coins *to*? Commit/reveal protocols are meant as a tool saving coins in= =20 > an emergency, 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 =20 > wrote: > > Am I correct in understanding that commit/reveal always depends on someon= e=20 > else already having a valid PQC UTXO to spend? > > So in other words, this can never be a solution for a (procrastinating=20 > Bitcoin system), only a solution for (procrastinating Bitcoin users).=20 > > We need to have an already functioning PQC solution for Bitcoin itself,= =20 > deployed, before any of commit/reveal can help, right? > > Den tors 20 aug. 2026 23:56'conduition' via Bitcoin Development Mailing= =20 > List skrev: > >> Dearest friends, colleagues, and lurkers, >> >> I would like to present for your consideration a new commit/reveal rescu= e=20 >> protocol to save the coins of quantum procrastinators - those who take n= o=20 >> action to move their coins to PQC-enabled wallets by Q-Day. >> >> https://conduition.io/bitcoin/dropkick/ >> >> The term "DropKick" is self-descriptive of its usage: *Drop* a hidden=20 >> commitment somewhere on the blockchain, and reveal it later with an=20 >> SPV-style proof to *Kick* (spend) your legacy coins forward to a new=20 >> PQ-secure wallet. >> >> Background >> >> As with any post-quantum commit/reveal protocol, DropKick uses the=20 >> blockchain as a trustless timestamping service to prove than an honest u= ser=20 >> had earlier chronological knowledge of some secret *witness* to a=20 >> quantum-hard* one-way function*. The honest user hides a *commitment* in= =20 >> a block, waits for confirmations, and later *reveals* her commitment to= =20 >> certify she knew the secret witness long before an adversary (like a=20 >> quantum computer) could have done so. Assuming this witness was indeed k= ept=20 >> secret prior to reveal time, it is already too late for the adversary to= =20 >> forge an equivalent proof. >> >> >> This general mechanism also allows validators to distinguish an honest= =20 >> bitcoin-holding procrastinator from a CRQC in many situations, and so=20 >> procrastinators can still authorize spending of their legacy UTXOs even= =20 >> well after Q-day, provided the rescue protocol is deployed *before*=20 >> 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,=20 >> Q), Q)=E2=80=8B is hidden somewhere in a block, such as an OP_RETURN or = inside a=20 >> taproot tweak. Q=E2=80=8B is a post-quantum public key, and w=E2=80=8B i= s the witness to=20 >> a one-way function f=E2=80=8B, such that s =3D f(x)=E2=80=8B is the scri= pt pubkey=20 >> (address) encumbering a coin. We can later reveal the witness w=E2=80=8B= and a=20 >> signature from pubkey Q=E2=80=8B to authorize a spend, along with an *op= ening=20 >> proof* showing that the commitment was included in a prior block. The=20 >> verifier checks the commitment opening is valid and sufficiently old,=20 >> checks s =3D f(x)=E2=80=8B, and verifies the PQ-signature from Q=E2=80= =8B. >> >> See this section for the actual proving/verifying steps of the protocol.= =20 >> >> >> Features >> >> *Generality:* DropKick generalizes to any *efficient *[1] one-way=20 >> function based on knowledge asymmetries - things the honest user knows= =20 >> which the adversary doesn't. In the context of Bitcoin, the one-way=20 >> function would typically be a computational pipeline that includes hashi= ng=20 >> of secret data unknown to a CRQC, such as "BIP32 hardened derivation of = an=20 >> address" or "hashing a public key or script to build an address" or=20 >> "taproot key tweaking". DropKick can be instantiated with different one-= way=20 >> functions to encumber different coins. >> >> *Compatibility:* DropKick can be deployed as a soft-fork, as it only=20 >> *tightens* spending validation rules, and does so only on certain UTXOs. >> >> *Confiscation:* DropKick can be deployed *without* confiscating any=20 >> coins, if so desired, by deploying it as an encumbrance only on UTXOs wi= th=20 >> *decidable* knowledge asymmetries like hashed addresses (see this sectio= n=20 >> ). If one= =20 >> wishes to maximize the number of legacy coins rescued, DropKick can also= be=20 >> deployed on *undecidable* knowledge asymmetries like BIP32-CKD. To be=20 >> clear, P2PK coins cannot be covered by DropKick or indeed by any rescue= =20 >> protocol, as these UTXOs have no known knowledge asymmetries when a CRQC= is=20 >> in play. >> >> *Blockspace Efficiency:* DropKick has near zero on-chain impact until=20 >> reveal time, at which point the commitment opening proofs are included i= n a *reveal=20 >> transaction* spending the legacy coins. Opening proofs could be attached= =20 >> in an OP_RETURN for backwards compatibility, or for better efficiency th= e=20 >> proofs could be attached in a new transaction witness field which would= =20 >> allow for the 4x segwit discount to apply. DropKick opening proofs are= =20 >> approximately the same size as SPV=20 >> =20 >> or OpenTimestamps proofs (less than a=20 >> kilobyte) and those proofs can be reused to rescue multiple related UTXO= s,=20 >> e.g. coins on the same address, or coins on addresses derived from the s= ame=20 >> seed. >> >> *Performance:* DropKick opening proofs cost very little to verify: a few= =20 >> hash invocations, about as fast to verify as an SPV proof or lamport=20 >> signature of the same size, and the cost of verification scales linearly= =20 >> with the size of the proof. If one has txindex=3D1=E2=80=8B enabled, ver= ification=20 >> is even faster. The only prerequisite data needed to verify the opening= =20 >> proof is the set of all Bitcoin block headers. Verifying the revealed=20 >> witness w=E2=80=8B is exactly as efficient as evaluating the one-way fun= ction=20 >> f(w)=E2=80=8B. >> >> *Ergonomics: *Procrastinator *do not* need to have their own PQ-safe=20 >> UTXOs available to execute a DropKick rescue: Users can delegate their= =20 >> commitments to untrusted third party servers called "aggregators" who=20 >> *do* have PQ-safe UTXOs. These servers take it upon themselves to=20 >> aggregate the commitments of other users together into a merkle tree, wh= ose=20 >> root they publish on-chain. Those aggregators can charge a salvage fee f= or=20 >> their services if desired, paid in-band from the rescued UTXOs, or up-fr= ont=20 >> out-of-band. Procrastinators can shop between different aggregators, and= =20 >> anyone with PQ-safe UTXOs can operate one. >> >> Comparison to Lifeboat >> >> DropKick competes directly with Tadge Dryja's Lifeboat/Lifejacket=20 >> proposal (also see this= =20 >> older post ), but= =20 >> DropKick aims for a different (lower) degree of security in exchange for= a=20 >> simpler implementation surface, more flexibility, and better efficiency. >> >> The two protocols fulfill functionally similar roles, so I will take a= =20 >> moment to compare and contrast DropKick and Lifeboat/Lifejacket. >> >> DropKick includes some novel features which Lifeboat does not, such as *= key=20 >> certification *(allowing things like RBF, or equivocation, by the honest= =20 >> spender), or generalization to arbitrary one-way functions. Such=20 >> developments could be easily transferred to Lifeboat as well, so I will= =20 >> mostly ignore these minor differences here.=20 >> >> The fundamental difference between DropKick and Lifeboat is the=20 >> commitment ordering requirement. >> >> >> - Lifeboat requires procrastinators to (1) procure a PQ-secure UTXO,= =20 >> and (2) upload a ~96-byte commitment in-the-clear in a new transactio= n,=20 >> such as in an OP_RETURN or inscription. Validators must index all suc= h=20 >> commitments, so that they can *chronologically order* the revealed=20 >> commitments later. Reveals reference this index to authorize spending= : Only=20 >> the earliest valid commitment for a given witness is allowed to spend= =20 >> the legacy coin that witness unlocks. >> - DropKick encourages procrastinators to *hide* commitments in merkle= =20 >> trees committed into blocks, such as via a merkle root posted in an= =20 >> OP_RETURN, or in a taproot-style key tweak. Reveals use SPV-style pro= ofs to=20 >> convince validators that the commitment was included in a past block.= *Validators=20 >> therefore do not (and cannot) index all commitments, and so there is = no way=20 >> to confirm any one commitment was earliest*. >> >> >> By dropping the commitment ordering requirement, DropKick skips the need= =20 >> for a new index database collecting all the commitments, and this frees = us=20 >> from putting commitments on chain in-the-clear. DropKick commitments can= be=20 >> hidden off-chain, but anchored to the chain in merkle trees of arbitrary= =20 >> size, which is the key feature that enables the new role of aggregators,= =20 >> and means procrastinators don't need PQ-UTXOs to publish a commitment an= d=20 >> rescue their legacy coins. >> >> To gain these benefits, DropKick sacrifices some security, by admitting = miner=20 >> censorship attacks = =20 >> where miners can intentionally censor a reveal transaction to gain a cha= nce=20 >> to steal the procrastinator's coins. Lifeboat entirely avoids this class= of=20 >> attacks, whereas DropKick requires a somewhat loose game-theoretical=20 >> argument = =20 >> that miners will converge on choosing *not* to censor reveals, provided= =20 >> we enforce a long delay (days or weeks) between commitment and reveal=20 >> steps, and provided the procrastinator pays a proportional fee to=20 >> incentivize honest miners. We also have to assume no 51% reorg attacks o= f=20 >> course, as a malicious hashrate majority could easily censor any reveal= =20 >> transactions and so steal coins. >> >> However, if this security loss is acceptable, DropKick offers a much=20 >> simpler and less complex engineering surface area, and supports rescuing= =20 >> users in more diverse situations than LifeBoat can (because PQ UTXOs are= =20 >> mandatory in Lifeboat). >> >> LifeBoat's UX advantage over DropKick is that because of the ordering,= =20 >> there is no long delay or value-proportional fee needed: Users only need= to=20 >> wait a few blocks between *commit* and *reveal* stages, and they pay=20 >> only regular mining fees as usual. DropKick OTOH requires a delay=20 >> proportional to the fraction of the UTXO one is willing to sacrifice to= =20 >> miners. E.g. if we assume users are willing to sacrifice 1% of their UTX= Os,=20 >> then we need to enforce a reveal delay period of at least 100 blocks. Se= e=20 >> here for a derivation of these parameters=20 >> .=20 >> >> Conclusion >> >> So that's it. >> >> I'm submitting DropKick here as a sketch for consideration, not as a=20 >> concrete proposal. I am most interested to know if anyone can think of a= =20 >> better mechanism to avoid miner censorship attacks, or if we can at leas= t=20 >> reduce the strength of the assumptions needed for DropKick to resist the= m. >> >> regards, >> conduition >> >> >> [1]: The one-way function must be *efficient* so that verifiers can=20 >> recompute it to validate reveal transactions without DoS risks. For=20 >> example, BIP32 master key derivation via BIP39 is not considered efficie= nt=20 >> because it uses PBKDF2, whereas BIP32 CKD is efficient if restricted to = a=20 >> maximum derivation depth. >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/ruufSzDPIml1W5hF-m_IJLeBzuh= qey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61FaU_asfj39Ri1QgSXtz7-OekEt6= bbTvo%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/= 0521d915-8613-47ea-ad44-6eaeaa5a6ed0n%40googlegroups.com. ------=_Part_131691_630680991.1789750275397 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Conduition,

Thanks for your Dropkick proposal.

= Found the time to have a cursory read of your ideas, it's all
interest= ing. I think the problematization of the issue in plain
terms of knowl= edge asymmetry sounds an interesting analytical
foundations to evaluat= e rescue protocols.

With my earlier idea of a certificate-based = rescue protocol, the
intuition is very similar with what I'm calling a= "proof of
knowledge anteriority". =C2=A0With the notable difference t= han
rather to rely on a derivation secret like parent BIP32 xprivs
one generate a new secret (e.g a random preimage) counter-signed
by = a ECC key. It's true the security of this scheme relies on
a "decaying= assumption" as it's invalidated by the occurence of
the Q-day, though= on the other hand it's an "open set" of secret
asymmetry, whatever th= e address type evaluated.

Now, digging a bit about your proposal= , and how it's sharing some
limitation with Lifeboat. On the delay, it= 's not clear if you're
proposing the delay to be "gentleman's agreemen= t" enforced by the
aggregator ? If yes it doesn't sound very robust in= face of an
adversarial one, and note the "toxicity" of the informatio= n, i.e
the commitment tx, you =C2=A0cannot delegate to a N number of a= ggregator,
as a single enough not complying is enough.

Gene= rally, I'm thinking be it Lifeboat of Dropkick, they're both
vulnerabl= e to some class of time-dilation attack [0], where a miner
and PQ adve= rsary can go to forge a hashrate-good chain, =C2=A0sybil the
target vi= ctim and trigger her or him to reveal her reveal tx, too
earlier from = the "real" chain time. Once the victim is sybilled,
one has a selfish = mining advantage, and this is realistic to consider
if the rescued coi= ns are of a significant amount.

As you're observing the aggregat= or is very at risk to be the object
of a distrubuted denial-of-service= . While micro-payment can be a
solution, there is always the risk of p= roof inflation cost, where
a third-party inflate the asked rate for mi= cro-payment beyond what
lowest economic users can afford for the proof= , leveraging a asymmetrical
factor in her or his benefice as it's a co= mmon ressource. A classic
when you have to evaluate lightning dos atta= ck.

This might be also delicate to have secure opening proof, as= the
commitment transaction witness txid could be altered before it's<= br />included in the chain (e.g one can go to modify the witness stack),though it sounds a user could re-compute an opening proof. There is
the risk of "binding malleability" if the opening proof can be malleatedto point to another commitment tx at spending or be plainly invalidated=
while the carrying transaction would stay valid (some "half-state" is= sue).

Anyway, those are the few constraints and weaknesses that = I can think
of while doing a brief read of your DropKick proposal. To = be clear,
I do think there are trade-offs affecting any rescue protoc= ol, and there
are not specific to DropKick or Lifeboat.

Ove= rall, it's a very interesting formalization of the issues.

Best,=
Antoine
OTS: cc1d5b4a3d0ed137fc3778ff2d72c35814d9aec8d2b8e742797= 40d6e726901e0

[0] https://arxiv.org/abs/2006.01418

Le Monday, = August 24, 2026 =C3=A0 12:58:01=E2=80=AFAM UTC+1, conduition a =C3=A9crit= =C2=A0:
Hi Alex,

We need to have an already funct= ioning PQC solution for Bitcoin itself, deployed, before any of commit/reve= al can help, right?

Yes. Tw= o reasons:

First, without on-chain PQC, = making commitments would be impossible to do safely unless commitment are a= ggregated directly by miners into the coinbase transaction.

Second, without on-chain PQ-secure addresses, where wou= ld one even rescue coins to? Commit/reveal protocols are meant as a = tool saving coins in an emergency, not for everyday spending.
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
P= Q signature schemes are therefore needed as a prerequisite.

reg= ards,
conduition
On Saturday, August 22nd, 2026 at 1:46 PM, Alex <alexh...@gmail.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 Development Mailin= g List <b= itco...@googlegroups.com> skrev:
Dearest fri= ends, colleagues, and lurkers,

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

https://conduition.io/bitcoin/dropkick/

The term "DropK= ick" is self-descriptive of its usage: Drop a hidden commitment= somewhere on the blockchain, and reveal it later with an SPV-style proof t= o Kick (spend) your legacy coins forward to a new PQ-secure wallet.<= /div>

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">Background

As with any post-quantum commit/reveal = protocol, DropKick uses the blockchain as a trustless timestamping service = to prove than an honest user had earlier chronological knowledge of some se= cret witness to a quantum-hard one-way function. The honest u= ser hides a commitment in a block, waits for confirmations, and late= r reveals her commitment to certify she knew the secret witness long= before an adversary (like a quantum computer) could have done so. Assuming= this witness was indeed kept secret prior to reveal time, it is already to= o late for the adversary to forge an equivalent proof.


This general mechani= sm also allows validators to distinguish an honest bitcoin-holding procrast= inator from a CRQC in many situations, and so procrastinators can still aut= horize spending of their legacy UTXOs even well after Q-day, provided the r= escue protocol is deployed before Q-day as a new encumb= rance on affected legacy coins.

DropKick In One Paragraph

DropKick specifically is a commi= t/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 tw= eak. Q=E2=80=8B is a post-quantum public key, and w=E2=80=8B is the witness to a one-way function f=E2=80=8B, s= uch that s =3D f(x)=E2=80=8B is the script pubkey (address) en= cumbering a coin. We can later reveal the witness w=E2=80=8B a= nd a signature from pubkey Q=E2=80=8B to authorize a spend, al= ong with an opening proof showing that the commitment was included i= n a prior block. The verifier checks the commitment opening is valid and su= fficiently old, checks s =3D f(x)=E2=80=8B, and verifies the P= Q-signature from Q=E2=80=8B.


Features

Generality: Dro= pKick generalizes to any efficient [1] one-way function based on kno= wledge asymmetries - things the honest user knows which the adversary doesn= 't. In the context of Bitcoin, the one-way function would typically be = a computational pipeline that includes hashing of secret data unknown to a = CRQC, such as "BIP32 hardened derivation of an address" or "= hashing a public key or script to build an address" or "taproot k= ey tweaking". DropKick can be instantiated with different one-way func= tions to encumber different coins.

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

Confiscation: DropKick can be deployed wi= thout confiscating any coins, if so desired, by deploying it as an encu= mbrance only on UTXOs with decidable knowledge asymmetries like hash= ed addresses (see this section). If one wishes 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 cov= ered by DropKick or indeed by any rescue protocol, as these UTXOs have no k= nown knowledge asymmetries when a CRQC is in play.

Blockspace Efficiency: Dr= opKick has near zero on-chain impact until reveal time, at which point the = commitment opening proofs are included in a reveal transaction spend= ing the legacy coins. Opening proofs could be attached in an OP_RETURN for = backwards compatibility, or for better efficiency the proofs could be attac= hed in a new transaction witness field which would allow for the 4x segwit = discount to apply. DropKick opening proofs are approximately 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.

Performan= ce: DropKick opening proofs cost very little to verify: a few hash invo= cations, about as fast to verify as an SPV proof or lamport signature of th= e same size, and the cost of verification scales linearly with the size of = the proof. If one has txindex=3D1=E2=80=8B enabled, verification is even = faster. The only prerequisite data needed to verify the opening proo= f is the set of all Bitcoin block headers. Verifying the revealed wi= tness 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 own PQ-safe UTXOs available to execute a Drop= Kick rescue: Users can delegate their commitments to untrusted third party = servers called "aggregators" who do have PQ-safe UTXOs. Th= ese servers take it upon themselves to aggregate the commitments of other u= sers together into a merkle tree, whose root they publish on-chain. Those a= ggregators can charge a salvage fee for their services if desired, paid in-= band from the rescued UTXOs, or up-front out-of-band. Procrastinator= s can shop between different aggregators, and anyone with PQ-safe UTXOs can= operate one.

Comparison to Lifeboat

DropKick comp= etes directly with Tadge Dryja's Lifeboat/Lifejacket proposal (also se= e this older pos= t), but DropKick aims for a different (lower) degree of security in exc= hange for a simpler implementation surface, more flexibility, and better e= fficiency.
=
The tw= o protocols fulfill functionally similar roles, so I will take a moment to = compare and contrast DropKick and Lifeboat/Lifejacket.

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 ar= bitrary one-way functions. Such developments could be easily transferred to= Lifeboat as well, so I will mostly ignore these minor differences here.

The fundamental di= fference between DropKick and Lifeboat is the commitment ordering requireme= nt.

  • Lifeboat requires procrastinators to (1) procure a PQ-secure UTXO= , and (2) upload a ~96-byte commitment in-the-clear in a new transaction, s= uch as in an OP_RETURN or inscription. Validators must index all such commi= tments, so that they can chronologically order the revealed commitme= nts later. Reveals reference this index to authorize spending: Only the ear= liest valid commitment for a given witness is allowed to spend the legacy c= oin that witness unlocks.
  • DropKick encourages procrastinators to hide = commitments in merkle trees committed into blocks, such as via a merkle roo= t posted in an OP_RETURN, or in a taproot-style key tweak. Reveals use SPV-= style proofs to convince validators that the commitment was included in a p= ast block. Validators therefore do not (and cannot) index all commitmen= ts, and so there is no way to confirm any one commitment was earliest.<= /span>

By dropping the commitment= ordering requirement, DropKick skips the need for a new index database col= lecting all the commitments, and this frees us from putting commitments on = chain in-the-clear. DropKick commitments can be hidden off-chain, but ancho= red to the chain in merkle trees of arbitrary size, which is the key featur= e that enables the new role of aggregators, and means procrastinators don&#= 39;t need PQ-UTXOs to publish a commitment and rescue their legacy coins.

To gain these benefits, DropKick sacrifices some se= curity, by admitting miner censorship attacks where miners can intentionally censor = a reveal transaction to gain a chance to steal the procrastinator's coi= ns. Lifeboat entirely avoids this class of attacks, whereas DropKick requir= es a somewhat loose game-theoretical argument that miners will = converge on choosing not to censor reveals, provided we enforce a lo= ng delay (days or weeks) between commitment and reveal steps, and provided = the procrastinator pays a proportional fee to incentivize honest miners. We= also have to assume no 51% reorg attacks of course, as a malicious hashrat= e majority could easily censor any reveal transactions and so steal coins.<= /div>

However, if this security loss is acceptable, Drop= Kick offers a much simpler and less complex engineering surface area, and s= upports rescuing users in more diverse situations than LifeBoat can (becaus= e PQ UTXOs are mandatory in Lifeboat).

LifeBoat= 9;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 r= egular mining fees as usual. DropKick OTOH requires a delay proportional to= the fraction of the UTXO one is willing to sacrifice to miners. E.g. if we= assume users are willing to sacrifice 1% of their UTXOs, then we need to e= nforce a reveal delay period of at least 100 blocks. See here for a deriva= tion of these parameters.

Conclusion

So that's it.

I'm submitting DropKick her= e as a sketch for consideration, not as a concrete proposal. I am most inte= rested to know if anyone can think of a better mechanism to avoid miner cen= sorship attacks, or if we can at least reduce the strength of the assumptio= ns needed for DropKick to resist them.

regards,
conduition


[1]: The one-way function must be e= fficient so that verifiers can recompute it to validate reveal transact= ions without DoS risks. For example, BIP32 master key derivation via BIP39 = is not considered efficient because it uses PBKDF2, whereas BIP32 CKD is ef= ficient if restricted to a maximum derivation depth.

--
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 bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ruufS= zDPIml1W5hF-m_IJLeBzuhqey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61FaU_a= sfj39Ri1QgSXtz7-OekEt6bbTvo%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/bitcoind= ev/0521d915-8613-47ea-ad44-6eaeaa5a6ed0n%40googlegroups.com.
------=_Part_131691_630680991.1789750275397-- ------=_Part_131690_185385045.1789750275397--