From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 22 Aug 2026 10:48:55 -0700 Received: from mail-ot1-f58.google.com ([209.85.210.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 1wxppt-0001cT-UH for bitcoindev@gnusha.org; Sat, 22 Aug 2026 10:48:55 -0700 Received: by mail-ot1-f58.google.com with SMTP id 46e09a7af769-7e9dc0f5900sf6731313a34.0 for ; Sat, 22 Aug 2026 10:48:53 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1787420927; cv=pass; d=google.com; s=arc-20260327; b=IEuQqFOXxSkesvUi27sGcVf7kLTtcK4k51CZ2NbE8hrWOE8sPKGirAzVOONVpd+oRi Cq0PXBio6WBvTtE2T13hOAcvhSj4LWSu8JceXm/oMzDxzUD2Ili8tfiaP2cKcQDY2wPM pSQstF5GqUB+i9gli3PFHRomdro3TPMDqZBIIsuyR9nOBs+LT8uI/wnZJSotvdk10PUC pOO82Av5kUDcnfcUioa72xqqY1VpLlH7RfF/gj3Z24Kt+gJDQFxLqklqeF1RTYeKMR4w O0VzaZ2lb8vXuYg8KVz62Nj0fphOAbpAnj7jRrKzvtcUzyOLptjvQKwxVtVDsSEQstJW QwWQ== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=k6Chbw1X6zrtg/x12ibUkDAEJumkRsEO2FsOBeoQXbI=; fh=Vxt53/zhCfMAyCAmPaAsVetBgXnIA418lVDZRwKt1Cc=; b=BkpPCdIPCSDtb2E22kVPdWp39b71xlS3FAz4cixD2yhz/U8b9w/pAGAAfbupuqy1VB 9HHSeQOk9s7HPSXwpkNoSbl03Lg7rmV+ouYBpxNt2ysiNzC6iYPEv/XGzVt9D6ZfdQto 9FGAj0MqpFJugMHibSlI+pq213HBLI7z68auT0hUUjxI4st1GKFYt+xh+EYAYNC2jfjM JEYkK0T+kPbibcVrOBr8pNQh8yzMTLsRk+874lHS6gT12lmH6r0dteG76c8CCjjmXRSE +fSA7WrazxokXY34CLsYBycQaagRetpN6KssdtU3G82/x1GZzpNrZeB0GwZ3rcc2Bayp 7Ubg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=B9wLuqlk; arc=pass (i=1); spf=pass (google.com: domain of alexhultman@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=alexhultman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787420927; x=1788025727; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=k6Chbw1X6zrtg/x12ibUkDAEJumkRsEO2FsOBeoQXbI=; b=o00ari/KhVqr6ziJRJq7ioWihp/h5vuQGBPmvxB2nMoSAQl9rHu4km3bfG3+fq1HD9 9CoTDzyLuNn7KpxFfAUQLFjDXN2PxojFxPOVCHIE5Z6ap5PYTVi+Ou1lApfkwJBbNE07 pwajw7ynK+F3HWpKwyaK7H3hVzbq+rCGF8fohCJt7Y4UjFficLEjkR/mUFr8SWL3dZW7 7BLuw9tEErmOfAe4YKmTDR72/RVHVscwGhTezbz/5k2LmKSBERxMSOkTFuVqbG8z0+Bz cs2FZ7+I1sDbgdJjbjCmEaruqWLOXrjRjaT5AHz+WsOLCkDEkQ3UHZJro8e0GrxbvFnA 7hCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787420927; x=1788025727; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to:content-type; bh=k6Chbw1X6zrtg/x12ibUkDAEJumkRsEO2FsOBeoQXbI=; b=ZdrqCfpsaVdF3ox1pCuzL3gnZZOf4HLn4AReO5bhjBwxxMpCuPIaNXDAbY7uuomLCZ 8vPzbrSDETsZll+eKmn8IHTBgSGxomQMbrZxk4nV2xCb5tnZKSb4R+mn3hej8EBeNX65 RUQR/XhiVJUfw16w3vT4i+hLEPC7rfKK5SORGAu+7hPX4DqSph6962wYKjFHUm9jqrqt MEjMtQX1G+Bxbkal2jkLEHiyHpbI6wCWyX5JVPWWqbqMcTryFwxTDr1Z55C0ZTMoMyVr oCHNOlq/bVi3t6V7tL1t+M392dG0ruiOS5os9IlaX6awBinaU0OQ9ImnuayA8ON3Kr7N MhtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787420927; x=1788025727; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=k6Chbw1X6zrtg/x12ibUkDAEJumkRsEO2FsOBeoQXbI=; b=HvNc/NKSEJ9ptphVF2vaWuq13XI7kPaX3A5PKIsqm4Mj/tVtS5rjf0ffYmOMtrMeOt NGlOcK0pH7NBmMaPhVnpPJYJuZiIqPfpyc/QYXmodvQ0dfzbfFJ6eLzJeqS1m1xRe0UT SeNkOYKRlYpoy2+D/7qY4KHISRvd+Gd0ybEsdmfKIH/RloaZvpFH+aQWLWezL5EdMOVo IWAR64m3ZfAMxFIIDWOIn/zNvcoJYbd96RYsUMN4H9hbsSPnU90OD6ujWv51cSlnfArM hNNkWUnV9L7MAQIrIJlimzF/5h62SXrGU+ej1rZElwTePTfkCaRFRJYhVlQv70pHBwf+ gj/A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+RoJaj5AuZp9OjXeTKRGPqm5FDA6ajaA/4XS26jjSTInO+7QQ4kBsvMPZ+96NRdKW+abNz89NnkiOckw@gnusha.org X-Gm-Message-State: AFuF++mLfHQc0MMiEMfWX8W/EQpYCf8N3Hk8Y63inCQs9Y6Q2FOTAaWF VqVEykmwSZ1sAt5ILMLGxfAZjda+8RxrcGJbRYPk6z14fDIwWdgMPdnZ X-Received: by 2002:a05:6820:16ab:b0:6b1:51f3:abf with SMTP id 006d021491bc7-6b151f3124fmr15809191eaf.15.1787420927196; Sat, 22 Aug 2026 10:48:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddXnv+Bx43BYAcSqCLqkAmhmVPCDIwBWobPXT1kmDMnJQ==" Received: by 2002:a05:6870:3912:b0:463:af61:d3e6 with SMTP id 586e51a60fabf-463af620368ls14153fac.0.-pod-prod-00-us-canary; Sat, 22 Aug 2026 10:48:41 -0700 (PDT) X-Received: by 2002:a05:6808:c1b8:b0:495:ca1b:7865 with SMTP id 5614622812f47-4b2cdcc4f55mr22671465b6e.11.1787420921024; Sat, 22 Aug 2026 10:48:41 -0700 (PDT) Received: by 2002:ab3:7a0c:0:b0:306:e47b:2a88 with SMTP id a1c4a302cd1d6-31123fa1925msc7a; Sat, 22 Aug 2026 10:46:59 -0700 (PDT) X-Received: by 2002:a05:651c:30ca:b0:39c:7d57:a3ae with SMTP id 38308e7fff4ca-3a1ae85d3f1mr35452241fa.0.1787420817956; Sat, 22 Aug 2026 10:46:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787420817; cv=pass; d=google.com; s=arc-20260327; b=Yb2ES6b9dNdiu+3w4FzMRyaHdIYn5r16HbPyJGJ+861KUxEInnKrq9o7bbQgu9qend esBXE5KJ/7HKpJOZ3OCyKAiTLgvLcVSHLsEbPiz+rbFAM0fvagbBBV42mKMVy33QNQsR Kj4L92RWNiX6Dap7EQVEPWwFUNSdHrdL7gq71T6aRdV6lv3Nt8Jt3JDa5lIY/EPgEAqq fTvWp92as6J3HM3Qr87ArThl6X7Mq7Cn18EwsuZWWgWMWh3Y4/MjQCxBsnZKALucfDtw 37/DYuMjNj+1hOpJhoIdBY9+/VwYoUMN597eXcw0IE/M3qoOXgSzgnl5cPOteX2NL2I0 xZEQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xs0TQ/jejnBRVnWdON3P8sD9B1ahslwmask2/Af9o4U=; fh=mzXEsTWDK6gnkBrY7ZCwwMohUIL8bXkfU2CQ462oZJ0=; b=AirFcqvMqvDGtYQxkRsyiUOt8Qxd5B1Ux2g2GQetanpL75uXBumgWJv60xMmMaBZt1 rBApsDQC36PbpScL1pySQK0As7EKPZr4/XIi3LCJSKQKy/imTdAhGqQcyUkzYY8yjY0I 64FsI6ZBmUqtgwmPokj6V843Ahd3Znz8h37vAuhQ4jIcHcSKRYPM0QybjBG33JbjINcH 3pSrY0EqkAeZCHynbtpEHcP4M+O77Os727zwrJbsToI/ROsp+RzQojXnzCELs8oV91uW yB9Rd7dawSWrbC3hrWzjhnBUODlXUjqmMmjEuQkfetDsCSeaCz2q9ADGaxL7VaEd+R+V pw4A==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=B9wLuqlk; arc=pass (i=1); spf=pass (google.com: domain of alexhultman@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=alexhultman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com. [2a00:1450:4864:20::12d]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3a1c2c5aae4si406321fa.4.2026.08.22.10.46.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Aug 2026 10:46:57 -0700 (PDT) Received-SPF: pass (google.com: domain of alexhultman@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) client-ip=2a00:1450:4864:20::12d; Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-5b011edaf7dso2294297e87.2 for ; Sat, 22 Aug 2026 10:46:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787420817; cv=none; d=google.com; s=arc-20260327; b=Zwe1cSBVwuNvZMfPUjz8u8+9coOdlpPHash+FaVW4wafBIrW6OMeQMjLd1pK9Zn30c crLIy77iwTBbeW5G6ADbuKYKJN4bxLxeg6mpuP4ewOSxPqqIfc4Q0pHs+SaCfjx5GpzR rLJmWp/5ld/BPrvzUNi+tNAS9n8IorQI/M0eVOSnJXgMpOrlCa8x0ozdCYQ+nNTWudkH ujP6jghC2cyoTI1MzvPooJvOwoSBx6YUtYWz2Z0eVedEFN2y3SFHquxnPK84seG3OWPN JSLl3YlwrCiXozItk+TsUxI61+1TXWTz6D/EdfnoNtY9qBzkWbN874ozWeCy7GfdM504 EBog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xs0TQ/jejnBRVnWdON3P8sD9B1ahslwmask2/Af9o4U=; fh=mzXEsTWDK6gnkBrY7ZCwwMohUIL8bXkfU2CQ462oZJ0=; b=Xloz6+Yqw/n6p7X0X8ZCerwlEuZyxGGKLAFDBCaLQP3DjbXj/2VP5D83RWp6an9iXT YMvu5Ivqdnh6aKo8MYXdnvsNS+t5wDSvdlLsXVkV+apKYlOXXySGojF7NNP5DjmAhDhH 29ti8lKsFzpdedKTxVkZtxqDSWjYexf6HJ0zbRjFXD39GOsLVjgZOepzY5Ez0eYWSx3n vGH2kvlhACOTiU3E5iuYjBA1LPEqQsNO0wPukkudm+M6q4FHjBtjCbdTy3DX9B1gN614 aOlmIDoQXtHPCZJFGyuLtpTAQjaMdJpm49ePiY9jVW1gRxbeop6S0NTNQR+r6JYNFa93 l1TQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AR+sD13aXT1uDEedsbUMAktP7Svpx4+w8Mgls1cQ8jUi5ZVa3jTvXcEBluYKNqvklOK 7Rl7jsBYJqOc9nER2Hg2JBOpJx6dD4w3ihKp6my+YHkXjtonrVBiuQlDvKGYzF9VmjTz663sEiH xqehvsNrKDnjPay2e5YzQ3kHTmCiX1BcSumZtgU7HY2Ra1ElYkgUej5RK47LuqM6O67qPVDP8B3 F/1q/s5OjgOMvSv6ju07HutzSgZDoU52O9ttuE0phP4ijRqMgPu2ubRWtlxMI3IMm1qWKbLHJt4 7ATsKv+hgTeahX1WqU6qSf9FeibuUAdtVaC/Pnnl0/nCHXvjU4ja7uhN+ce8qmnzEGPJaTj3HEA CeDnxvyfVw6FQN4sKjR8CQ0dXiwdGZEQ1pd/zhcI8qQ0Myd3mAqCN0alTS+R+ X-Received: by 2002:a2e:be9d:0:b0:39c:7200:b9b9 with SMTP id 38308e7fff4ca-3a1aec4cdd4mr36539721fa.13.1787420817039; Sat, 22 Aug 2026 10:46:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Date: Sat, 22 Aug 2026 19:46:44 +0200 X-Gm-Features: AcwNN1VOELq-9gJuGvpGSYBFNhSEPyWbO1aLtj-iMmGIenhxb1aX8eDo45-mEI8 Message-ID: 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?= To: conduition Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000dd259d0659a65660" X-Original-Sender: alexhultman@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=B9wLuqlk; arc=pass (i=1); spf=pass (google.com: domain of alexhultman@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=alexhultman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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.1 (/) --000000000000dd259d0659a65660 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am I correct in understanding that commit/reveal 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 Bitcoin itself, deployed, before any of commit/reveal can help, right? Den tors 20 aug. 2026 23:56'conduition' via Bitcoin Development Mailing List skrev: > Dearest friends, colleagues, and lurkers, > > I would like to present for your consideration a new commit/reveal 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 "DropKick" is self-descriptive of its usage: *Drop* a hidden > commitment somewhere on the blockchain, and reveal it later with an > SPV-style proof to *Kick* (spend) your legacy coins forward to a new > PQ-secure wallet. > > Background > > As with any post-quantum commit/reveal protocol, DropKick uses the > blockchain as a trustless timestamping service to prove than an honest us= er > had earlier chronological knowledge of some secret *witness* to a > quantum-hard* one-way function*. The honest user hides a *commitment* in > a block, waits 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 ke= pt > 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 > procrastinators can still authorize spending of their legacy UTXOs even > well after Q-day, provided the rescue protocol is deployed *before* Q-day > as a new encumbrance on affected legacy coins. > > DropKick In One Paragraph > > DropKick specifically is a commit/reveal protocol where the commitment H(= H(w, > Q), Q)=E2=80=8B is hidden somewhere in a block, such as an OP_RETURN or i= nside a > taproot 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 scrip= t pubkey (address) > encumbering a coin. We can later reveal the witness w=E2=80=8B and a sign= ature > from pubkey Q=E2=80=8B to authorize a spend, along with an *opening proof= * showing > that the commitment was included in a prior block. The verifier checks th= e > commitment opening is valid and sufficiently old, checks s =3D f(x)=E2=80= =8B, and > verifies the PQ-signature from Q=E2=80=8B. > > See this section for the actual proving/verifying steps of the protocol. > > > 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 > function would typically be a computational pipeline that includes hashin= g > of secret data unknown to a CRQC, such as "BIP32 hardened derivation of a= n > address" or "hashing a public key or script to build an address" or > "taproot key tweaking". DropKick can be instantiated with different one-w= ay > functions to encumber different coins. > > *Compatibility:* DropKick can be deployed as a soft-fork, as it only > *tightens* spending validation rules, and does so only on certain UTXOs. > > *Confiscation:* DropKick can be deployed *without* confiscating any > coins, if so desired, by deploying it as an encumbrance only on UTXOs wit= h > *decidable* 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 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 commitment opening proofs are included in= a *reveal > transaction* spending the legacy coins. Opening proofs could be attached > in an OP_RETURN 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 same size as SPV > > or OpenTimestamps 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 sa= me > 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 size of the proof. If one has txindex=3D1=E2=80=8B enabled, veri= fication > 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 func= tion f(w) > =E2=80=8B. > > *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 "aggregators" who *do= * have > PQ-safe UTXOs. These servers take it upon themselves to aggregate the > commitments of other users together into a merkle tree, whose root they > publish on-chain. Those aggregators can charge a salvage fee for their > services if desired, paid in-band from the rescued UTXOs, or up-front out= -of-band. 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 proposa= l > (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 > moment to compare and contrast DropKick and Lifeboat/Lifejacket. > > DropKick includes some novel features which Lifeboat does not, such as *k= ey > 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 will > mostly ignore these minor differences here. > > The fundamental difference between DropKick and Lifeboat is the commitmen= t > 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* the revealed > commitments later. Reveals reference this index to authorize spending:= Only > the earliest valid commitment for a given witness is allowed to spend > the legacy coin that witness unlocks. > - DropKick encourages procrastinators to *hide* commitments in merkle > 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 proo= fs to > convince validators that the commitment was included in a past block. = *Validators > therefore do not (and cannot) index all commitments, and so there is n= o way > to confirm any one commitment was earliest*. > > > By dropping the commitment ordering requirement, DropKick skips the need > for a new index database collecting all the commitments, and this frees u= s > from putting commitments on chain in-the-clear. DropKick commitments can = be > hidden off-chain, but anchored to the chain in merkle trees of arbitrary > size, which is the key feature that enables the new role of aggregators, > 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 m= iner > censorship attacks w= here > 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 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 proportional fee to > incentivize honest miners. We also have to assume no 51% reorg attacks of > course, as a malicious hashrate majority could easily censor any reveal > transactions and so steal coins. > > However, if this security loss is acceptable, DropKick offers a much > simpler 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, > 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 > 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. i= f > we 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 > derivation of these parameters > . > > Conclusion > > So that's it. > > 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 > reduce 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 it to validate reveal transactions without DoS risks. For > example, BIP32 master key derivation via BIP39 is not considered efficien= t > because it uses PBKDF2, whereas BIP32 CKD is efficient if restricted to a > maximum derivation depth. > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/ruufSzDPIml1W5hF-m_IJLeBzuhq= ey6CGe7-zT1WwY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61FaU_asfj39Ri1QgSXtz7-OekEt6b= bTvo%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/= CAHPaHkr5r4%2BhodZv6F2S1yCq_UcHSr2iCrkYLgZ_vryNgwbRPA%40mail.gmail.com. --000000000000dd259d0659a65660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Am I correct in understanding that commit/reveal always d= epends on someone else already having a valid PQC UTXO to spend?

So in other words, this can never be a s= olution for a (procrastinating Bitcoin system), only a solution for (procra= stinating Bitcoin users).=C2=A0

We need to have an already functioning PQC solution for Bitcoin i= tself, deployed, before any of commit/reveal can help, right?
Den tors 20 aug. 2026 23:56'conduition' via Bitcoin= Development Mailing List <bitcoindev@googlegroups.com> skrev:
Deares= t friends, colleagues, and lurkers,

I would like to present for your consideration a new com= mit/reveal rescue protocol to save the coins of quantum procrastinators - t= hose who take no action to move their coins to 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 later with an SPV-style proof to Kick=C2=A0(spend) you= r legacy coins forward to a new PQ-secure wallet.

Background

As with any post-quantum commit/reveal protocol, DropKick uses t= he blockchain as a trustless timestamping service to prove than an honest u= ser had earlier chronological knowledge of some secret witness=C2=A0= to a quantum-hard one-way function. The honest user hides a commi= tment in a block, waits for confirmations, and later reveals=C2= =A0her commitment to certify she knew the secret witness long before an adv= ersary (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 ho= nest bitcoin-holding procrastinator from a CRQC in many situations, and so = procrastinators can still authorize spending of their legacy UTXOs even wel= l after Q-day, provided the rescue protocol is deployed=C2=A0<= i>before=C2=A0Q-day as a new encumbrance on affected legacy coins.

DropKick I= n One Paragraph

DropKick specifically is a=C2=A0commit/reveal protocol where the comm= itment=C2=A0H(H(w, Q), Q)=E2=80=8B is hidden somewhere in a bl= ock, such as an OP_RETURN or inside a taproot tweak.=C2=A0Q=E2= =80=8B is a post-quantum public key, and w=E2=80=8B=C2=A0is th= e 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 witness w=E2=80=8B and a signature fr= om pubkey=C2=A0Q=E2=80=8B to authorize a spend, along with an = opening proof=C2=A0showing that the commitment was included in a pri= or block. The verifier checks the commitment opening is valid and sufficien= tly old, checks s =3D f(x)=E2=80=8B, and verifies the PQ-signa= ture from Q=E2=80=8B.


Features

= Generality:=C2=A0DropKick generalizes to any efficient [1]=C2= =A0one-way function based on knowledge asymmetries - things the honest user= knows which the 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 der= ivation of an address" or "hashing a public key or script to buil= d an address" or "taproot key tweaking". DropKick can be ins= tantiated with different one-way functions to encumber different coins.

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

Confiscatio= n: DropKick can be deployed without=C2=A0confiscating any coins,= if so desired, by deploying it as an encumbrance only on UTXOs with=C2=A0<= i>decidable=C2=A0knowledge 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=C2=A0kno= wledge asymmetries like BIP32-CKD. To be clear, P2PK=C2=A0coins cannot be c= overed by DropKick or indeed by any rescue protocol, as these UTXOs have no= known 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=C2=A0= spending the legacy coins. Opening proofs could be attached in an OP_RETURN= for backwards compatibility, or for better efficiency the proofs could be = attached in a new transaction witness field which would allow for the 4x se= gwit discount to apply. DropKick opening proofs are approximately the same = size as SPV or OpenTimestamps proofs (less than a kilobyte) and those pr= oofs 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=C2=A0txindex=3D1=E2=80=8B 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= witness w=E2=80=8B=C2=A0is exactly as efficient as evaluating= the one-way function f(w)=E2=80=8B.

Ergonomics:=C2=A0Procr= astinator do not need to have their own PQ-safe UTXOs available to e= xecute a DropKick rescue: Users can delegate their commitments to untrusted= third party servers called "aggregators" who do=C2=A0have= PQ-safe UTXOs. These servers take it upon themselves to aggregate the comm= itments 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= desired, paid in-band from the rescued UTXOs, or up-front=C2=A0out-= of-band.=C2=A0Procrastinators can shop between different aggregators, and a= nyone with 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 flexibili= ty, and better efficiency.

The two protocols fulfill functionally similar roles, so I will t= ake a moment to compare and contrast DropKick and Lifeboat/Lifejacket.

DropKick includes som= e novel features which Lifeboat does not, such as key certification = (allowing things like RBF, or equivocation, by the honest spender), or gene= ralization to arbitrary one-way functions. Such developments could be easil= y transferred to Lifeboat as well, so I will mostly ignore these minor diff= erences here.

Th= e fundamental difference between DropKick and Lifeboat is the commitment or= dering requirement.

  • Lifeboat requires procrastinators to (1) procure = a PQ-secure UTXO, and (2) upload a ~96-byte commitment in-the-clear in a ne= w transaction, such as in an OP_RETURN or inscription. Validators must inde= x all such commitments, so that they can chronologically order=C2=A0= the revealed commitments later. Reveals reference this index to authorize s= pending: Only the=C2=A0earliest valid commitment for a given witness is all= owed to spend the legacy coin that witness unlocks.
    • <= li style=3D"list-style-type:"- "">DropKick encourages procr= astinators to hide=C2=A0commitments in merkle trees committed into b= locks, such as via a merkle root posted in an OP_RETURN, or in a taproot-st= yle key tweak. Reveals use SPV-style proofs to convince validators that the= commitment was included in a past block. Validators therefore do not (a= nd cannot) index all commitments, and so there is no way to confirm any on= e commitment was earliest.

=
By dropping the commitment ordering requirement, DropKick skips the ne= ed for a new index database collecting all the commitments, and this frees = 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 arbitrar= y size, which is the key feature that enables the new role of aggregators, = and means procrastinators don't need PQ-UTXOs to publish a commitment a= nd rescue their legacy coins.

To gain these benefi= ts, DropKick sacrifices some security, by admitting=C2=A0mine= r censorship attacks=C2=A0where miners can intentionally censor a revea= l transaction to gain a chance to steal the procrastinator's coins. Lif= eboat entirely avoids this class of attacks, whereas DropKick requires a so= mewhat loose game-theoretical argument that mi= ners will converge on choosing not=C2=A0to censor reveals, provided = we enforce a long delay (days or weeks) between commitment and reveal steps= , and provided the procrastinator pays a proportional fee to incentivize ho= nest miners. We also have to assume no 51% reorg attacks of course, as a ma= licious hashrate majority could easily censor any reveal transactions and s= o steal coins.

However, if this security loss is a= cceptable, DropKick offers a much simpler and less complex engineering surf= ace area, and supports rescuing users in more diverse situations than LifeB= oat can (because PQ UTXOs are mandatory in Lifeboat).

<= div>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=C2=A0and reveal=C2=A0st= ages, and they pay only regular mining fees as usual. DropKick OTOH require= s a delay proportional to the fraction of the UTXO one is willing to sacrif= ice to miners. E.g. if we assume users are willing to sacrifice 1% of their= UTXOs, then we need to enforce a reveal delay period of at least 100 block= s. See here for a derivation of these parameter= s.=C2=A0

Conclusion

So that's it.=

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, o= r if we can at least reduce the strength of the assumptions needed for Drop= Kick to resist them.

regards,
conduition


[1]: The one-way function must be efficient=C2=A0so= that verifiers can recompute it to validate reveal transactions without Do= S risks. For example, BIP32 master key derivation via BIP39 is not consider= ed efficient because it uses PBKDF2, whereas BIP32 CKD is efficient if rest= ricted 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+unsubscribe@googlegroups.com.=
To view this discussion visit https://gr= oups.google.com/d/msgid/bitcoindev/ruufSzDPIml1W5hF-m_IJLeBzuhqey6CGe7-zT1W= wY4vlhVj_5NJTSalz43T4ZlZgXs3sDesW61FaU_asfj39Ri1QgSXtz7-OekEt6bbTvo%3D%40pr= oton.me.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAHPaHkr5r4%2BhodZv6F2S1yCq_UcHSr2iCrkYLgZ_vryNgwbRPA%40ma= il.gmail.com.
--000000000000dd259d0659a65660--