From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Erik Aronesty <erik@q32.com>
Cc: "garlonicon@gmail.com" <garlonicon@gmail.com>,
Ethan Heilman <eth3rs@gmail.com>,
Jonas Nick <jonasd.nick@gmail.com>,
bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
Date: Fri, 27 Feb 2026 19:31:16 +0000 [thread overview]
Message-ID: <xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c=@proton.me> (raw)
In-Reply-To: <CAJowKgL+YMWSgEPcVF-u8bNvPFK35cY-3cHtimWD2mtXdDhUzQ@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5423 bytes --]
> I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs. Be interested to see those solutions.
This is correct, but you don't actually need public-key tweaking to use an SLH-DSA pubkey as a backup for an ECC xpub. You can just append the SLH-DSA public key to a BIP32 xpub, and use the result to construct PQ-hybridized child addresses. For privacy we can attach a pseudorandom nonce derived from the chaincode, to prevent on-chain fingerprinting of unused BIP360 leaves. The resulting tap leaf hash looks random, and the SLH-DSA public key (and nonce) is only revealed if used for spending.
All this will be spec'd out as part of a non-consensus BIP, to help wallets build safe and robust quantum-resistant addresses.
> I provided an example script that shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destination in phase 0.
This pseudocode seems to commit the CTV hashes T & E in the anchor_script which is used to construct the funding UTXO. This is exactly the problem I mentioned which would prevent this technique from being usable as a PQ fallback script.
> txhash is a partial-commitment, not over all fields. this give the flexibility needed for the final spend, since you don't commit to it.
You've stated specifically in your post that TXHASH enforces that the `AnchorPublishTx` creates a UTXO paying to `P_anchor`.
> OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that] pins the next envelope (P_anchor)
You've also stated that `P_anchor` commits to the CTV template hashes `T` & `E`.
> P_anchor: Taproot output key committing to an Anchor script tree that ... enforces reveal-or-escape spending conditions
This statement is backed up by the pseudocode which depends on `T` and `E` when constructing `P_anchor`, as i pointed out earlier in this email.
Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV hashes `T` & `E`, yes?
Perhaps it would help if you mentioned which `TxFieldSelector` you are using, otherwise i'm just left to guess. The pseudocode is unclear.
regards,
conduition
On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <erik@q32.com> wrote:
> >
> >
> > I'd be excited to learn about this as an option. Erik, could you please answer my previous questions about the viability of your linked protocol? I'm not questioning its quantum-resistance properties (yet). I'm wondering how it is possible to instantiate this scheme in a way that allows a wallet to actually use this commit/reveal scheme without knowing the final destination CTV templates (denoted T & E in the delving post) in advance of creating the phase 0 locking script.
>
>
> I provided an example script that shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destination in phase 0.
>
> txhash is a partial-commitment, not over all fields. this give the flexibility needed for the final spend, since you don't commit to it.
>
> however someone has pointed out a fee-problem that CCV's value-aware composability can solve. coming around to thinking the ccv-based construction would be necessary. CCV is more powerful but requires much more care in policy and analysis. CTV is trivial, we could merge it tomorrow and hardly worry about surface area issues. TXHASH is only slightly more complicated. CCV has a much bigger burden of proof around implementation and node safety... but i think you could do many kinds of vaulting schemes with it alone.
>
>
>
> > But in the case of hash-based signature (HBS) schemes, i disagree. HBS is already mature. Whatever cryptanalytic breakthroughs the future holds, we can be reasonably sure that SHA256 preimage resistance will hold for a long time, so HBS security will hold. Even today md4 and md5 preimage resistance still holds. Securing coins using hashes alone is the ideal fallback, and even if HBS is not the most efficient class of schemes, that doesn't matter so much if we don't use HBS as our primary everyday signature scheme. Its value lies in security, not efficiency.
>
>
> When I mean "too soon", I'm including SPHINCS, not sure what
> 1. Earlier versions of the SPHINCS framework were found to be susceptible to fault attacks
> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of security, not 128
> > If you're worried about stuff like how xpubs would work with HBS, we have solutions for that too, and they are mostly drop-in replacements for existing standards.
>
> I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs. Be interested to see those solutions. But, regardless, 17kb sigs are... not compatible with a decentralized bitcoin, imo. Lattice-sigs are the only reasonable PQ way forward and they aren't ready yet.
--
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/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 11036 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-02-27 21:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
2026-02-20 1:41 ` Alex
2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-26 15:51 ` Matt Corallo
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List [this message]
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-03-01 21:28 ` Alex
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
2026-02-12 19:20 ` Matt Corallo
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
2026-02-15 12:12 ` Matt Corallo
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=erik@q32.com \
--cc=eth3rs@gmail.com \
--cc=garlonicon@gmail.com \
--cc=jonasd.nick@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox