From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 20 Aug 2026 14:56:39 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wxAkY-00087o-I1 for bitcoindev@gnusha.org; Thu, 20 Aug 2026 14:56:39 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-456b5122c7csf2030233fac.1 for ; Thu, 20 Aug 2026 14:56:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787262992; cv=pass; d=google.com; s=arc-20260327; b=cy64Oh7xxRWLypciMgfqds3m7zrDys7QYJBr7xEmHwGEiJGJ6DgAmDaPGNxTn1PM2V u7y3SIb6XfJhE3xNnCdlHaj1/Cy1jcih701ecXk9dt0Ev1G6Nn/mNPSMIh3wBCbr+pID ibg6Q5vqEvjTGwcThEs6jr961qh+eklpoqfk+GjOXE7fzlFeWtv+yblftq899a1/Fxdv 4L2b4bck+qBjABOZn/9P5TjuzGa7I7xKvM5Em8niXJyARuNbVAL3N0c6i5huYc3KQ/m3 0AtyDMhRJCtgbb/E6AC2q3X0UzBrWyXocBe/v6CSsg2e8/uK6mNooKkdH2W0VsQMaKCO WAHg== 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 :message-id:subject:from:to:date:dkim-signature; bh=YwO84Av+Y8BmIS+J2z0ajqQ7RcAJ6ApiwdX/NTk29Ss=; fh=KgKlWMxlIdCNUXe2PIkHRZY24shVSWcHw2WgrlCIAdI=; b=avORO9L3l2bDCfNJaRpEG0iaGVlqB/vZg/gCSEqlDqsa88p9LEdqlB2pD2AaJD2s8j ++GJHf5XiJ0yg/BECgnSX+fxExGT0Ci5yQSW0K4poCyUDdDpEZmxico73L3O+wnk4/Qa h8ie/dF62SHqd1ZxtWXmQAna0r81bP8Pto48Z2unwCGXeU02Zu9tRkrICOCKuT6n4CF0 v0x6ndSB79XtoMau/R/nyQE83GyImkQWg7sAvajQoEZFiaQDO26RHZDHFKD6Mr7ipzaj LSoeg76rzqVpxqJL737P2P34jEwV8YNNfv0Hg6xYZsLs47DjvOsncEDTocTWQvqjHJJW Pokg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=nety7wia7bap3gn4g7tifqdgx4.protonmail header.b=JRBUbtc9; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.31 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=1787262992; x=1787867792; 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:message-id:subject:from:to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=YwO84Av+Y8BmIS+J2z0ajqQ7RcAJ6ApiwdX/NTk29Ss=; b=UAr1uGccSiqK/7GbtHX3UHUpSrWb8JWNdsenBtlk2yFw65qjIRek3gINU++qXrHhas Xn0Sgw8JfLa8DoRscn5huzQ66dT7djdk4RORvJ9kMV50wnvV6Iu9zHt3c/Py78EkCIIT kjDhxosC9+rLneyEVIh5u0uGz9AT5BZLcrmQ0gCWnJGafAG7+QMl1eUwT0XKOLBcJv1N 3VXZmn0rtAS2PpUpX0LGcceNXfKxqgqF11gTZPc1ojDomkJ2Y44ljGC8dOCHAIhevDlI +uryyxNWvIcKpNmqVTBauLPdy9E4Nr+A37m6+AD8IKhUw2v/94E/BLUDupPSZiHK9nxw hl7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787262992; x=1787867792; 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:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=YwO84Av+Y8BmIS+J2z0ajqQ7RcAJ6ApiwdX/NTk29Ss=; b=U6Ay1irqNjYhczlbuUfZrp37Q2aHRt5maJyCq+VDDNX8aA0Do8Eq26b1hMCSTuXwir Ees6rVP0cKWMCxObiANTnznlHDYh8G/CBM9IMIyDgA7w90DmiYaJ6AL19cWCKKYbQL87 RQ6/CiRdZII7RwbyBk26ZO2yHN47MOlnhozZjvhKoniNxzmuJfmJSBOf3261wdTS38gP fWfMiSW45aikm8/6Sh74frTvyIAl/o2b/SEZsthQnCIs8SKPNo1Ssa1QSLEgNL/Lx6Z4 AteA/9UXqQbbSblMO24SyLdZfIDgkv1mXHb/YD8GJFYSy4g5KpKZhm/Dgs+eNODcpoK2 auew== X-Forwarded-Encrypted: i=2; AHgh+RpSP4gQKm1GlVDfgGxeEWdBtVW/uUG84MD6ac3A+NO/KBsNzxsX5cjAcJhVCr4DT6QiVxEdrvFmygfC@gnusha.org X-Gm-Message-State: AOJu0YxT+zG4sSiWFahv85WfWjU/0n1xGDgZJv+1KLh1u+h845lFKshH v78JstrUr6x+BCOCil5nzXoSFdvefG6zekvwigQzxK6xTOzajJDgHo8n X-Received: by 2002:a4a:d1ba:0:b0:6aa:e367:a3e2 with SMTP id 006d021491bc7-6b1492fca45mr7121177eaf.19.1787262992027; Thu, 20 Aug 2026 14:56:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcMWeYHHvuuH5nNfSaOyGvi7gbVw/KksW8/Hr6/wqAs8w==" Received: by 2002:a05:6870:6289:b0:457:ae9e:6504 with SMTP id 586e51a60fabf-462eef6774fls878355fac.0.-pod-prod-00-us-canary; Thu, 20 Aug 2026 14:56:26 -0700 (PDT) X-Received: by 2002:a05:6808:1b2b:b0:496:976:acad with SMTP id 5614622812f47-4b2ef4af87bmr1112401b6e.1.1787262986823; Thu, 20 Aug 2026 14:56:26 -0700 (PDT) Received: by 2002:a05:6808:a547:10b0:495:e116:a399 with SMTP id 5614622812f47-4b2b59fbeb1msb6e; Thu, 20 Aug 2026 14:30:09 -0700 (PDT) X-Received: by 2002:a05:6830:a219:10b0:7e9:de1a:16ea with SMTP id 46e09a7af769-7f44c0caf11mr7169865a34.13.1787261409014; Thu, 20 Aug 2026 14:30:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787261409; cv=none; d=google.com; s=arc-20260327; b=ErS6OHuB/qQ/UKHK8GoYVnhEdAspCREVzRbKcIzp9XrQO0PtrHBxEIt47rgCLE0zW0 A2rwpsWg8jlyrcGX3NwmL8yu2qH2ELOLtPPAE3Ngi0evMoCxcAGF7g4gWYaME4EvO8r3 RPXLWpNtCc5WHs25z9PwZB/JcrihsOklKJS5wtlFVqD03GcUQBt6iBrwmkKY9mjYsbJw BOW2uxaHWpdPHeWtaPOvOFIXO8kjZa+jTg4o8jE51GAZoeae6zUECcsSPbfJ/N6eBrjV HbZI4iODWkd0uuGtsV7Z7NUOd06ujjb9OVDczTJRrZ7erNQMX6KSbdkI8LxwgpnVDczm EL8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=GUgsqNvFQXBDErvHm2SP9Sfi5xnHR1aWp5XvFf73nzw=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=Zw2bBqrura10HNl8fIVS3pBDditEJMFaqh7U8B3/3bAPlG5qXEnNRm+0PdPRNZrgcv 3zhYLWNTVGk244SCvmK6mGhYTy11M+bHrvzYl76I1Kaz+kUxh0L2Wn6gv1LbHkGGbry0 udySul7ERGdAYt20tdmlmcVl8/iQQ78bxLg95UCwyDNde4pLn0Ejn5+WImua6iXlIGWk 2zl1dzS7jmqfUHEXzoT+Emc1IrlaSPsAjo3AMJaRNtJqv6UDqqHpTCCpcOU3Zd18xJbA c1y+Rgw1aMb9vkAOuMIKRkfMDZuOWQTf6mVjL7nCknWIYog4hm6SKFUoMPoLxq0fuY7o /fww==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=nety7wia7bap3gn4g7tifqdgx4.protonmail header.b=JRBUbtc9; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.31 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24431.protonmail.ch (mail-24431.protonmail.ch. [109.224.244.31]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7f43fe4bbd2si181542a34.1.2026.08.20.14.30.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2026 14:30:07 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.31 as permitted sender) client-ip=109.224.244.31; Date: Thu, 20 Aug 2026 21:30:01 +0000 To: "bitcoindev@googlegroups.com" From: "'conduition' via Bitcoin Development Mailing List" Subject: =?UTF-8?Q?=5Bbitcoindev=5D_DropKick_=E2=9A=BD=EF=B8=8F_=2D_A_minimal_commit=2Freve?= =?UTF-8?Q?al_PQ_rescue_protocol?= Message-ID: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: de43d38ae7df695f55d41245d305c32be04e6a47 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------3e9d16f5057a407a9f14c6bd20b119654f9a70172c89628df5565dc224b690db"; 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=nety7wia7bap3gn4g7tifqdgx4.protonmail header.b=JRBUbtc9; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.31 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) --------3e9d16f5057a407a9f14c6bd20b119654f9a70172c89628df5565dc224b690db Content-Type: multipart/mixed;boundary=---------------------2096af60c0e991ad277f36e6de24753e -----------------------2096af60c0e991ad277f36e6de24753e Content-Type: multipart/alternative;boundary=---------------------e647d481f8d0054922949e9338855117 -----------------------e647d481f8d0054922949e9338855117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Dearest friends, colleagues, and lurkers, I would like to present for your consideration a new commit/reveal rescue p= rotocol to save the coins of quantum procrastinators - those who take no ac= tion 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 commitm= ent somewhere on the blockchain, and reveal it later with an SPV-style proo= f to Kick=C2=A0(spend) your legacy coins forward to a new PQ-secure wallet. Background As with any post-quantum commit/reveal protocol, DropKick uses the blockcha= in as a trustless timestamping service to prove than an honest user had ear= lier chronological knowledge of some secret witness=C2=A0to a quantum-hard = one-way function. The honest user hides a commitment in a block, waits for = confirmations, and later reveals=C2=A0her commitment to certify she knew th= e secret witness long before an adversary (like a quantum computer) could h= ave done so. Assuming this witness was indeed kept secret prior to reveal t= ime, it is already too late for the adversary to forge an equivalent proof. This general mechanism also allows validators to distinguish an honest bitc= oin-holding procrastinator from a CRQC in many situations, and so procrasti= nators can still authorize spending of their legacy UTXOs even well after Q= -day, provided the rescue protocol is deployed=C2=A0before=C2=A0Q-day as a = new encumbrance on affected legacy coins. DropKick In One Paragraph DropKick specifically is a=C2=A0commit/reveal protocol where the commitment= =C2=A0`H(H(w, Q), Q)` is hidden somewhere in a block, such as an OP_RETURN = or inside a taproot tweak.=C2=A0`Q` is a post-quantum public key, and `w`= =C2=A0is the witness to a one-way function `f`, such that `s =3D f(x)` is t= he script pubkey (address) encumbering a coin. We can later reveal the witn= ess `w` and a signature from pubkey=C2=A0`Q` to authorize a spend, along wi= th an opening proof=C2=A0showing that the commitment was included in a prio= r block. The verifier checks the commitment opening is valid and sufficient= ly old, checks `s =3D f(x)`, and verifies the PQ-signature from `Q`. See this section for the actual proving/verifying steps of the protocol. Features Generality:=C2=A0DropKick generalizes to any efficient [1]=C2=A0one-way fun= ction based on knowledge asymmetries - things the honest user knows which t= he adversary doesn't.=C2=A0In 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 key twe= aking". DropKick can be instantiated with different one-way functions to en= cumber 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 without=C2=A0confiscating any coins,= if so desired, by deploying it as an encumbrance only on UTXOs with=C2=A0d= ecidable=C2=A0knowledge asymmetries like hashed addresses (see this section= ). If one wishes to maximize the number of legacy coins rescued, DropKick c= an also be deployed on undecidable=C2=A0knowledge asymmetries like BIP32-CK= D. To be clear, P2PK=C2=A0coins cannot be covered by DropKick or indeed by = any rescue protocol, as these UTXOs have no known knowledge asymmetries whe= n a CRQC is in play. 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=C2=A0spending the legacy coins. Opening proofs could be attach= ed in an OP_RETURN for backwards compatibility, or for better efficiency th= e proofs could be attached in a new transaction witness field which would a= llow for the 4x segwit discount to apply. DropKick opening proofs are appro= ximately the same size as SPV or OpenTimestamps proofs (less than a kilobyt= e) and those proofs can be reused to rescue multiple related UTXOs, e.g. co= ins 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 verification scales linearly with the siz= e of the proof. If one has=C2=A0`txindex=3D1` enabled, verification is even= faster.=C2=A0The only prerequisite data needed to verify the opening proof= is the set of all Bitcoin block headers.=C2=A0Verifying the revealed witne= ss `w`=C2=A0is exactly as efficient as evaluating the one-way function `f(w= )`. Ergonomics:=C2=A0Procrastinator do not need to have their own PQ-safe UTXOs= available to execute a DropKick rescue: Users can delegate their commitmen= ts to untrusted third party servers called "aggregators" who do=C2=A0have P= Q-safe UTXOs. These servers take it upon themselves to aggregate the commit= ments of other users together into a merkle tree, whose root they publish o= n-chain. Those aggregators can charge a salvage fee for their services if d= esired, paid in-band from the rescued UTXOs, or up-front=C2=A0out-of-band.= =C2=A0Procrastinators can shop between different aggregators, and anyone wi= th PQ-safe UTXOs can operate one. Comparison to Lifeboat DropKick competes directly with Tadge Dryja's Lifeboat/Lifejacket proposal= =C2=A0(also see this older post), but DropKick aims for a different (lower)= degree of security in exchange for a simpler implementation surface, more = flexibility, and better efficiency. The two protocols fulfill functionally similar roles, so I will take a mome= nt 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 spe= nder), or generalization to arbitrary one-way functions. Such developments = could be easily transferred to Lifeboat as well, so I will mostly ignore th= ese minor differences here. The fundamental difference between DropKick and Lifeboat is the commitment = ordering requirement. - Lifeboat requires procrastinators to (1) procure a PQ-secure UTXO, 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 commitments= , so that they can chronologically order=C2=A0the revealed commitments late= r. Reveals reference this index to authorize spending: Only the=C2=A0earlie= st valid commitment for a given witness is allowed to spend the legacy coin= that witness unlocks. =20 - DropKick encourages procrastinators to hide=C2=A0commitments in merkle = trees committed into blocks, such as via a merkle root posted in an OP_RETU= RN, or in a taproot-style key tweak. Reveals use SPV-style proofs to convin= ce validators that the commitment was included in a past block. Validators = therefore 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, DropKick skips the need fo= r a new index database collecting all the commitments, and this frees us fr= om putting commitments on chain in-the-clear. DropKick commitments can be h= idden off-chain, but anchored to the chain in merkle trees of arbitrary siz= e, which is the key feature that enables the new role of aggregators, and m= eans procrastinators don't need PQ-UTXOs to publish a commitment and rescue= their legacy coins. To gain these benefits, DropKick sacrifices some security, by admitting=C2= =A0miner censorship attacks=C2=A0where miners can intentionally censor a re= veal transaction to gain a chance to steal the procrastinator's coins. Life= boat entirely avoids this class of attacks, whereas DropKick requires a som= ewhat loose game-theoretical argument that miners will converge on choosing= not=C2=A0to censor reveals, provided we enforce a long delay (days or week= s) between commitment and reveal steps, and provided the procrastinator pay= s a proportional fee to incentivize honest miners. We also have to assume n= o 51% reorg attacks of course, as a malicious hashrate majority could easil= y censor any reveal transactions and so steal coins. However, if this security loss is acceptable, DropKick offers a much simple= r and less complex engineering surface area, and supports rescuing users in= more diverse situations than LifeBoat can (because PQ UTXOs are mandatory = in Lifeboat). LifeBoat's UX advantage over DropKick is that because of the ordering, ther= e is no long delay or value-proportional fee needed: Users only need to wai= t a few blocks between commit=C2=A0and reveal=C2=A0stages, and they pay onl= y regular 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 t= o enforce a reveal delay period of at least 100 blocks. See here for a deri= vation of these parameters.=C2=A0 Conclusion So that's it. I'm submitting DropKick here as a sketch for consideration, not as a concre= te proposal. I am most interested to know if anyone can think of a better m= echanism to avoid miner censorship attacks, or if we can at least reduce th= e strength of the assumptions needed for DropKick to resist them. regards, conduition [1]: The one-way function must be efficient=C2=A0so that verifiers can reco= mpute it to validate reveal transactions without DoS risks. For example, BI= P32 master key derivation via BIP39 is not considered efficient because it = uses PBKDF2, whereas BIP32 CKD is efficient if restricted to a maximum deri= vation 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, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= ruufSzDPIml1W5hF-m_IJLeBzuhqey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61= FaU_asfj39Ri1QgSXtz7-OekEt6bbTvo%3D%40proton.me. -----------------------e647d481f8d0054922949e9338855117 Content-Type: multipart/related;boundary=---------------------2a1b051f88fe0ef501482b75fd3bb51e -----------------------2a1b051f88fe0ef501482b75fd3bb51e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dearest fri= ends, colleagues, and lurkers,

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


