From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 09:04:28 -0700 Received: from mail-qt1-f191.google.com ([209.85.160.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYQqR-0002tt-03 for bitcoindev@gnusha.org; Sat, 13 Jun 2026 09:04:28 -0700 Received: by mail-qt1-f191.google.com with SMTP id d75a77b69052e-51776d4355csf65890651cf.0 for ; Sat, 13 Jun 2026 09:04:26 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1781366657; cv=pass; d=google.com; s=arc-20240605; b=JNdlcbm7b5nGHE4iKur8RnguLSoQIPYBqWm+fbgqhGs6Rz0GAoSgobT0zL7J9qiHun 1LMqhNdoLG8whivoUuq29nu3WbfHPZ7AiCPje7wCE6B+nq7CJykkEDfQAMq4L1yqJeFH 73sw1DkETBAufnYyJdpxD4nFF8vBmoBA1FZicTLSRS92p0aFpldGDx44XTJ8d8odFaGX Eb7IKQAXBQEISf4jMfaexrhqnQuvCX+WaKg1xidpFk9STx5tmDTolSLLquz1DFzQYbkk Rq3TbD0EzdyjzfP10sBIIY/q+yDY7NsGQWUCqc+K29owDnmrHmI23uPCinCmyQ0pPeC1 ePLA== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; 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=Zk3Jrp1GbCXt1tnBfzmkEHcKbEccIwAlucQoagRQYLI=; fh=JZ8VgohXCZAP3m3sVQmWV1grCkkhOO/aY+0nZhcq9fg=; b=FMVnsKEzgzkqgr0dQ/xgtOzz0dthAzabPC2SpOu5tfjoHoje/oOFTsfX9GKp5M69AS /wEnfK3t2KeI9P+mSdmQYqzBEHy5ILzoiYHK4tInVPT3HaoJF0vlwbRmaKCvxj8GPPrj cWzJGc9cOBL7CofBl/PEhEZMWhq3c8zUnV9dq6i2+1P6gMD7WJB2vTofvOL626ehI2f6 tXlBP0ZqojymPu4BDbXM0w7dg7mShw6+kWqx9XnqC/nJl3R4XvVnhBTgtu+LMoOatwNu Phk220MJl0xBV+tLHudNBlrxDC9jF9lP9KAZWyUq0dqZ0lxXh2Omtk4OOKuzmrRJsHZB 6Lxg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=k0pNVK50; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::235 as permitted sender) smtp.mailfrom=saintwenhao@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=1781366657; x=1781971457; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Zk3Jrp1GbCXt1tnBfzmkEHcKbEccIwAlucQoagRQYLI=; b=BK5LoReCzQFXJN8KKKizo/0mmmaS1GYFpi83XZiix/j7rSFnS2g4S94lnAjSc4JY7a XV+Ww648hCrVzdCoFPiWcNrvHvrU2TNw5Vz5fA1yjzU0YXwqmfkItmh9p6IDVdHcYYy3 MqOiOdXTle+B7pAxiuW3r5cTUVkv3mwilG2Ytn3PBm/jwAh1J2S/UkVCXXxuEfzIVccK DYjwlzEpX6g1fQn8IguZAKk7Yx713E4mne54RXh9P86yKXeWL1BAsPf+qUf9zQYF1pQO OTarlJ/TBFZZyoX8cFoCHqR2AMeauPxiNkSLC3qJRGEV9IPKEjUv5v34jgweWK+IayTi XNKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781366657; x=1781971457; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zk3Jrp1GbCXt1tnBfzmkEHcKbEccIwAlucQoagRQYLI=; b=A0OuvMgzsM4rcrtUMHBLQxwMd0HtMClkswwy2ZGpTPIbOO9NGeqAIeNpdwirbIFaJG Ue5dxcFddrFdCYiWyiu/cLln9h4acofstE2na2X+So+9DkRbdr8LwI7xstLG9OP6lzmM KI2sByyl85yt85u6DrZhjqM2L/ATdcOLdt/+0sbmWEZ63KYspunkPqquS9cLwl8QezYg 9UwyxQMXSSelNgv/dqQ97KRCdSCxVgosryx8HquHwVA5mfyp6x6y6HVu0Ujop9hsQbD8 WLYc2Erg5gS0YQEdIjbxNN3RSNGA2oCQGms1jA21ASfcfD5wvCKfy5U4sX+OB/EW1to9 NxSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781366657; x=1781971457; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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; bh=Zk3Jrp1GbCXt1tnBfzmkEHcKbEccIwAlucQoagRQYLI=; b=jKicDv/NIpQdgcgqDL3Dvk+MMixeT+tFSpsSMNsexOnOByA4CNpl2+MmzkdGcSpS7E yRxcGX6um0In0tzA/1oxQJHFKVwhPcW+28MBdBYqc/O9ifgUP3FPk09Lqlf7UT5P6gTB yIvJaIz3ugrbZIfZUvupIV1Eig/43P5s3iexyyxutIZI5h43g4z0EOJ3XneQJ+L08iuX 6xQ9o4CYSraGwW/9w1xjc+LphhFLYWKET7BiV2V2AbeOYHW+jmBQNr02BSQSZ5Bd4EBF eUy5WliqsP6IeeMRNIihDnYc4kOSvaB876gBwQpCZps8C/fTLeOm3RQn60P5WZdyanmf g5Ew== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+ALr/TF7MbSia9JI2izQF8CAdq6DyudMWjUTOf9jpntcRJOPil85YjEQlYSPeeXdfmLzIouejmmZEn@gnusha.org X-Gm-Message-State: AOJu0YyntSUg11V1W9h3/zOvsaUvCk0kyrihLL8GDL+iJ1Um9OSHjmTa cfNUZBLGwR5mPjlaVjLm85S0XSW79snuIdcM1/NlZ02giRi0y6KZQ6Wn X-Received: by 2002:a05:622a:1391:b0:516:e0e7:6e42 with SMTP id d75a77b69052e-517fbcb186cmr104836061cf.13.1781366656714; Sat, 13 Jun 2026 09:04:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeWaiKglTQBgHQgOBeQOQkRvpFW3IWanLG6TeAhTWmYsQ==" Received: by 2002:a05:622a:6841:20b0:516:37f0:fd4d with SMTP id d75a77b69052e-517ea287327ls17965871cf.0.-pod-prod-00-us-canary; Sat, 13 Jun 2026 09:04:13 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ+uDRnRDLJtp9xqzyPnqdRRmwxl8+bDg+fZXFfo3dh4ZwtofDix34d1aSDXfHGa1prPnk0FxZo9zK/6@googlegroups.com X-Received: by 2002:a05:620a:486e:b0:915:9eb1:f08a with SMTP id af79cd13be357-91619e76bd7mr798324485a.18.1781366652913; Sat, 13 Jun 2026 09:04:12 -0700 (PDT) Received: by 2002:a7b:c00a:0:b0:488:963a:630a with SMTP id 5b1f17b1804b1-49089fed838ms5e9; Sun, 31 May 2026 01:15:04 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/wD0yLyMqNTlsyPUVM8j56fG9X72BVdh5m1xsNAk7mg8swGRIeBoeVG5brBzgYWnvGCy3W3DucxXEf@googlegroups.com X-Received: by 2002:a5d:48c4:0:b0:45e:9ea3:ce9a with SMTP id ffacd0b85a97d-45ef6af6cc6mr9144493f8f.8.1780215303020; Sun, 31 May 2026 01:15:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780215303; cv=pass; d=google.com; s=arc-20240605; b=hVMg7ZvSjUgv4BandkD/XK8IqDSvbLbfZ4kFchBVGGB46yBdHF21dKH07OFAPk8hcO kXLrTmGmYIhZVCVIX2dVHZEL6lh6GFSnHw6LSyt+s/QpaVfZie64SUph5Si+fsXI1q/Z izGLWzhldPD7wQ+LUN/fsuc5/MIBOmMUfnA7q9tycieM1sK0siZ0eCmLQithtV9/C+PK fe9h2VML5ArWKfptffRTqhFFZJRZEAqo802oB4mlJ8fJJstnUgYSQQ48/qfA5XuBCgTF 5maBbNoqTqRR072/PGJska9oPVuCJv6P1fPNVy6xrdT4BdxVXw2qAqFjqCG08at+doJi 2X8w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kZmZ+ND2XdafB8WSaSYETwoM3vUR2Anmq2BtBZrFV/w=; fh=rj/thuNGX6R6W2ZZNj1y9BM3YOykQlJaZUwX83liRV4=; b=j26VvzHxApZBFaPCcChj2Tm8GJrL8YibIhc5Ma0imuOHrDl6WZrOSBA3elLdqTg1UB sjpi5hYxJ67t3VZg6Hz1GP+fajs0i3vCSDds/QEpn3HG5ZBk2/VqFA5ADChqSWFHIf6r C83vntPaS0I1GnlFrk5z+Yx91kk5U/OugQuBW6Bf8UoEqFPGeE/WSVIC6yA6LmE/1eI3 bStdBBXZSfRRx87GEWQ/2sr/LJg6CcOEbcz0eYbk0fju4AJqmEYmvxuzZ4RnnAPxo9bE l+ZA8tGCfBkqD84ItbOAa2EtwdWfa05vdCMoBk8eNyOD2zA8/wFBHQuGSJ8+RKd6dkXr mcBQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=k0pNVK50; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::235 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com. [2a00:1450:4864:20::235]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-45ef355c969si115482f8f.3.2026.05.31.01.15.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 May 2026 01:15:03 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::235 as permitted sender) client-ip=2a00:1450:4864:20::235; Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-39666f49929so9477701fa.0 for ; Sun, 31 May 2026 01:15:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780215302; cv=none; d=google.com; s=arc-20240605; b=Zc+LxAwqlXFkCFwyzINIbaD0FdAiKqQNqCUcwJg7OZmcqHlcMh7r3n7fueme1tRvfC PtT8mUo+DQkcuKVy7KQwp1OnxlRsllSjMhTe1nD57ohiY62FkDpffA+QclgEipX8A96U DTETS/SSfNkkLCg0lRF588apVFwjG3wEVoF/gkAAIAgvKchXNNRPycx0+V4arlczD8nA /Qll9WEV4zITx1kAXzfYBBVWyZ4eKTSILU4JJKNf7PUwXSLpZBIJWDYELxk6VaQGQp7h AjPhLmhCSd7FTcEsWQu2G89QekwGddUBGr0N52qnhPJvx8DfhqIqVTU3TnAIZW4JwY4Y rMUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kZmZ+ND2XdafB8WSaSYETwoM3vUR2Anmq2BtBZrFV/w=; fh=rj/thuNGX6R6W2ZZNj1y9BM3YOykQlJaZUwX83liRV4=; b=CzfxwKY5CETLTzLD8A8iObxzIy7vt1HOkdwFbistM7rjSxcgZe0Q+pGQqKU+qjzYfg j/2ax5sDNqyngKDW/RY8TkgxSzNQv0+xwTUfr/0nURyyVD2ZRhJVJye5g+ycl56xekQf a5FQvFlXQS7tFwT0EG+XqZfRxhyZIdUHSFx9UlzCOidg5Pu1r77XuxVQMaPlaU7qnD28 gmTR/aLbWjJ6utA8B4G1oWNnK/zYAyuvJK+uagYHXv0DJE//3mxHGLmHCsFKpT0cKO01 c/ZXcOO1DbnJD/KJIBfgKl2H/MXQELs4z++/xw8jNB+B1mErkDrUkA+1pPGY0KRr8aa3 o/Fg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ+a+VHCJhFjsa8yKzoer5mxlUwiKazxfaAHW0udvjum30lQQphuQ049rOrP2l1BLBvz++G1kTt0K3Aw@googlegroups.com X-Gm-Gg: Acq92OHu/is2X7Y4i6KRcqsCrcrcqlfOiM/ez+0hffbRLTwIkoC8LM8aHrVTnyzH1yZ /6qD+yDe4mrmEgYBjKXAU+keuNxBLqGpPske8Fo2xi2FuaDesgaLNrNlnQOA9i23mFDMJQgXuC3 Iw0CfAq6/aX9eiGJKXikC23spJkKo082JUDsAHoGgm42dX95vrCfQmNmvaTTYTD7rkpOrNAy6o1 AqOELcsuc8vikPY5bgdTyX1zj9cUGIoiRnx9fb5/WIiACfOWXorqf5u55qYp3bhyZXha/kpWSYF fpFik3HZJgRbplf5ERK8aGe+mEtpFK3t7rVxydE4h3Nbmmzefw== X-Received: by 2002:a05:651c:88a:b0:396:7d24:26b5 with SMTP id 38308e7fff4ca-3967d242859mr3648121fa.17.1780215301893; Sun, 31 May 2026 01:15:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Saint Wenhao Date: Sun, 31 May 2026 10:14:50 +0200 X-Gm-Features: AVHnY4JqYC1uoeVa_rw8Y5W70FwArYWXAmwSRwo6eGdvuYdiYGepc6x3Nk2Mc1o Message-ID: Subject: Re: [bitcoindev] Weak Quantum Bounty Ceremony To: Nagaev Boris Cc: Erik Aronesty , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b17374065318acae" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=k0pNVK50; arc=pass (i=1); spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::235 as permitted sender) smtp.mailfrom=saintwenhao@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.0 (/) --000000000000b17374065318acae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Those not motivated by funds could publish a zero knowledge proof instead of moving the funds. I think at least some financial incentive is needed. It could be something like 10k satoshis, or more, just to have a non-dust anchor for the puzzle, where other people could attach more coins. For example: if you have a puzzle, where the creator cannot move the coins, without solving the puzzle, then it is still possible to increase the reward later, as long as coins are signed with proper sighashes. See: https://mempool.space/tx/8349df0753e80cce322322f1b76789e1d0fd6693aed2f4de4e= 49576423081ae7 In this case, the puzzle from bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx uses SIGHASH_ANYONECANPAY, and is grinded by the solver. And bc1q9nw84cph4dn2pw78pnaec68c82h7pxvv55cla8 is someone, who bumped the reward, by signing it with SIGHASH_NONE, so the signature is valid only in the context of the puzzle. > Or the whole scheme can be deployed to testnet or signet not to waste (or burn?) real coins. We also did it: mainnet: https://mempool.space/tx/aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be= 0c2e68c50b2801 testnet4: https://mempool.space/testnet4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6= 937080c2ca37b38671970e5 signet: https://mempool.space/signet/tx/5aa27f3639c2218ee710fee9830924a129098dca944= 46661f37cae79c4e76712 However, if you think, that test coins are not traded, then you are wrong. For example: https://altquick.com/exchange/market/BitcoinSignet I think, sooner or later, all test coins will be traded, and just handled like all other altcoins. To some extent, it can be prevented, by making next chains, and dropping previous ones, like it was between testnet3 and testnet4, but still: exchanges will list new coins faster, than Bitcoin Core will release a new version, where the support for some old test network will be dropped. Which means, that creating the puzzle will always have a cost. Because even if initially some test chain will be worth exactly zero, then it will gain non-zero value over time. And because even signet uses Proof of Work, then creating any puzzle will always require at least some computing power, even if it will be negligible, and doable on CPUs. > plausible deniable for the publisher It can be done, by using SIGHASH_ANYONECANPAY, which we also did in our mainnet puzzle. In this way, an unconfirmed transaction with low fees can be made, and published anywhere, using any channel. And then, other people can add more inputs, or bump the fees, by solving some low hanging fruits, and claiming the easiest puzzles. In this way, the creator has to only prepare a single input, and all outputs, and then, it can be extended by the rest of the community, and pushed on-chain by the first solver (which would also set the challenge in stone, and prove, that at least some outputs are solvable, and people know, how to claim them). niedz., 31 maj 2026 o 09:40 Nagaev Boris napisa=C5=82(a= ): > Hey Erik, > > The scheme is interesting! I want to add my two cents. > > Those not motivated by funds could publish a zero knowledge proof > instead of moving the funds. This means real funds are not even needed > in this case. Or the whole scheme can be deployed to testnet or signet > not to waste (or burn?) real coins. > > Also I would like to propose some properties which the publishing > scheme should have to maximize the effect: > > - anonymous for the publisher > - plausible deniable for the publisher > - uncensorable > > For the plausible deniability thing, imagine a researcher who has > access to a particular signature made by quantum computer and can > prove it, but then it will be clear who leaked it, because the > signature has a unique nonce. This is where ZK can help. But how to do > ZK onchain to get censorship resistance? Maybe some BitVM construction > may help. > > Using mainnet provides better censorship resistance than testnet or > signet - that is actually a good reason to use mainnet unless we come > up with a better approach. > > Best, > Boris > > On Sat, May 30, 2026 at 12:58=E2=80=AFPM Erik Aronesty wro= te: > > > > I have been thinking about a way to create publicly verifiable Bitcoin > outputs whose recovery is intentionally tied to breaking a weaker > cryptographic system. > > > > The goal is to create a "quantum bounty." The output would be spendable > by a valid secp256k1 private key, but the key would be generated in a > public ceremony and intentionally limited to 160 bits of entropy. Recover= y > would additionally be facilitated by publishing an encryption of the same > secret under a weaker elliptic curve system. > > > > The basic idea is that a group of independent participants runs a > distributed key generation ceremony. Each participant contributes a secre= t > share. The shares are combined into a single 160-bit scalar x. At no poin= t > is x reconstructed on any machine or revealed to any participant. > > > > From the same distributed shares, participants jointly derive: > > > > 1. A Bitcoin public key P =3D xG on secp256k1. > > 2. An encryption of x under a separate 160-bit elliptic curve system. > > > > The transcript contains all commitments, public contributions, > ciphertext contributions, and equality-of-discrete-log proofs needed to > verify that both constructions are derived from the same hidden scalar. > > > > The construction does not require SNARKs or any trusted setup. It > appears sufficient to use Pedersen-style commitments, ElGamal-style > encryption, and Chaum-Pedersen proofs showing consistency between > participant contributions across the two groups. > > > > After the transcript is finalized, participants destroy their secret > shares and temporary randomness. Assuming at least one participant behave= s > honestly and destroys their material, the scalar x is no longer known to > anyone. > > > > The final artifact consists of: > > > > * A Bitcoin public key P. > > * A weak-curve ciphertext C. > > * A complete public transcript proving that P and C were derived from > the same hidden scalar. > > > > Bitcoin can then be sent to the address corresponding to P. > > > > Anyone who can recover x from the weak cryptosystem can spend the > output. The effective security of the bounty is therefore determined by t= he > weaker curve rather than by the full secp256k1 discrete logarithm problem= . > > > > The intended purpose is to create a publicly auditable cryptographic > canary target. > > > > One question I have not fully resolved is whether there are cleaner > constructions for the recoverable encryption component than ElGamal-style > encryption, while still preserving simple transcript verification and > avoiding general-purpose zero-knowledge systems. > > > > -- > > 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/CAJowKgJVwmm%3Dh6AsO4zeGTmfd= K-RUQiDsMJkMRd6WZSo5FjeZg%40mail.gmail.com > . > > > > -- > Best regards, > Boris Nagaev > > -- > 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/CAFC_Vt7DLZEytF72Q0EVPeg6iED= 3qztMXs7aX6zBNBQ5%2B-ceXA%40mail.gmail.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/= CACgYNO%2BLNdfHhfsA0uek2frXO46Zc6SV8S7rO_XZLbqS1A5j6A%40mail.gmail.com. --000000000000b17374065318acae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Those not motivated by funds could publish a zero kno= wledge proof instead of moving the funds.

