From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 04 Oct 2026 07:50:51 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xDNY8-0008Tg-J3 for bitcoindev@gnusha.org; Sun, 04 Oct 2026 07:50:51 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-451d80641efsf993726fac.2 for ; Sun, 04 Oct 2026 07:50:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1791125439; cv=pass; d=google.com; s=arc-20260327; b=grZbMqTTnO5Fn1tp4OxuXKCnHZ2iJbGOyyyMAQR13jkUP10ppB7eLLEy3djzl+6MYg r+6KwY/4Lfnu96S0dk85r8tFwuUJF2s/eamO7zZ1EAnfQplU9crUEzwWggnyauD5owJP LjohEYHKUYZeaaKNb5T/UWTKJ07SGeDku387u91ZeK0CEMReQtCsu4hpgbDvzAAE27i2 wvdljdvl28hFtCGpDTXayL4toCExVjYdcanlfMh0Dxmwu56YV8uLUxwXPXoQ9xZ+q7fT SXuXoJK2vJxszU5h1i57fIecChdBop096Mada2mJKXbTNFAK1SuYV8oqIvP+MdyL7q1C t9Ag== 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=P2y/0m8wEIX5rulv/cZ+W1ideA9WeHiFSpLvrmk1wTQ=; fh=uk5VzNkWXtc+cuvUFB0IOoGUJALgOawD/mHy2ftg8Tc=; b=ljXZ/+f3q0zpR/xdDgFxRyIsus+vrruH3vEm4NU6PRBjkCtqyhoHCWCQS/vIU7iwrm vcDyHegmjvV8JLy6xSkDsAQvY787NrFtO1o8w7QyEvrWPWgUWubscQuXzlqACeibTxYX C6r2fDbgWipmBIQ1dVM4D3j8t7rASJLFnHIijcGVArc3Es2cuHmLKPzrtkMdiVfvV1Tz qGKMWwRTNU+DFug+dBq2z1aDhQgeaYEiVQZmcVE7wve91lLO9DaZIoroRJ4O4A0bxjG/ vESFg9n5LjA+NYUy1w2xwGv5T94scYco4wsUY1l6oeIb6Q/afBqgfMP+NAFBEaGSkqRP toaA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail2 header.b=O23l7JVj; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 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=1791125439; x=1791730239; 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=P2y/0m8wEIX5rulv/cZ+W1ideA9WeHiFSpLvrmk1wTQ=; b=W6Q4IzL+hznx82aaVANHIBDmX4WOHNYmLkHDR7a/LtbGKV0mf40RQubcPi8QI8hSxm ZgMpzJMxgNCNECkIUD/V0HCe5B95t1HQkH81nNIYIRdreHa2lJdcgalEWrpAjddULOxz Jqgi21K9/RjZZlCEzh8SG8vuyH61a1lR4TmiaVCl4S8U/ujoCS2z6PII3vsKC1APiajJ RWOmsTbOodyH4BkblVrV+pBUcAqX0tA1SnMbhCT4EpkH03s0dmjBoKDey2/Lizo0mpR+ 2hst0XuFSvzuzozaeg9ezIpoecVF/PuMa1EqfcCMxc6iYflzpdCIwiwkok9rdXLClZ8/ 1rcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791125439; x=1791730239; 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=P2y/0m8wEIX5rulv/cZ+W1ideA9WeHiFSpLvrmk1wTQ=; b=LRt3jo2c4Fn4WJk7vOfhtUdCWDfQOGDCd6BdgMHLjLWAa7n1WyY8Mkvu8AtPiuD/g5 ThYR8j2JjmEdLNuXI+eNcNcnN8mtE/qlJyrfvKgZupvvaLd6DYfF49QL+wIHzLGFEgjs zFvAfJ2XGWc6dti+xazGLvz8sU4ixaHD1OFPdhIXSccd0rsRzTiRVBjQ53pIk+B1ucj8 l33s1vj28iHi+sv/DZcZe4lnfY0FmnkV6OszVHT22xT+D0U5DOZdZhwkz8H0TuPsaH2a F8hv/bhh77qf8xLS9nXIduCEapN5mDQ38TtlscTLv4y0Qt9wxhCpr54DWGGKsRmEUlR8 NWKw== X-Forwarded-Encrypted: i=2; AKwUvBwXGp6bJUQ7gaK4PN0bEE7vjKYzABTyvNq3eAxeUknQDra6Lg0iO/Rhjh/o90eubABat8VtN1trP3TK@gnusha.org X-Gm-Message-State: AFuF++mZVdXbSpM3nDGzjwipgjX1WHR9FX/wYffVojnXpkBYuN9fhxMh knsYE2aq/ITMi2wP2ae2ZRNZc6p8TKN9TG6lUVQAZTdJrpFMZKK59+pF X-Received: by 2002:a05:6870:b48f:b0:49d:c502:5e2c with SMTP id 586e51a60fabf-49e15ee8a14mr6160234fac.48.1791125439396; Sun, 04 Oct 2026 07:50:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfYrQIHP1+e4hc5KLrIqb1Fkoc79fyrBpR7Wih1boaReA==" Received: by 2002:a05:6871:8a84:b0:49d:f7b1:71ff with SMTP id 586e51a60fabf-49e190672d1ls1798154fac.1.-pod-prod-03-us; Sun, 04 Oct 2026 07:50:32 -0700 (PDT) X-Received: by 2002:a05:6808:1701:b0:4cc:c2aa:6c6a with SMTP id 5614622812f47-4f529d2125emr6437451b6e.19.1791125432317; Sun, 04 Oct 2026 07:50:32 -0700 (PDT) Received: by 2002:a05:6504:9947:10b0:316:ae02:42fe with SMTP id a1c4a302cd1d6-316d3f5ed2fmsc7a; Sat, 3 Oct 2026 17:52:38 -0700 (PDT) X-Received: by 2002:a2e:bc81:0:b0:3a6:53b7:65f with SMTP id 38308e7fff4ca-3a8877e40a1mr17825901fa.24.1791075156910; Sat, 03 Oct 2026 17:52:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791075156; cv=none; d=google.com; s=arc-20260327; b=bKV7C2B9OjTeptppAYUcQ6CeJ8zdlH3rX+vuD557T/WCrLZXTErVOrOv/4RLf+H1WC QOwJVkfn8bTowRTmsNxubgryYHxaDeWrpldz4egt25tHTP17r4KWRPKWiNzCiPGo0/kX AXDQ4x0HBqJPTEytvRCA3Tv4a7d2eEvUD0o/25hFbwVVE1mpU4a8TYIQbqOhAp94CX5q ctLB/5yy511iWjCi2FVGFgSmxQ5qEHbFgUvyhu5H2q1Y9IQjoLRuUu4NNVUKz9iK98ch r3LV/0dITVqr8GBplBH2Nb2BSKnY2FSKczqWfppRSmfKpGjy/FhJsK1gWXdr+ApNILVT H78w== 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=JrfPshvUDF6kHXtFRZDfvS0Cy74TGnWrObIDTNzurqo=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=mjO5FApYvQSU6a1V7gguxylVoz6DmK1CwZe6szx/FEn3a/3NSyItGE1qwoOLgEcOvX tr2BnzMOjnPrqOyQJ1r6g/jYsi72UQBrSViqXYEUs73i0lWK+31DTL04+XsLUJFf86k1 FhJmyhwBAXh3u1r1heHrao0Sx/TBDRAUPrt+S/6s7MY7vDVflH19Pr/+mtZe5D5QgMnR POcga+0FRXw5Ch+WkgAHthn7YEvCYGoT7amxZmu2Snr3nsrFL89NAZ+3gAWLBeB64Iny Ru203ss2bgHPKbmPmpBjEI6O4niZU4pqh3c9/UkbKsqV267HG+BVOzawVBjqpdgzu/r8 XSAQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail2 header.b=O23l7JVj; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch. [79.135.106.99]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3a87e348be0si1207231fa.9.2026.10.03.17.52.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Oct 2026 17:52:36 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) client-ip=79.135.106.99; Date: Sun, 04 Oct 2026 00:52:29 +0000 To: Antoine Riard From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List 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: <0521d915-8613-47ea-ad44-6eaeaa5a6ed0n@googlegroups.com> References: <0521d915-8613-47ea-ad44-6eaeaa5a6ed0n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 5034df36c819d7a3a6c3cd7fc36d6c281f05e3fa MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------e26a4d97fabe03ce0445e3a4e5fa5fd2cfadda62aa1252008c0d0b4beea8a448"; 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=protonmail2 header.b=O23l7JVj; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 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) --------e26a4d97fabe03ce0445e3a4e5fa5fd2cfadda62aa1252008c0d0b4beea8a448 Content-Type: multipart/mixed;boundary=---------------------d82cfe6b1a76e53b3d8d9010fdd0c125 -----------------------d82cfe6b1a76e53b3d8d9010fdd0c125 Content-Type: multipart/alternative;boundary=---------------------06d2620be9da971534d20a96a69ad9da -----------------------06d2620be9da971534d20a96a69ad9da Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Antoine, and thank you for spending the time to read into DropKick :) > On the delay, it's not clear if you'reproposing the delay to be "gentlema= n'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. The reveal delay (the `d`=C2=A0parameter) is enforced by consensus, during = the reveal stage. The exact check is described in step 2 of this section: > Authenticate the commitment opening `pi`, asserting `H(H(w, Q), Q)` was c= ommitted at least `d` blocks earlier. The reveal delay=C2=A0`d` must unfortunately be fixed at deployment time, a= nd applies globally to every dropkick spend. So that, and the closely relat= ed minimum fee rate=C2=A0=CE=B4 are very "bikeshed-able". One welcome area = for suggestions would be if anyone can find a way to allow users to pick th= eir own block delay parameters to better suit their uses cases. Unfortunate= ly Tadge and I have been unable to find any way to do this securely. The aggregator doesn't need to do anything special here - their job is simp= ly to put merkle trees of commitments on-chain, and potentially earn fees d= irectly from the rescued users by doing so. > Generally, I'm thinking be it Lifeboat of Dropkick, they're bothvulnerabl= e 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. Astute observation! My understanding is that in a time dilation attack, the= victim sees blocks appear slower than usual, yes? So a time-dilation attac= ker would=C2=A0delay=C2=A0the victim from publishing her reveal longer than= they otherwise would, because the victim won't publish the reveal until `d= ` blocks after their commitment is mined. More concerning is, i don't think time dilation is necessary here - if anyt= hing it hurts the attackers because they have to wait longer before seeing = the reveal transaction, and thus they must maintain their eclipse for longe= r. An eclipse attack by itself is sufficient, as it allows the attackers to= censor the victim's reveal transaction and start working on their own comm= it/reveal spend without the victim realizing. More generally, if an adversary can convince the user that her reveal trans= action has been published when in fact it hasn't, then the attacker gains a= significant advantage in a censorship attack. An attacker with sufficient = hashrate could even convince the user her reveal has been mined when it has= n't. Though, for reasonable block delays (e.g. `d > 100`) the attacker woul= d need to maintain this kind of sandboxing/eclipse attack for potentially s= everal days. Lifeboat doesn't have this problem AFAICT. With Lifeboat, once a user's com= mitment is made, censorship attacks of any kind (including eclipse attacks)= are not possible without a deep reorg. As long as hers is the first valid = commitment in the chain, no subsequent commitments can usurp the user's spe= nding control with Lifeboat.=C2=A0 > As you're observing the aggregator is very at risk to be the objectof a d= istrubuted 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. Could you clarify, are you saying a third party could submit many commitmen= ts in an attempt to inflate the aggregator's fees and proof sizes for every= one else? This is precisely what anti-DoS measures would need to prevent.= =C2=A0=C2=A0 > This might be also delicate to have secure opening proof, as thecommitmen= t 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)= . Using the witness TXID to cover the user's commitment is probably not the b= est design, as proofs would be much larger (they'd have to include signatur= es and the coinbase transaction). Better is to put the=C2=A0commitment some= where outside the witness, e.g. in an OP_RETURN, or hidden in a P2TR public= key tweak (i.e. the vout script).=C2=A0 Correct me if i'm misunderstanding here, but if a third party malleates an = opening proof to point at a different (incorrect) commitment, this would si= mply render the proof invalid. Of course if the user makes multiple commitm= ents for the same secret=C2=A0witness, the proof could be malleated to poin= t between them. I'm not sure this is any more dangerous than the ability of= a user to create multiple distinct signatures for the same transaction inp= ut. Like a signature, the opening proof is either valid, or it's not in whi= ch case the whole reveal transaction becomes invalid.=C2=A0 --- Thanks again for your time and attention reading through the proposal. It i= s sincerely appreciated! regards, conduition On Friday, September 18th, 2026 at 9:53 AM, Antoine Riard wrote: > Hello Conduition, >=20 > Thanks for your Dropkick proposal. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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)= . >=20 > 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 protocol, and there > are not specific to DropKick or Lifeboat. >=20 > Overall, it's a very interesting formalization of the issues. >=20 > Best, > Antoine > OTS: cc1d5b4a3d0ed137fc3778ff2d72c35814d9aec8d2b8e74279740d6e726901e0 >=20 > [0] https://arxiv.org/abs/2006.01418 >=20 > Le Monday, August 24, 2026 =C3=A0 12:58:01=E2=80=AFAM UTC+1, conduition a= =C3=A9crit : >=20 > > Hi Alex, > >=20 > >=20 > > > We need to have an already functioning PQC solution for Bitcoin itsel= f, deployed, before any of commit/reveal can help, right? > >=20 > >=20 > > Yes. Two reasons: > >=20 > > First, without on-chain PQC, making commitments would be impossible to = do safely unless commitment are aggregated directly by miners into the coin= base transaction. > >=20 > > Second, without on-chain PQ-secure addresses, where would one even resc= ue coins to? Commit/reveal protocols are meant as a tool saving coins in an= emergency, not for everyday spending. > >=20 > >=20 > > PQ signature schemes are therefore needed as a prerequisite. > >=20 > >=20 > > regards, > > conduition > > On Saturday, August 22nd, 2026 at 1:46 PM, Alex wr= ote: > >=20 > > > Am I correct in understanding that commit/reveal always depends on so= meone else already having a valid PQC UTXO to spend? > > > So in other words, this can never be a solution for a (procrastinatin= g Bitcoin system), only a solution for (procrastinating Bitcoin users). > > >=20 > > > We need to have an already functioning PQC solution for Bitcoin itsel= f, deployed, before any of commit/reveal can help, right? > > >=20 > > > Den tors 20 aug. 2026 23:56'conduition' via Bitcoin Development Maili= ng List skrev: > > >=20 > > > > Dearest friends, colleagues, and lurkers, > > > >=20 > > > > I would like to present for your consideration a new commit/reveal = rescue protocol to save the coins of quantum procrastinators - those who ta= ke no 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= commitment somewhere on the blockchain, and reveal it later with an SPV-st= yle proof to Kick (spend) your legacy coins forward to a new PQ-secure wall= et. > > > >=20 > > > > Background > > > >=20 > > > > 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 secret witness to a quantum-ha= rd one-way function. The honest user hides a commitment in a block, waits f= or confirmations, and later reveals her commitment to certify she knew the = secret witness long before an adversary (like a quantum computer) could hav= e done so. Assuming this witness was indeed kept secret prior to reveal tim= e, it is already too late for the adversary to forge an equivalent proof. > > > >=20 > > > >=20 > > > > This general mechanism also allows validators to distinguish an hon= est bitcoin-holding procrastinator from a CRQC in many situations, and so p= rocrastinators can still authorize spending of their legacy UTXOs even well= after Q-day, provided the rescue protocol is deployed before Q-day as a ne= w encumbrance on affected legacy coins. > > > > DropKick In One Paragraph > > > >=20 > > > > DropKick specifically is a commit/reveal protocol where the commitm= ent `H(H(w, Q), Q)` is hidden somewhere in a block, such as an OP_RETURN or= inside a taproot tweak. `Q` is a post-quantum public key, and `w` is the w= itness to a one-way function `f`, such that `s =3D f(x)` is the script pubk= ey (address) encumbering a coin. We can later reveal the witness `w` and a = signature from pubkey `Q` to authorize a spend, along with an opening proof= showing that the commitment was included in a prior block. The verifier ch= ecks 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 prot= ocol. > > > >=20 > > > > Features > > > >=20 > > > >=20 > > > > Generality: DropKick generalizes to any efficient [1] one-way funct= ion based on knowledge asymmetries - things the honest user knows which the= adversary doesn't. In the context of Bitcoin, the one-way function would t= ypically be a computational pipeline that includes hashing of secret data u= nknown to a CRQC, such as "BIP32 hardened derivation of an address" or "has= hing 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. > > > >=20 > > > >=20 > > > > Compatibility: DropKick can be deployed as a soft-fork, as it only = tightens spending validation rules, and does so only on certain UTXOs. > > > >=20 > > > > Confiscation: DropKick can be deployed without confiscating any coi= ns, if so desired, by deploying it as an encumbrance only on UTXOs with dec= idable knowledge asymmetries like hashed addresses (see this section). If o= ne wishes to maximize the number of legacy coins rescued, DropKick can also= be deployed on undecidable knowledge asymmetries like BIP32-CKD. To be cle= ar, P2PK coins cannot be covered by DropKick or indeed by any rescue protoc= ol, as these UTXOs have no known knowledge asymmetries when a CRQC is in pl= ay. > > > >=20 > > > > Blockspace Efficiency: DropKick has near zero on-chain impact until= reveal time, at which point the commitment opening proofs are included in = a reveal transaction spending the legacy coins. Opening proofs could be att= ached in an OP_RETURN for backwards compatibility, or for better efficiency= the proofs could be attached in a new transaction witness field which woul= d allow for the 4x segwit discount to apply. DropKick opening proofs are ap= proximately the same size as SPV or OpenTimestamps proofs (less than a kilo= byte) 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 see= d. > > > >=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 si= gnature 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 e= ven faster. The only prerequisite data needed to verify the opening proof i= s the set of all Bitcoin block headers. Verifying the revealed witness `w` = is exactly as efficient as evaluating the one-way function `f(w)`. > > > >=20 > > > >=20 > > > > Ergonomics: Procrastinator do not need to have their own PQ-safe UT= XOs available to execute a DropKick rescue: Users can delegate their commit= ments to untrusted third party servers called "aggregators" who do have PQ-= safe UTXOs. These servers take it upon themselves to aggregate the commitme= nts of other users together into a merkle tree, whose root they publish on-= chain. Those aggregators can charge a salvage fee for their services if des= ired, paid in-band from the rescued UTXOs, or up-front out-of-band. Procras= tinators can shop between different aggregators, and anyone with PQ-safe UT= XOs can operate one. > > > >=20 > > > > Comparison to Lifeboat > > > >=20 > > > > DropKick competes directly with Tadge Dryja's Lifeboat/Lifejacket p= roposal (also see this older post), but DropKick aims for a different (lowe= r) degree of security in exchange for a simpler implementation surface, mor= e flexibility, and better efficiency. > > > >=20 > > > > The two protocols fulfill functionally similar roles, so I will tak= e 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 ho= nest spender), or generalization to arbitrary one-way functions. Such devel= opments could be easily transferred to Lifeboat as well, so I will mostly i= gnore these minor differences here. > > > >=20 > > > > The fundamental difference between DropKick and Lifeboat is the com= mitment ordering requirement. > > > >=20 > > > >=20 > > > > - Lifeboat requires procrastinators to (1) procure a PQ-secure UT= XO, and (2) upload a ~96-byte commitment in-the-clear in a new transaction,= such as in an OP_RETURN or inscription. Validators must index all such com= mitments, so that they can chronologically order the revealed commitments l= ater. Reveals reference this index to authorize spending: Only the earliest= valid commitment for a given witness is allowed to spend the legacy coin t= hat witness unlocks. > > > > =20 > > > > - DropKick encourages procrastinators to hide commitments in merk= le trees committed into blocks, such as via a merkle root posted in an OP_R= ETURN, or in a taproot-style key tweak. Reveals use SPV-style proofs to con= vince validators that the commitment was included in a past block. Validato= rs therefore 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= need for a new index database collecting all the commitments, and this fre= es us from putting commitments on chain in-the-clear. DropKick commitments = can be hidden off-chain, but anchored to the chain in merkle trees of arbit= rary size, which is the key feature that enables the new role of aggregator= s, and means procrastinators don't need PQ-UTXOs to publish a commitment an= d rescue their legacy coins. > > > >=20 > > > > To gain these benefits, DropKick sacrifices some security, by admit= ting miner censorship attacks where miners can intentionally censor a revea= l transaction to gain a chance to steal the procrastinator's coins. Lifeboa= t entirely avoids this class of attacks, whereas DropKick requires a somewh= at loose game-theoretical argument that miners will converge on choosing no= t to censor reveals, provided we enforce a long delay (days or weeks) betwe= en commitment and reveal steps, and provided the procrastinator pays a prop= ortional fee to incentivize honest miners. We also have to assume no 51% re= org 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 muc= h simpler and less complex engineering surface area, and supports rescuing = users in more diverse situations than LifeBoat can (because PQ UTXOs are ma= ndatory in Lifeboat). > > > >=20 > > > > LifeBoat's UX advantage over DropKick is that because of the orderi= ng, there is no long delay or value-proportional fee needed: Users only nee= d to wait a few blocks between commit and reveal stages, and they pay only = regular mining fees as usual. DropKick OTOH requires a delay proportional t= o the fraction of the UTXO one is willing to sacrifice to miners. E.g. if w= e assume users are willing to sacrifice 1% of their UTXOs, then we need to = enforce a reveal delay period of at least 100 blocks. See here for a deriva= tion of these parameters. > > > >=20 > > > > Conclusion > > > >=20 > > > > So that's it. > > > >=20 > > > > I'm submitting DropKick 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 miner censorship attacks, or if we can at least r= educe 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 r= ecompute it to validate reveal transactions without DoS risks. For example,= BIP32 master key derivation via BIP39 is not considered efficient because = it uses PBKDF2, whereas BIP32 CKD is efficient if restricted to a maximum d= erivation depth. > > > >=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, s= end an email to bitcoindev+...@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/ruufSzDPIml1W5hF-m_IJLeBzuhqey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs= 3sDesW61FaU_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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/0521d915-8613-47ea-ad44-6eaeaa5a6ed0n%40googlegroups.com. --=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/= MCeBFwbQNl9QpVD5DW7A-tEd3qvg-vnlJ7CrBcZvrCmjtjGleFxGrcQ49oK2rG9vVqGHe4aLhcE= uBGseNrj4tym_sl7jWN1JlDc7SKzciTQ%3D%40proton.me. -----------------------06d2620be9da971534d20a96a69ad9da Content-Type: multipart/related;boundary=---------------------eb36ec977b4e99934c78f1c6796b5341 -----------------------eb36ec977b4e99934c78f1c6796b5341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,= and thank you for spending the time to read into DropKick :)

