From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: opus lux <opusluxofficial@proton.me>
Cc: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP] P2WOTS: 64 Slot Winternitz UTXO's (witness version three)
Date: Tue, 09 Jun 2026 00:41:47 +0000 [thread overview]
Message-ID: <_dsqh_xK1dtHYHls7SoJ0A-9XA8Nn78wSz2f4XewzAs3SKdt-YpNxK8tjlEBdjHqfY48JQ7SabS59AtY9ti8bQrLPxGoxLb48CfjbxTU2v8=@proton.me> (raw)
In-Reply-To: <3fqrs3Vli-C23u7QSQM9h4xVBaow5h_I5YfiVyCY3ij5qMKKYgQ3gcYmhf1Fd1TIHRypfEquAOwkWfn6q-wBvOdzcJ1XfYMP0oduByPl-So=@proton.me>
[-- Attachment #1.1.1: Type: text/plain, Size: 4509 bytes --]
> Including replies from Murch
...where he dipped out after accusing you of being a bot. Your delving thread OP even seems to include your LLM's thinking output 😂
In any case, this proposal is strictly worse than BIP360:
- It doesn't offer any flexibility with respect to gradual migration. The complete absence of usable EC spending paths would ensure absolutely nobody will migrate to it before Q-day, which is the whole goal of introduce a PQ address format today.
- The lack of scripting capability means Bitcoin would lose all the benefits of script after Q-day: no more lightning, no ARK, no DLCs, timelocks, covenants, etc.
- Where did the number 64 came from? What makes you think 64 signatures is enough? Or not too much?
- The proposal uses 256-bit hash functions, which is drastically overkill and results in signatures over 1 kilobyte. They could be much smaller if you use modern hash-based cryptography with tweaked hash functions as in SPHINCS.
- The proposal offers no solution for signers who need to create more than 64 signatures, or signers who cannot reliably track state.
- The "specification" is full of off-by-one typos, especially in security-critical array-indexing operators.
- You represent the 6-bit key index with a 32-byte witness element??
- The hash functions in the signing and verification algorithms appear to be different, so the scheme is probably not even correct, let alone sound.
- Many variables are not defined or explained.
- "Nobody watching the UTXO set knows: How many slots the tree contains..." Really? nobody knows how many slots there are? Even though the number of slots is a fixed constant?
If there is a human reading this reply, I recommend you first start by exploring the literature on hash-based cryptography before attempting to create a BIP for it. If you want to use AI to generate stuff cool, you do you, but make sure you can at least verify its output is reasonable.
regards,
conduition
On Monday, June 8th, 2026 at 7:21 PM, 'opus lux' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> To clarify, this proposal has been under active discussion on Delving Bitcoin for several weeks prior to this mailing list post. Including replies from Murch:
>
> https://delvingbitcoin.org/t/p2wots-post-quantum-utxo-winternitz-signatures/2530
>
> A live signet with full P2WOTS support is live for testing and a wallet demo can be interacted with from my website. I will resubmit the BIP pull request once sufficient mailing list discussion has taken place here as well.
>
> https://block_opuslux.ar.io
>
> Happy to answer any technical questions!
>
> Regards,
> Opus Lux
>
> On Monday, June 8th, 2026 at 4:07 PM, opus lux <opusluxofficial@proton.me> wrote:
>
> > Hi all,
> > I's like to officially propose P2WOTS (Pay-to-Winternitz-One-Time-Signature), a new native Bitcoin output type using witness version three. It provides post quantum security using only SHA-256 and contains no elliptic curve key material anywhere.
> >
> > The 34 byte scriptPubKey commits to a Merkle Key Tree over 64 independent WOTS+ one time key pairs.
> > This construction directly solves the WOTS+ one time signing limitation, each spend consumes a fresh independent slot key, making address reuse safe without ever violating the one time property.
> >
> > BIP draft PR:
> > https://github.com/bitcoin/bips/pull/2194
> >
> > Looking forward to technical feedback from the community.
> >
> > Regards,
> > Opus Lux
>
> --
> 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/3fqrs3Vli-C23u7QSQM9h4xVBaow5h_I5YfiVyCY3ij5qMKKYgQ3gcYmhf1Fd1TIHRypfEquAOwkWfn6q-wBvOdzcJ1XfYMP0oduByPl-So%3D%40proton.me.
--
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/_dsqh_xK1dtHYHls7SoJ0A-9XA8Nn78wSz2f4XewzAs3SKdt-YpNxK8tjlEBdjHqfY48JQ7SabS59AtY9ti8bQrLPxGoxLb48CfjbxTU2v8%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 8606 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 --]
prev parent reply other threads:[~2026-06-09 0:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 22:07 [bitcoindev] [BIP] P2WOTS: 64 Slot Winternitz UTXO's (witness version three) 'opus lux' via Bitcoin Development Mailing List
2026-06-08 22:20 ` Nagaev Boris
2026-06-08 23:01 ` [bitcoindev] " 'opus lux' via Bitcoin Development Mailing List
2026-06-09 0:41 ` 'conduition' via Bitcoin Development Mailing List [this message]
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='_dsqh_xK1dtHYHls7SoJ0A-9XA8Nn78wSz2f4XewzAs3SKdt-YpNxK8tjlEBdjHqfY48JQ7SabS59AtY9ti8bQrLPxGoxLb48CfjbxTU2v8=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=opusluxofficial@proton.me \
/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