The term "DropKick" is self-descri= ptive of its usage: Drop a hidden commitment somewhere on the blockc= hain, 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/re= veal protocol, DropKick uses the blockchain as a trustless timestamping ser= vice to prove than an honest user had earlier chronological knowledge of so= me secret witness to a quantum-hard one-way function. T<= span style=3D"display: inline !important; background-color: rgb(255, 255, 2= 55);">he honest user hides a commitment in a block, waits for confir= mations, and later reveals her commitment to certify she knew t= he 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 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.<= /span>

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 tap= root tweak. 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, such that s =3D f(x)=E2=80=8B is the script pu= bkey (address) encumbering a coin. We can later reveal the witness w<= /code>=E2=80=8B and a signature from pubkey Q=E2=80=8B to= authorize a spend, along with an opening proof showing that th= e commitment was included in a prior block. The verifier checks the commitm= ent 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=

<= /div>
=
Generali= ty: DropKick generalizes to any efficient [1] one-way = function based on knowledge asymmetries - things the honest user knows whic= h 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 "tapro= ot key tweaking". DropKick can be instantiated with different one-way funct= ions to encumber different coins.

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

Confiscation: DropKick can be deployed without confiscating any coins, if = so desired, by deploying it as an encumbrance only on UTXOs with de= cidable knowledge asymmetries like hashed addresses (see this = section). If one wishes to maximize the number of legacy coins rescued,= DropKick can also be deployed on undecidable knowledge asymmet= ries 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 t= he commitment opening proofs are included in a reveal transaction&nb= sp;spending the legacy coins. Opening proofs could be attached in an OP_RET= URN for backwards compatibility, or for better efficiency the proofs could = be attached in a new transaction witness field which would allow for the 4x= segwit discount to apply. DropKick opening proofs are approximately the sa= me size as SPV or OpenT= imestamps 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: DropKi= ck 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, a= nd the cost of verification scales linearly with the size of the proof. If one has txindex=3D1=E2=80=8B enabled, verificat= ion is even faster. The only prerequisite data needed to verify= the opening proof is the set of all Bitcoin block headers. Ver= ifying the revealed witness w=E2=80=8B is exactly as effi= cient as evaluating the one-way function f(w)=E2=80=8B.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
Ergonomics: Procrastinator do not need to have= their own PQ-safe UTXOs available to execute a DropKick rescue: Users can = delegate their commitments to untrusted third party servers called "aggrega= tors" who do have PQ-safe UTXOs. These servers take it upon the= mselves to aggregate the commitments of other users together into a merkle = tree, whose root they publish on-chain. Those aggregators can charge a salv= age fee for their 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 on= e.
Comparison to Lifeboat<= /span>