On the d= elay, 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
ad= versarial one, and note the "toxicity" of the information, i.e
=
the commitment tx, you cannot delegate to a N number of aggregat= or,
as a single enough not complying is enough.

The reveal = delay (the d=E2=80=8B parameter) is enforced by con= sensus, during the reveal stage. The exact check is described in step 2 of = this secti= on:

<= div>Authenticate the commitment opening pi= =E2=80=8B, asserting H(H(w, Q), Q)=E2=80=8B was committed at l= east d=E2=80=8B blocks earlier.
=

The reveal delay d=E2=80=8B must unfortuna= tely be fixed at deployment time, and applies globally to every dropkick sp= end. So that, and the closely related minimum fee rate =CE=B4 ar= e very "bikeshed-able". One welcome area for suggestions would be if anyone= can find a way to allow users to pick their own block delay parameters to = better suit their uses cases. Unfortunately Tadge and I have been unable to= find any way to do this securely.

The aggregator doesn't need to do anything special here - the= ir job is simply to put merkle trees of commitments on-chain, and potential= ly earn fees directly from the rescued users by doing so.

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, to= o
earlier from the "real" chain time. Once the victi= m is sybilled,
one has a selfish mining advantage, a= nd this is realistic to consider
if the rescued coins are= of a significant amount.

