Post Quantum transaction signature (PQTS) Breakout #17

Agenda

Meeting Time: Wednesday, October 28, 2026 at 14:00 UTC (60 minutes)

GitHub Issue

Meeting Summary:

The meeting focused on choosing default parameters for the post-quantum transaction signature scheme, specifically Sphinx, for use in Ethereum. Antonio opened with a brief update on the launch of a primitive testnet version 03 on Daisugi, which demonstrated a static proof of 20 transaction signatures using a version of Sphinx. Tom presented the Sphinx art website, which allows users to explore trade-offs between signature lifetime, shape, hash function, and few-time signature types, and he explained the implications of pruning for privacy and performance on constrained devices. Matteo Vena and Alessandro from Project 11 presented their own parameter sets, emphasizing the need for compatibility with hardware wallets and MPC, and they argued that a smaller signature lifetime, such as 2^24, would be sufficient and more practical for constrained hardware. The group discussed the trade-offs between signature lifetime, size, and verification speed, with Nico and Daniel from Circle providing input on the practicalities of key rotation for high-volume signers. The participants generally converged on using the Sphinx art parameters as a baseline, while the specific choice of signature lifetime remained the primary open point of discussion.

Click to expand detailed summary

Antonio led the Post Quantum Transaction Signature meeting on October 28th, focusing on selecting default parameters for Linux Sphinx. He announced the launch of a testnet version 03 on Daisugi, which includes a simple version of EAP8288 and supports static proofs of 20 transaction signatures using Sphinx. The current testnet lacks traffic, but tools from PandaOrg will be implemented to generate more transactions for better benchmarking.

Tom presented a website called things.art that helps explore trade-offs when choosing parameters for LSPHINX, covering topics like signature lifetime, Sphinx shape, and hash options. He explained two novelties: a forest of WOTS+ scheme submitted to the SICOF competition by Jonas Nick from Blockstream, which offers 30% better performance than comparable schemes but requires new security analysis, and pruning techniques that can improve key generation speed but may compromise privacy. Tom also discussed privacy concerns with pruning and proposed partial solutions, including using a semi-trusted state to allow up to 2,000 fully private signatures on a ledger while maintaining reasonable performance.

Matteo Vena presented two parameter sets for constrained hardware solutions, focusing on maintaining compatibility with existing systems and optimizing for performance in MPC and hardware wallet contexts. The first set was based on previous work, while the second set aimed for better compatibility with proposals like sphincs.art, incorporating features like force. Both sets aim to balance verification requirements, size, and lifetime while supporting constrained devices. The discussion included questions about state size and permutation handling in sphincs.art, with clarification that it uses worst-case permutations.

The team discussed parameters for implementing SPHINCS+ signatures in the testnet, focusing on lifetime values and performance considerations. While there was general agreement on using the SPHINCS+ parameters presented by Matteo Vena, the specific lifetime value remained open for discussion, with options ranging from 2^24 to 2^32. Key concerns included hardware wallet performance limitations and the need for key rotation, with Daniel from Circle confirming that automated systems could handle rotation efficiently. The team agreed to finalize the lifetime parameter offline and aim to implement the chosen parameters in the next testnet version within two weeks.

Next Steps:

  • Tom: Add a new toggle for a lifetime of 2^24 to the sphinx.art website to show the resulting parameters and trade-offs.
  • Daniel: Investigate internally at Circle how they would implement key rotation and report back to the group.
  • Antonio: Include the proposed Sphinx.art parameters (similar to Matteo’s version 2) in the next testnet upgrade, with the lifetime to be finalized offline.
  • The group: Finalize the decision on the signature lifetime offline, considering the trade-offs between MPC/hardware wallet performance, user experience, and alignment with other ecosystems like Bitcoin.

Recording Access:

YouTube recording available: https://youtu.be/oFDXXviYdXA