From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 18 Aug 2026 16:20:02 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwT69-0001QD-VM for bitcoindev@gnusha.org; Tue, 18 Aug 2026 16:20:02 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-448d5182870sf634566fac.1 for ; Tue, 18 Aug 2026 16:20:01 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1787095196; cv=pass; d=google.com; s=arc-20260327; b=LpVk0v2qm4e4xnFJGVZmLQ/VgqQ0OWAynvGaszayEtNTSNkHlLXUCifQ8Xn0UZnLdm h8T2FFQV90hBo2oR+ERk9LhrK28J+h2cfH1wXfGSi/Uq63bkrUrPEmabrHu2U+VNgCYU qN/U0mFXZCQF2qUC9v5gRe59oJXgMsRDdGuAqtri2e8cdHX44/sggernZENiIl3CVSy0 ybmitF8P7e5tEBOORZJPtUa/7Ginw3KAWPV2wEMotD3rCO7c3IfebSaUA/Rn8c+czKoN ukroWvBnT6nQblGMf6AbrLkHTcyiKSWzNOBQalL7lQkyhJ+V6AdWMA0xfYliIfHnunL1 e2FA== 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; bh=FW5EfdFP022mD/uNkah/s8EfvUJXepsfZ8MwQ9MCzZ8=; fh=5KgiqkUXzcnS+KLw0vPi1XVk35YU6FuVAz1Kzm2Fkwo=; b=I9dqnHmHhbPjXaWzqirGqurhFWlc/IgimpP/bUejBlvWXyOwL1Nn/IvLXZ1VXbpG4L KBKeFs7XsbBM8aB6HUaGNDMy8qlR+RIetpkTxjhP8MdiLha5prwM7r4mGdQ1Xo0RE5Mr VjwNkB4TUCN/YnvnZ71bz/rVKZ55hVoGkR0ROqsd6W5ybQE7ZhNEbYcZ+jywAMe48rAC a0LoddiofTw3ATaxwz1YIMm8GqwaamWZxiHLwSL1owwsD2MkA8uHzaIpPWihGtR8sSqS paH57VAEfffIjNwkQv7e2/Cw8r80Daq4GxPKqSdK5zAqtyqTrQtJCk1LNih2SiNxVy1e h9Cg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=DYCQztYp; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=q32.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787095196; x=1787699996; 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=FW5EfdFP022mD/uNkah/s8EfvUJXepsfZ8MwQ9MCzZ8=; b=CjC8DfRO3znsy7IIJvyNPYNlFzMexFBErx9seN51pycI/PR7P+7C4CzkaTHppuqoQq 3VPHqKe0Ss0vH2ys8r79SZuDTvA+cpkfy9j3Sl1ycD5gtVK1rPUBOVSYF1ARRcTmh/r7 vrCzBXNtY1T929Qp9YtyqmVG8IkOmOFjWg3eAiVBvzw1DmXx9OB8uWpkTWdPUDzDSNIo lbdVhJuIv7BcJgF4r0/6dsFGRagvMUvF+Ctaae8dhD4kAl7E7SfU/Bq7evJUQhnMTxiD 1CAS+xqnNUieAZDPjDaoBLjVii2oUcHXJUUmeegG4iyjQmHbsagIYLaNy5kgHMxSx4XB BdEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787095196; x=1787699996; 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=FW5EfdFP022mD/uNkah/s8EfvUJXepsfZ8MwQ9MCzZ8=; b=F3TcGECiU7AwmaU5Dljjwkqq9qzIMUWJRXarUo1yAwe6CFiBeL7LXxt7rBwzyjWunX 3igbNZGA6f8vvNTqMmPEzCVeqGWdCaPZZsIVxtKrTZZoIAAc+ar51Cm/I7rxLLy6kYXo oVXl9B7aeANGTv+GMBqCu3AQekXGMGX+SRvWH12UxxqBFGm3vfW4+lFEmLl/OM8KvCKr 7h2pzOElge69evHPXxIcUvVYJj6t85p9q+bjW1GNlHd5nrzyNYf+oksI6Q+xgf0xwbBS TbtkZfHuK/eYqPtLhSSV/EsQ1nzwH7TRMpvLtWD+x56eq9TdNCgm8r1WvbS1CgKUfv+f yPDA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+Rqr4ENQIJTYpI9W527g+5FkuxxzlKNFRM5mW9KMXpfCQA9hmEVmyRX2B740wptxbCTSM6axPM4zCJya@gnusha.org X-Gm-Message-State: AOJu0Yz5uX70DJWXWN8GaE4WSPwoyUY3jz0Y3jR3ziTuuX1x3n5+sJsN gFaWsy/dnwHHae4s5c+LODG8DnzIAbDTsyWr/3mI31rk2V/LBzZx3fqR X-Received: by 2002:a05:6871:e9:b0:441:419:1fea with SMTP id 586e51a60fabf-462f6cc279bmr806042fac.11.1787095195832; Tue, 18 Aug 2026 16:19:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfA/s142RJbVMTM7LmHwmYD3JKGgZYblxEYMTy9KbNQDQ==" Received: by 2002:a05:6871:5e94:b0:451:b668:486 with SMTP id 586e51a60fabf-45e5c083dcals6064262fac.1.-pod-prod-01-us; Tue, 18 Aug 2026 16:19:50 -0700 (PDT) X-Forwarded-Encrypted: i=3; AHgh+Rp+FgQmHUjvrKIHD8i/96c370dW/rPaEgGIJ/3wirky6FWXurbc+gT/ZA5bpfcXf8qAJWsXw4CJO2yk@googlegroups.com X-Received: by 2002:a05:6808:23cd:b0:492:3ed0:9073 with SMTP id 5614622812f47-4b2bc93da94mr212237b6e.4.1787095190375; Tue, 18 Aug 2026 16:19:50 -0700 (PDT) Received: by 2002:a05:600c:6d8b:b0:495:6266:d77a with SMTP id 5b1f17b1804b1-499a8208617ms5e9; Tue, 18 Aug 2026 16:04:41 -0700 (PDT) X-Forwarded-Encrypted: i=3; AHgh+RqQbN7JOJbGvX51tSsWSFBo8i0mjj2MbOsmaoyJMnB4RurSEPeCikvRZXc3tjf81lL3SwE/1M3aDXjN@googlegroups.com X-Received: by 2002:a05:600c:34d1:b0:499:49f3:77b1 with SMTP id 5b1f17b1804b1-499aa14a6a6mr7107425e9.3.1787094279241; Tue, 18 Aug 2026 16:04:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787094279; cv=pass; d=google.com; s=arc-20260327; b=pzso/qhOKXNz+glpuHgFYVfMR3TXg2/ljBTM5KkY+FUl2Lgf2k0Z1RPuF7M38CEU1E k0aFhAEo0KsCNjhTqWhv5tq7di0ovzcwGtyhlGlUhot0h69isFn1UMnWBMGjpapir85z pHIqRN5itXtbSNI1xmExKUspc4/wNSbreXOvOFqYchIYhjD2MbA3se1vQvaXZ+lqdgna Ol79pYy+iPgKkwnS8w3nJnOl1rYTTUoFsMdQSY9/Wx9ztizKbE+8IJwx3XcazsPj22bb UdkO8Lqe7B8nbu4iNiwT7c88y41X5LMsLtATIdl/JG4JqssrzUx5GM2r3OAfLBHfD4c8 4euQ== 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=c1D0T/1ZRkhM/ycZ39yF2mCCB/AD10KLUAb/YnV+QPM=; fh=168cj6eKd9Wx9S15DdN2DlHeubTDFIUH67367Csrt24=; b=Whhpc8xvlquB3IqUqGwai6/oyL1JfhNwijX8UNY27bO9gerMJx2CExj5huDiard2z2 Eq6/oGLHbr9z7Wiv11KFoN+uUSVLD+7OAHc5cXS71tLYQN74RF4IpKLgPuNkDJjGK6ZA wYGjtw+QVLmOJ7vfC2HhOosYOBNufx7CxPYRPmKSpjYckAGp24yQYIS8993HINv3ignr cLcPHQojVcrK6b4rwfK6LF09bOY/I4uJrXcirdiR5M1Zgd0naCDw3tPgHfs00lAy+5b5 1yPWxzTEvX0VgcgXBo7xJUs4/5L9qxeMsXpSzJK9dlIc8VGOsQVX5dBWjs/0P7ieoG/W qRWw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=DYCQztYp; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=q32.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com. [2a00:1450:4864:20::632]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-499a9e88942si24165e9.2.2026.08.18.16.04.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2026 16:04:39 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) client-ip=2a00:1450:4864:20::632; Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-c15e592da74so47368166b.1 for ; Tue, 18 Aug 2026 16:04:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787094279; cv=none; d=google.com; s=arc-20260327; b=Qnkh1pIXhBpN0zjmAH4YDxDo074wd0GFm0/WGUXWkmHYcxsVx/5igDgDBO0RkOcK61 9+vkSm37Letpc9ZlAo+DTft8gJZzNCoRX94fXkAGrG3iCmtovgQH642j7OtjCVh5gDes bKzaer+3f8whWghr/wS1ztksnado6CydCmOAjlxfuI3XzAKWJo9E8E2cPN3zpjtm3BUn /kJpZFKsx/zM/YIxPmHCWWr3lUVmnbPpMeDnGkKoLkyufYpgMRxsNwjwap++8CvZneZg bfl/lKFlNgqgCsP58r5DDNpdj9wNW31f4E7xbEwokaV9rawuUn//5JlVLeSVwdlvbf0Z tR5w== 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=c1D0T/1ZRkhM/ycZ39yF2mCCB/AD10KLUAb/YnV+QPM=; fh=168cj6eKd9Wx9S15DdN2DlHeubTDFIUH67367Csrt24=; b=J3JuB32AwL3sPhITzQvHC7/KxyGearNuQ6YzPHoSosMlL3mnjeWzzNjCfc+lZ5dGrS wSzcQ1V9Q/TEM2V6vbUtERSpf2dmw+Oe4Gwb1728ZytFG9Yr4M3SkLNiLMu6846AHo9D jZeTfAFydkEejlyMg7kRlZT1ptS6T9FRN8iVuwAtrDqmO+NR7q97qc/rADIuk7AViXQy YC+xeBOJV8l234nphceyOB1K1dGK/u2u1KLTgGCeNbPVYaBMR46EvPdX9TBW9Cthe1jq MJK3e8pKXZtMiTha6myyAoOpJx8RM9UlobXgvOU+auMSMT9XNIbXS8biuE1qZS20hXhC YZkQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AHgh+RpDzH7iFj7fEKzf554Iv5vr+prCc+dcajAf+lfY8XlnXiY18iOzM8zmO2/06wInawn3Zw0ai9EQSoVU@googlegroups.com X-Gm-Gg: AR+sD10nhfncPDBWVW3jjx1mDN7nUwwVPNjvuJ+azMHe9XX5SYOcDm40vnfswDSCHHP oyXjZF9p9Y+ODPQo796tumdv2fo5OYVdzZc9vdx7OqwMMfKB2blBDTlrMQaUZy756Cj8/3noW3H X/AvKSJjc+IMWuzC2RCwnQPjGmLNs9ttbTzT9yom3I2hRPVO65lCjiQKm8ANgKTuAKL02Rp3+rP xRX0g/xNC+XaFGckNW04flaPeya/jIilkKnzzuQoXoZ1wag/hYrfrPZ32e7rVy2U2eFYV4w2mCv HMlXWK0ALbNCaKaWi9KJXJpJa3NG8JDKBbQhqVb58WoTvu6k37CmDfAD1U0DEqHA7eILif6Bj6o lA1ze X-Received: by 2002:a17:907:ea6:b0:c21:3c4e:cb90 with SMTP id a640c23a62f3a-c23e81e31f5mr21388166b.0.1787094278318; Tue, 18 Aug 2026 16:04:38 -0700 (PDT) MIME-Version: 1.0 References: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> In-Reply-To: From: Erik Aronesty Date: Tue, 18 Aug 2026 16:04:25 -0700 X-Gm-Features: AcwNN1WIsnz-5Kb4qpaDqThF5m7ZF2jy3pUY1G282P-j49EoY2Jfabhw1u1wv6g Message-ID: Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) To: Pieter Wuille Cc: "waxwing/ AdamISZ" , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000a3adf706595a4fbf" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=DYCQztYp; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=q32.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: 2.3 (++) --000000000000a3adf706595a4fbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW: there is a very long thread about this here: https://groups.google.com/g/bitcoindev/c/d7o74e-teNo/m/lLKjufQZAgAJ On Tue, Aug 18, 2026 at 10:30=E2=80=AFAM Pieter Wuille wrote: > Hi all, > > I'm unconvinced the complexity of a 192-bit canary is worth it. Picking a > curve and a NUMS point on it are not hard, but very little of > libsecp256k1's code can be reused (even field arithmetic is optimized > specifically for the secp256k1 prime). A more generic implementation is > possible of course, but it's still a pretty big piece of engineering for > what is IMO very little gain. > > There is a pretty fundamental difference between a secp256k1 Tripwire and > a canary for weaker curves, in that the former isn't intended to be > predictive. Its purpose is setting a codified upper bound on when ECC > (within PQC output types) is expected to be disabled. While it's certainl= y > possible it's actually triggered by a cooperative CRQC, that's not how I > expect ECC disabling to happen (instead I expect a community > consensus-changing effort, effected through Miner Lockdown or otherwise). > The Tripwire just sets an unambiguous expectation that disabling is > intended by Q-day. > > I don't think the presence of a 192-bit canary changes this expectation > much. 192-bit ECDLP broken (or breakable) is certainly a legitimate reaso= n > for panic, but nothing prevents that information from being used at the > human layer without it needing to have been part of consensus rules. > > Relatedly, something I don't know is how "similar" a canary needs to be t= o > the real secp256k1 ECDLP for people to bother building/programming/runnin= g > a QC for it. This is of course a question that exists for secp256k1 itsel= f: > whether a *cooperative* entity with the capability of building a > secp256k1-ECDLP QRQC would bother doing so. But it's even more tenuous fo= r > weaker problems, if they're not so much weaker that they're trivial. This > makes me wonder about using a subgroup of a very related curve: for examp= le > y^2 =3D x^3 + 3 (mod 2^256-2^32-977) has a subgroup of order ~2^187.11, w= hich > would use all the same finite field arithmetic and almost the same > multiplication logic (only doubling is affected). Keeping the field modul= us > the same does mean the q-bit count is unaffected though, only the gate > count decreases (proportional to logarithm of group order). Like other > weaker-curve constructions, I don't think this is worth it, but want to > throw the idea out there. > > I also don't think optimizing for multi-target ECDLP adds much. My > understanding is that Shor's doesn't benefit from multiple targets? I'm n= ot > opposed to giving freedom of finding (m,x) such that H(m) =3D x*G, but I > don't see why that would encourage a cooperative CRQC to work on breaking > it. > > Regarding using the BIP-341 H itself as canary, I don't think that's a > problem if the ECDLP break proof is a Schnorr signature (as opposed to > revealing the DLP itself). But it also makes sense to be as conservative = as > possible here; it may make sense to make a selection of hash functions, > feed them all as much input as possible (the genesis block is a good idea= , > the existing generator G, maybe a block hash from a time when the > activation parameters are decided, or even a block hash when the block go= es > live as suggested by Tadge though that adds hash-to-curve logic to > consensus too), and then XOR (or hash) all hash results together. > > From a simplicity standpoint, I think just having a "a UTXO with > scriptPubKey X is spent" is ideal, because it reuses all existing block a= nd > transaction validation logic, and just adds a trivial trigger. It's not > compatible with any weaker curve construction of course, or with AJ's > H-dependent DLP proof which could enlist non-cooperative CRQC, but I don'= t > think that's worth complicating matters for. > > Cheers, > > -- > Pieter > > -- > 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/td8wPWxRVg0rQIdP41uibTvWuIoC= vGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384= Uink%3D%40wuille.net > . > --=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/= CAJowKg%2BE5YMaWopx7VhMmtMYJ93mYMsDzbdJgVoG%2BB4%3Da9KaNQ%40mail.gmail.com. --000000000000a3adf706595a4fbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW: there is a very long thread about this here:=C2=A0https://groups.google.com/g/bitcoindev/c/d7o74e-teNo/m/lLKjufQZAgAJ<= /div>
On Tue, Aug 18, 2026 at 10:30=E2=80=AFAM Pieter Wuille= <bitcoin-dev@wuille.net&g= t; wrote:
Hi all= ,