=
Astute observation! My understanding is that in a time di= lation attack, the victim sees blocks appear slower than usual, yes? So a t= ime-dilation attacker would delay the victim from publishi= ng her reveal longer than they otherwise would, because the victim won't pu= blish the reveal until d=E2=80=8B blocks after their commitmen= t is mined.

More concerning is, i don't think time= dilation is necessary here - if anything it hurts the attackers because th= ey have to wait longer before seeing the reveal transaction, and thus they = must maintain their eclipse for longer. An eclipse attack by itself is suff= icient, as it allows the attackers to censor the victim's reveal transactio= n and start working on their own commit/reveal spend without the victim rea= lizing.

More generally, if an adversary can convin= ce the user that her reveal transaction has been published when in fact it = hasn't, then the attacker gains a significant advantage in a censorship att= ack. An attacker with sufficient hashrate could even convince the user her = reveal has been mined when it hasn't. Though, for reasonable block delays (= e.g. d > 100=E2=80=8B) the attacker would need to maintain = this kind of sandboxing/eclipse attack for potentially several days.
<= div>
Lifeboat doesn't have this problem AFAICT. With Lifeboat= , once a user's commitment is made, censorship attacks of any kind (includi= ng eclipse attacks) are not possible without a deep reorg. As long as hers = is the first valid commitment in the chain, no subsequent commitments can u= surp the user's spending control with Lifeboat. 