I think at least some fina= ncial incentive is needed. It could be something like 10k satoshis, or more= , just to have a non-dust anchor for the puzzle, where other people could a= ttach more coins. For example: if you have a puzzle, where the creator cann= ot move the coins, without solving the puzzle, then it is still possible to= increase the reward later, as long as coins are signed with proper sighash= es. See: https://mempool.space/tx/8349df0753e80c= ce322322f1b76789e1d0fd6693aed2f4de4e49576423081ae7

In this case,= the puzzle from bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83= ltjx uses SIGHASH_ANYONECANPAY, and is grinded by the solver. And bc1q9nw84= cph4dn2pw78pnaec68c82h7pxvv55cla8 is someone, who bumped the reward, by sig= ning it with SIGHASH_NONE, so the signature is valid only in the context of= the puzzle.

> Or the whole scheme can be deployed to testnet or = signet not to waste (or burn?) real coins.

We also did it:

ma= innet: https://mempool.space/tx/aba3c2ae442aa201= 50996ee68f9aa4da83b57a4312891078be0c2e68c50b2801
testnet4: https://mempool.space/testnet4/tx/cc159432ffb7= a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5
signet: https://mempool.space/signet/tx/5aa27f3639c2218e= e710fee9830924a129098dca94446661f37cae79c4e76712