= DropKick competes directly with Tadge Dryja's Lifeboat/Lif= ejacket proposal (also see this older post), but DropKick aims f= or a different (lower) degree of security in exchange for a simpler implem= entation surface, more flexibility, and better efficiency.

The two protocols ful= fill functionally similar roles, so I will take a moment to compare and con= trast DropKick and Lifeboat/Lifejacket.

DropKick includes some novel features whic= h Lifeboat does not, such as key certification (allowing things like= RBF, or equivocation, by the honest spender), or generalization to arbitra= ry one-way functions. Such developments could be easily transferred to Life= boat as well, so I will mostly ignore these minor differences here.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
The fundament= al difference between DropKick and Lifeboat is the commitment ordering requ= irement.

  • Lifeboat requires procrastinato= rs to (1) procure a PQ-secure UTXO, and (2) upload a ~96-byte commitment in= -the-clear in a new transaction, such as in an OP_RETURN or inscription. Va= lidators must index all such commitments, so that they can chronological= ly order the revealed commitments later. Reveals reference this in= dex to authorize spending: Only the earliest valid commitment f= or a given witness is allowed to spend the legacy coin that witness unlocks= .
  • DropKick encourages procrastinators to hide commitments in me= rkle trees 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 c= onvince validators that the commitment was included in a past block. Val= idators therefore do not (and cannot) index all commitments, and so there = is no way to confirm any one commitment was earliest.
    • <= div>
    By dropping the commitment ordering require= ment, DropKick skips the need for a new index database collecting all the c= ommitments, and this frees us from putting commitments on chain in-the-clea= r. 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 th= e new role of aggregators, and means procrastinators don't need PQ-UTXOs to= publish a commitment and rescue their legacy coins.

    To gain these benefits, DropKick sacrifices some security, by admitting&= nbsp;miner censorship attacks where miners can intentionally = censor a reveal transaction to gain a chance to steal the procrastinator's = coins. Lifeboat entirely avoids this class of attacks, whereas DropKick req= uires a somewhat loose game-theoretical argument that min= ers will converge on choosing not to censor reveals, provided w= e enforce a long delay (days or weeks) between commitment and reveal steps,= and provided the procrastinator pays a proportional fee to incentivize hon= est miners. We also have to assume no 51% reorg attacks of course, as a mal= icious hashrate majority could easily censor any reveal transactions and so= steal coins.

    However, if this security loss is ac= ceptable, DropKick offers a much simpler and less complex engineering surfa= ce area, and supports rescuing users in more diverse situations than LifeBo= at can (because PQ UTXOs are mandatory in Lifeboat).

    LifeBoat's UX advantage over DropKick is that because of the ordering, t= here 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 regular mining fees as usual. DropKick OTOH requires a d= elay proportional to the fraction of the UTXO one is willing to sacrifice t= o miners. E.g. if we assume users are willing to sacrifice 1% of their UTXO= s, then we need to enforce a reveal delay period of at least 100 blocks. See here for a derivation of these parameters. 

    Conclusion

    So that's it.

    <= /div>
    I'm submitting DropKick here as a sketch for consideration, not a= s 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= reduce the strength of the assumptions needed for DropKick to resist them.=

    regards,
    conduition


    [1]: The one-way function must be efficient&nb= sp;so that verifiers can recompute it to validate reveal transactions witho= ut DoS risks. For example, BIP32 master key derivation via BIP39 is not con= sidered 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 &= 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/ruufSz= DPIml1W5hF-m_IJLeBzuhqey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61FaU_as= fj39Ri1QgSXtz7-OekEt6bbTvo%3D%40proton.me.
    -----------------------2a1b051f88fe0ef501482b75fd3bb51e-- -----------------------e647d481f8d0054922949e9338855117-- -----------------------2096af60c0e991ad277f36e6de24753e 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== -----------------------2096af60c0e991ad277f36e6de24753e-- --------3e9d16f5057a407a9f14c6bd20b119654f9a70172c89628df5565dc224b690db Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqHccoJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcKtFHaLkTgnL+WeLNFsB9ERoyQ/1uiHe44tSF2 QGVJIRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACiFAEA+HIDCq20y4AClE6o Xj4Xiy0m6CcKmYB4OYrv2avEvDEA/RHNmvdhh3wxj4sIj3It8p4N+CynsNQe 6MUbFt+XmiQK =DJWc -----END PGP SIGNATURE----- --------3e9d16f5057a407a9f14c6bd20b119654f9a70172c89628df5565dc224b690db--