<= div>
As you're observing the aggregator is very at risk to be th= e object
of a distrubuted denial-of-service. While micro-p= ayment can be a
solution, there is always the risk o= f 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 atta= ck.

Cou= ld you clarify, are you saying a third party could submit many commitments = in an attempt to inflate the aggregator's fees and proof sizes for everyone= else? This is precisely what anti-DoS measures would need to prevent. = ; 

This might be also delicate to= have secure opening proof, as the
commitment transaction = witness txid could be altered before it's
included i= n 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 pro= of can be malleated
to point to another commitment t= x at spending or be plainly invalidated
while the carryin= g transaction would stay valid (some "half-state" issue).

Using the witness TXID t= o cover the user's commitment is probably not the best design, as proofs wo= uld be much larger (they'd have to include signatures and the coinbase tran= saction). Better is to put the commitment somewhere outside the= witness, e.g. in an OP_RETURN, or hidden in a P2TR public key tweak (i.e. = the vout script). 

Correct me if i'm misunder= standing here, but if a third party malleates an opening proof to point at = a different (incorrect) commitment, this would simply render the proof inva= lid. Of course if the user makes multiple commitments for the same s= ecret witness, the proof could be malleated to point between th= em. I'm not sure this is any more dangerous than the ability of a user to c= reate multiple distinct signatures for the same transaction input. Like a s= ignature, the opening proof is either valid, or it's not in which case the = whole reveal transaction becomes invalid. 