However, if you= think, that test coins are not traded, then you are wrong. For example: https://altqui= ck.com/exchange/market/BitcoinSignet

I think, sooner or later, a= ll test coins will be traded, and just handled like all other altcoins. To = some extent, it can be prevented, by making next chains, and dropping previ= ous ones, like it was between testnet3 and testnet4, but still: exchanges w= ill list new coins faster, than Bitcoin Core will release a new version, wh= ere the support for some old test network will be dropped.

Which mea= ns, that creating the puzzle will always have a cost. Because even if initi= ally some test chain will be worth exactly zero, then it will gain non-zero= value over time. And because even signet uses Proof of Work, then creating= any puzzle will always require at least some computing power, even if it w= ill be negligible, and doable on CPUs.

> plausible deniable for t= he publisher

It can be done, by using SIGHASH_ANYONECANPAY, which we= also did in our mainnet puzzle. In this way, an unconfirmed transaction wi= th low fees can be made, and published anywhere, using any channel. And the= n, other people can add more inputs, or bump the fees, by solving some low = hanging fruits, and claiming the easiest puzzles. In this way, the creator = has to only prepare a single input, and all outputs, and then, it can be ex= tended by the rest of the community, and pushed on-chain by the first solve= r (which would also set the challenge in stone, and prove, that at least so= me outputs are solvable, and people know, how to claim them).