I'm unconvinced the complexity of a 192-bit canary is worth it. Picking= a curve and a NUMS point on it are not hard, but very little of libsecp256= k1's code can be reused (even field arithmetic is optimized specificall= y for the secp256k1 prime). A more generic implementation is possible of co= urse, but it's still a pretty big piece of engineering for what is IMO = very little gain.

There is a pretty fundamental difference between a secp256k1 Tripwire and a= canary for weaker curves, in that the former isn't intended to be pred= ictive. Its purpose is setting a codified upper bound on when ECC (within P= QC output types) is expected to be disabled. While it's certainly possi= ble it's actually triggered by a cooperative CRQC, that's not how I= expect ECC disabling to happen (instead I expect a community consensus-cha= nging effort, effected through Miner Lockdown or otherwise). The Tripwire j= ust sets an unambiguous expectation that disabling is intended by Q-day.
I don't think the presence of a 192-bit canary changes this expectation= much. 192-bit ECDLP broken (or breakable) is certainly a legitimate reason= for panic, but nothing prevents that information from being used at the hu= man layer without it needing to have been=C2=A0 part of consensus rules.
Relatedly, something I don't know is how "similar" a canary n= eeds to be to the real secp256k1 ECDLP for people to bother building/progra= mming/running a QC for it. This is of course a question that exists for sec= p256k1 itself: whether a *cooperative* entity with the capability of buildi= ng a secp256k1-ECDLP QRQC would bother doing so. But it's even more ten= uous for weaker problems, if they're not so much weaker that they'r= e trivial. This makes me wonder about using a subgroup of a very related cu= rve: for example y^2 =3D x^3 + 3 (mod 2^256-2^32-977) has a subgroup of ord= er ~2^187.11, which would use all the same finite field arithmetic and almo= st the same multiplication logic (only doubling is affected). Keeping the f= ield modulus the same does mean the q-bit count is unaffected though, only = the gate count decreases (proportional to logarithm of group order). Like o= ther weaker-curve constructions, I don't think this is worth it, but wa= nt to throw the idea out there.