=
---

Tha= nks again for your time and attention reading through the proposal. It is s= incerely appreciated!

re= gards,
conduition
On Friday, September 18th, 2026 at 9:53 AM, Antoine Riard <= antoine.riard@gmail.com> wrote:
Hello Conduition,

Thanks for your Dropkick proposal.
=
Found the time to have a cursory read of your ideas, it's all
intere= sting. I think the problematization of the issue in plain
terms of knowl= edge 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 t= o rely on a derivation secret like parent BIP32 xprivs
one generate a ne= w 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 in= validated by the occurence of
the Q-day, though on the other hand it's a= n "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
proposi= ng 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 n= ote the "toxicity" of the information, i.e
the commitment tx, you canno= t 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 m= iner
and PQ adversary can go to forge a hashrate-good chain, sybil the<= br>target victim and trigger her or him to reveal her reveal tx, too
ear= lier from the "real" chain time. Once the victim is sybilled,
one has a = selfish mining advantage, and this is realistic to consider
if the rescu= ed coins are of a significant amount.

As you're observing the aggreg= ator 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 pro= of inflation cost, where
a third-party inflate the asked rate for micro-= payment beyond what
lowest economic users can afford for the proof, leve= raging a asymmetrical
factor in her or his benefice as it's a common res= source. A classic
when you have to evaluate lightning dos attack.
This might be also delicate to have secure opening proof, as the
commit= ment transaction witness txid could be altered before it's
included in t= he 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 t= ransaction 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,
I do think there a= re trade-offs affecting any rescue protocol, and there
are not specific = to DropKick or Lifeboat.