niedz., 31 maj 2026 o 09:40=C2=A0Nagaev Boris <bnagaev@gmail.com> napisa=C5=82(a):
Hey Erik,

The scheme is interesting! I want to add my two cents.

Those not motivated by funds could publish a zero knowledge proof
instead of moving the funds. This means real funds are not even needed
in this case. Or the whole scheme can be deployed to testnet or signet
not to waste (or burn?) real coins.

Also I would like to propose some properties which the publishing
scheme should have to maximize the effect:

=C2=A0- anonymous for the publisher
=C2=A0- plausible deniable for the publisher
=C2=A0- uncensorable

For the plausible deniability thing, imagine a researcher who has
access to a particular signature made by quantum computer and can
prove it, but then it will be clear who leaked it, because the
signature has a unique nonce. This is where ZK can help. But how to do
ZK onchain to get censorship resistance? Maybe some BitVM construction
may help.

Using mainnet provides better censorship resistance than testnet or
signet - that is actually a good reason to use mainnet unless we come
up with a better approach.

Best,
Boris

On Sat, May 30, 2026 at 12:58=E2=80=AFPM Erik Aronesty <erik@q32.com> wrote:
>
> I have been thinking about a way to create publicly verifiable Bitcoin= outputs whose recovery is intentionally tied to breaking a weaker cryptogr= aphic system.
>
> The goal is to create a "quantum bounty." The output would b= e spendable by a valid secp256k1 private key, but the key would be generate= d in a public ceremony and intentionally limited to 160 bits of entropy. Re= covery would additionally be facilitated by publishing an encryption of the= same secret under a weaker elliptic curve system.
>
> The basic idea is that a group of independent participants runs a dist= ributed key generation ceremony. Each participant contributes a secret shar= e. The shares are combined into a single 160-bit scalar x. At no point is x= reconstructed on any machine or revealed to any participant.
>
> From the same distributed shares, participants jointly derive:
>
> 1. A Bitcoin public key P =3D xG on secp256k1.
> 2. An encryption of x under a separate 160-bit elliptic curve system.<= br> >
> The transcript contains all commitments, public contributions, ciphert= ext contributions, and equality-of-discrete-log proofs needed to verify tha= t both constructions are derived from the same hidden scalar.
>
> The construction does not require SNARKs or any trusted setup. It appe= ars sufficient to use Pedersen-style commitments, ElGamal-style encryption,= and Chaum-Pedersen proofs showing consistency between participant contribu= tions across the two groups.
>
> After the transcript is finalized, participants destroy their secret s= hares and temporary randomness. Assuming at least one participant behaves h= onestly and destroys their material, the scalar x is no longer known to any= one.
>
> The final artifact consists of:
>
> * A Bitcoin public key P.
> * A weak-curve ciphertext C.
> * A complete public transcript proving that P and C were derived from = the same hidden scalar.
>
> Bitcoin can then be sent to the address corresponding to P.
>
> Anyone who can recover x from the weak cryptosystem can spend the outp= ut. The effective security of the bounty is therefore determined by the wea= ker curve rather than by the full secp256k1 discrete logarithm problem.
>
> The intended purpose is to create a publicly auditable cryptographic c= anary target.
>
> One question I have not fully resolved is whether there are cleaner co= nstructions for the recoverable encryption component than ElGamal-style enc= ryption, while still preserving simple transcript verification and avoiding= general-purpose zero-knowledge systems.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "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/CAJowKgJVwmm%3Dh6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg%4= 0mail.gmail.com.



--
Best regards,
Boris Nagaev

--
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://groups.google.com/d/ms= gid/bitcoindev/CAFC_Vt7DLZEytF72Q0EVPeg6iED3qztMXs7aX6zBNBQ5%2B-ceXA%40mail= .gmail.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/CACgYNO%2BLNdfHhfsA0uek2frXO46Zc6SV8S7rO_XZLbqS1A5j6A%40ma= il.gmail.com.
--000000000000b17374065318acae--