I also don't think optimizing for multi-target ECDLP adds much. My unde= rstanding is that Shor's doesn't benefit from multiple targets? I&#= 39;m not opposed to giving freedom of finding (m,x) such that H(m) =3D x*G,= but I don't see why that would encourage a cooperative CRQC to work on= breaking it.

Regarding using the BIP-341 H itself as canary, I don't think that'= s a problem if the ECDLP break proof is a Schnorr signature (as opposed to = revealing the DLP itself). But it also makes sense to be as conservative as= possible here; it may make sense to make a selection of hash functions, fe= ed them all as much input as possible (the genesis block is a good idea, th= e existing generator G, maybe a block hash from a time when the activation = parameters are decided, or even a block hash when the block goes live as su= ggested by Tadge though that adds hash-to-curve logic to consensus too), an= d then XOR (or hash) all hash results together.

>From a simplicity standpoint, I think just having a "a UTXO with scrip= tPubKey X is spent" is ideal, because it reuses all existing block and= transaction validation logic, and just adds a trivial trigger. It's no= t compatible with any weaker curve construction of course, or with AJ's= H-dependent DLP proof which could enlist non-cooperative CRQC, but I don&#= 39;t think that's worth complicating matters for.

Cheers,

--
Pieter

--
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/msgid/bitcoindev/td8wPWx= RVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-= Vc2fsSoo-Qxfm8Lcnd384Uink%3D%40wuille.net.

--
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.co= m/d/msgid/bitcoindev/CAJowKg%2BE5YMaWopx7VhMmtMYJ93mYMsDzbdJgVoG%2BB4%3Da9K= aNQ%40mail.gmail.com.
--000000000000a3adf706595a4fbf--