Overall, it's a very interesting formalizat= ion of the issues.

Best,
Antoine
OTS: cc1d5b4a3d0ed137fc3778ff= 2d72c35814d9aec8d2b8e74279740d6e726901e0

[0] https://arxiv.org/abs/2006.01418
Le M= onday, August 24, 2026 =C3=A0 12:58:01=E2=80=AFAM UTC+1, conduition a =C3= =A9crit :
Hi Alex,

<= span style=3D"font-family:Arial,sans-serif">We need to have an already func= tioning PQC solution for Bitcoin itself, deployed, before any of commit/rev= eal can help, right?

Yes. T= wo reasons:

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

Second, without on-chain PQ-secure addresses, where wo= uld one even rescue coins to? Commit/reveal protocols are meant as a= tool saving coins in an emergency, not for everyday spending.
=

= PQ signature schemes are therefore needed as a prerequisite.

re= gards,
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 Mailing List &= lt;bitco...@googlegroups.com> skrev:
Dearest friends, colleagues, and lurkers,

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


The term "DropKick" is self-descriptive of its usage: Drop a hidden commitment somewhere on the blockchain, and reveal it la= ter with an SPV-style proof to Kick (spend) your legacy coins forwar= d to a new PQ-secure wallet.

Background<= /span>

=
As with an= y post-quantum commit/reveal protocol, DropKick uses the blockchain as a tr= ustless timestamping service to prove than an honest user had earlier chron= ological knowledge of some secret witness to a quantum-hard one-w= ay function. The honest user hides a commitment in a block, wait= s for confirmations, and later 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 too late for the adversary to forge an equivalen= t proof.

<= img width=3D"693" height=3D"555" src=3D"https://ci6.googleusercontent.com/p= roxy/84lhyGRFWbCuurF3o6dHtnsbYmdUSS3rultCppXMyQmCI0l7b-ZF7wzkApX2EtqyoCL5PN= fIv9Qb_ph08ef4iv39X6xnWEA=3Ds0-d-e1-ft#https://conduition.io/images/dropkic= k/fawkescoin.svg">

This general mechanism also allows validators to distinguish an hon= est bitcoin-holding procrastinator from a CRQC in many situations, and so p= rocrastinators can still authorize spending of their legacy UTXOs even well= after Q-day, provided the rescue protocol is deployed befo= re Q-day as a new encumbrance on affected legacy coins.

DropKick In One Parag= raph

DropK= ick 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_RE= TURN or inside a taproot tweak. Q=E2=80=8B is a post-quantum p= ublic 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= script pubkey (address) encumbering a coin. We can later reveal the witnes= s w=E2=80=8B and a signature from pubkey Q=E2=80= =8B to authorize a spend, along with an opening proof showing that t= he commitment was included in a prior block. The verifier checks the commit= ment opening is valid and sufficiently old, checks s =3D f(x)= =E2=80=8B, and verifies the PQ-signature from Q=E2=80=8B.


Features

Generality: DropKick generalizes to any efficient [1= ] one-way function based on knowledge asymmetries - things the honest user = knows which the adversary doesn't. In the context of Bitcoin, the one-way f= unction would typically be a computational pipeline that includes hashing o= f secret data unknown to a CRQC, such as "BIP32 hardened derivation of an a= ddress" or "hashing a public key or script to build an address" or "taproot= key tweaking". DropKick can be instantiated with different one-way functio= ns 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 deployed witho= ut confiscating any coins, if so desired, by deploying it as an encumbr= ance only on UTXOs with decidable knowledge asymmetries like hashed = addresses (see this section). If one wishes to maximize the number of lega= cy coins rescued, DropKick can also be deployed on undecidable knowl= edge 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.

Blockspace Efficiency: DropKick = has near zero on-chain impact until reveal time, at which point the commitm= ent opening proofs are included in a reveal transaction spending the= legacy coins. Opening proofs could be attached in an OP_RETURN for backwar= ds compatibility, or for better efficiency the proofs could be attached in = a new transaction witness field which would allow for the 4x segwit discoun= t to apply. DropKick opening proofs are approximately the same size as SPV or OpenTimestamps proofs (less than a kilobyte) and tho= se 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 s= ize, and the cost of verification scales linearly with the size of the proo= f. If one has txindex=3D1=E2=80=8B enabled, verification is even faster. = The only prerequisite data needed to verify the opening proof is the= set of all Bitcoin block headers. Verifying the revealed witness w=E2=80=8B is exactly as efficient as evaluating the one-way fun= ction f(w)=E2=80=8B.

Ergonomics: Procrastinator do not need to have their own PQ-safe UTXOs available to execute a DropKick res= cue: Users can delegate their commitments to untrusted third party servers = called "aggregators" who do have PQ-safe UTXOs. These servers take i= t upon themselves to aggregate the commitments of other users together into= a merkle tree, whose root they publish on-chain. Those aggregators can cha= rge a salvage fee for their services if desired, paid in-band from the resc= ued 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 DropKick aims fo= r a different (lower) degree of security in exchange for a simpler impleme= ntation surface, more flexibility, and better efficiency.

The two protocols fulfill functi= onally similar roles, so I will take a moment to compare and contrast DropK= ick 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 arbitrary one-way functions.= Such developments could be easily transferred to Lifeboat as well, so I wi= ll mostly ignore these minor differences here.

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

  • Lifeboat require= s procrastinators to (1) procure a PQ-secure UTXO, and (2) upload a ~96-byt= e commitment in-the-clear in a new transaction, such as in an OP_RETURN or = inscription. Validators must index all such commitments, so that they can <= b>chronologically order the revealed commitments later. Reveals referen= ce this index to authorize spending: Only the earliest valid commitment for= a given witness is allowed to spend the legacy coin that witness unlocks.
  • Dr= opKick encourages procrastinators to hide commitments in merkle tree= s committed into blocks, such as via a merkle root posted in an OP_RETURN, = or in a taproot-style key tweak. Reveals use SPV-style proofs to convince v= alidators 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.

By dropping the commitment ordering requirement, Dro= pKick skips the need for a new index database collecting all the commitment= s, and this frees us from putting commitments on chain in-the-clear. DropKi= ck 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 rol= e of aggregators, and means procrastinators don't need PQ-UTXOs to publish = a commitment and rescue their legacy coins.

To gai= n these benefits, DropKick sacrifices some security, by admitting miner censorship att= acks where miners can intentionally censor a reveal transaction to gain= a chance to steal the procrastinator's coins. Lifeboat entirely avoids thi= s 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 long delay (days or weeks) between= commitment and reveal steps, and provided the procrastinator pays a propor= tional fee to incentivize honest miners. We also have to assume no 51% reor= g attacks of course, as a malicious hashrate majority could easily censor a= ny reveal transactions and so steal coins.

However= , if this security loss is acceptable, DropKick offers a much simpler and l= ess complex engineering surface area, and supports rescuing users in more d= iverse situations than LifeBoat can (because PQ UTXOs are mandatory in Life= boat).

LifeBoat's UX advantage over DropKick is th= at because of the ordering, there is no long delay or value-proportional fe= e needed: Users only need to wait a few blocks between commit and reveal stages, and they pay only regular mining fees as usual. DropKic= k OTOH requires a delay proportional to the fraction of the UTXO one is wil= ling to sacrifice to miners. E.g. if we assume users are willing to sacrifi= ce 1% of their UTXOs, then we need to enforce a reveal delay period of at l= east 100 blocks. See here for a derivation of these parameters.
=

Con= clusion

So that's it.

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

regards,
conduition

[1]: The = one-way function must be efficient so that verifiers can recompute i= t to validate reveal transactions without DoS risks. For example, BIP32 mas= ter key derivation via BIP39 is not considered efficient because it uses PB= KDF2, 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+..= .@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 "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0521d915-8613-47ea-ad4= 4-6eaeaa5a6ed0n%40googlegroups.com.

--
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/MCeBFw= bQNl9QpVD5DW7A-tEd3qvg-vnlJ7CrBcZvrCmjtjGleFxGrcQ49oK2rG9vVqGHe4aLhcEuBGseN= rj4tym_sl7jWN1JlDc7SKzciTQ%3D%40proton.me.
-----------------------eb36ec977b4e99934c78f1c6796b5341-- -----------------------06d2620be9da971534d20a96a69ad9da-- -----------------------d82cfe6b1a76e53b3d8d9010fdd0c125 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== -----------------------d82cfe6b1a76e53b3d8d9010fdd0c125-- --------e26a4d97fabe03ce0445e3a4e5fa5fd2cfadda62aa1252008c0d0b4beea8a448 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmrBoz8JEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcxnSYsJQ2QA2UPsRaC7BckSpHZKaFjW2ecnhVX 2/9QfRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAm1gEAl3z1NiGb9HUgtk7u SYb8kywzmJMfh0D85enhVB6YKWIBANdW2CT/pvKJr4K3TFGX4QGxfKEJwX8R Wtdgp2/vuZ0E =EmTS -----END PGP SIGNATURE----- --------e26a4d97fabe03ce0445e3a4e5fa5fd2cfadda62aa1252008c0d0b4beea8a448--