Bitcoin developers should learn homologous cryptography (Part 2)

Author: condution

Source: https://conduition.io/cryptography/isogenies-intro/

Translator: Kurt Pan

The original article was published in March 2026.

See the previous article here.

Old Techniques, New Cryptography

While we could spend a lot of time exploring the inner workings of SQIsign, PRISM, and SIDH, as well as the underlying mathematical proofs of homologous cryptography, this is not necessary for the core argument of this article. Remember: I am trying to argue that Bitcoin enthusiasts should learn and invest resources in homologous cryptography. Let's get down to business.

Now we have some understanding of how same-origin key pairs and signature schemes work; we've seen how to attack them and how to prove their security. We know the basic rules.

We can finally discuss how same-originating systems can replace the classic ECC technique commonly used in Bitcoin.

Re-randomized public keys

Perhaps surprisingly, many of the high-level cryptographic constructs used in the Bitcoin ecosystem can be abstracted into a simpler building block called a " re-randomized public-key scheme," which can be instantiated using the IBC scheme (and there are already such cases).

A re-randomized public-key scheme is a public-key cryptosystem, and we have the following algorithms:

• $\text{KeyGen}(sk) \to pk$ generates a key pair.
• $\text{RerandomizePublic}(pk, r) \to pk'$, where $r$ is a random salt.
• $\text{RerandomizeSecret}(sk, r) \to sk'$, where $r$ is a random salt.

For the correctness of a re-randomized public key scheme, given $pk = \text{KeyGen}(sk)$, we need:

$$\text{KeyGen}(\text{RerandomizeSecret}(sk, r)) = \text{RerandomizePublic}(pk, r)$$

In plain terms: the rerandomized private key must correctly correspond to the rerandomization of its public key.

Constructing a correct rerandomized public key scheme is straightforward. Simply define $\text{RerandomizeSecret}(sk, r)$ to output a random private key derived from $sk$ and $r$, and then define $\text{RerandomizePublic}(pk, r) := \text{KeyGen}(\text{RerandomizeSecret}(sk, r))$.

But this is clearly not secure. Any adversary who knows $pk$ and $r$ can re-derive the rerandomized private key and thus sign messages.

To achieve complete privacy and security, we also need the properties of unlinkability and unforgeability .

• "Unlinkability" means that the rerandomized key is indistinguishable from the independently generated random key unless you know the salt $r$ used to rerandomize the key.
• "Unforgeability" means that attackers cannot forge signatures for rerandomized public keys unless they also know the private key (which may itself have been rerandomized).

motivation

Re-randomization encapsulates the essence of many cryptographic techniques used in Bitcoin:

The versatility of this re-randomized public-key scheme leads us to conclude that as long as we can instantiate a correct, unlinkable, and unforgeable re-randomized system using a homologous system, we immediately have post-quantum successors for BIP32, BIP341 key adjustment, and (with some conditions) BIP352 silent payments.

Previous work

Classic ECC implementations (including in Bitcoin) typically instantiate rerandomization as follows:

• Let $G$ be the base point of an elliptic curve of prime order $n$.
• Construct a collision-resistant hash function $H_n: {0, 1}^* \to \mathbb{Z}_n$ that maps any input to an integer modulo $n$.
• Given $sk \leftarrow \mathbb{Z}_n$, define $\text{KeyGen}(sk) := sk \cdot G$
• Given $pk = \text{KeyGen}(sk)$ and
  • Define $\text{RerandomizeSecret}(sk, r) := sk + H_n(r)$
  • Define $\text{RerandomizePublic}(pk, r) := pk + H_n(r) \cdot G = (sk + H_n(r)) \cdot G$

While some work has been done on re-randomized keys in the context of post-quantum lattice cryptography, the technique has always been constrained by the inflexible structure of lattice-cryptographic public keys. Attempting to introduce structure for lattice-cryptographic key pairs seems to hinder the compactness of keys and signatures. For example, this recent paper (see also the accompanying blog post ) presents a re-randomized signature scheme and uses it for unenhanced BIP32 key derivation, but at the cost of a 16kb public key and a 20kb signature (more than 8 times larger than ML-DSA).

For lattice cryptography, key rerandomization also affects security, requiring us to impose usage restrictions:

Note 2. While the Raccoon-G construction allows for public key rerandomization, this increases key noise and alters the signature distribution. This affects the maximum depth at which the signature distribution can be argued to be indistinguishable, which is part of the unlinkability argument. A “hybrid” approach could be considered, which limits the number of non-enhanced derivations for each public key generated with $\text{DetKeyGen}$.

Homologous rerandomization

We can use homology to achieve efficient and secure post-quantum rerandomization.

Let $\varphi: E_0 \to E$ be a secret homology that maps from the underlying curve $E_0$ to the public key curve $E$.

Let $\mathcal{H}(E, r)$ be a hash function that returns a uniformly random homogeneous source with $E$ as its domain (the input curve).

To rerandomize the public key curve $E$ without knowing the private key—given a random salt $r$, we derive a homologous $\psi = \mathcal{H}(E, r)$ that will $E \to E'$, and use the codomain (output) curve $E'$ as the updated public key. Quite simple. In fact, SQIsign does almost exactly this in its Fiat-Shamir transformation for signatures and verifications, each time it generates a challenging homologous $\phi_{\text{chl}}$.

Re-randomizing the same-source private key $\varphi$ is more subtle. Given a salt $r$, we can re-derive the same-source $\psi = \mathcal{H}(E, r)$. Because we know the automorphic ring $\text{End}(E)$ of the public key and the same-source $\psi: E \to E'$, we can compute $\text{End}(E')$. Meanwhile, by common sense we know $\text{End}(E_0)$, and we can now find a secret same-source $\varphi': E_0 \to E'$, which is our new private key.

A useful general fact about homology: If you know a homology path from any curve $E_1$ to any other curve $E_n$, even if that path involves many intermediate homology paths between other curves $E_2, E_3, E_4, \ldots$, it is relatively easy to compute a new concise homology path directly from $E_1$ to $E_n$, as long as you know the self-homomorphic cycle of at least one curve on the path (not necessarily the first or last curve).

More specifically:

• Definition $\text{KeyGen}(\varphi) := \text{Codomain}(\varphi)$
• Define $\text{RerandomizePublic}(E, r)$:
  • Calculate $\psi = \mathcal{H}(E, r): E \to E'$
  • Return $E' = \text{Codomain}(\psi)$
• Define $\text{RerandomizeSecret}(\varphi, r)$:
  • Calculate $E = \text{KeyGen}(\varphi)$
  • Calculate $\text{End}(E_0)$ using $\text{End}(E)$ and $\varphi$.
  • Calculate $\psi = \mathcal{H}(E, r): E \to E'$
  • Calculate $\text{End}(E)$ using $\text{End}(E')$ and $\psi$.
  • Using $\text{End}(E_0)$ and $\text{End}(E')$, calculate $\varphi': E_0 \to E'$
  • Return $\varphi'$

The correctness is easy to see. The public key generated by rerandomizing $\varphi$ is the same as the curve $E'$ found by rerandomizing the original public key $E$.

$$\text{KeyGen}(\text{RerandomizeSecret}(\varphi, r)) = \text{RerandomizePublic}(E, r)$$

nature

The $\text{ReRandomizePublic}$ algorithm based on common origins is fast and easier to implement because we only need to generate a pseudo-random common origin and compute the rest of the domain, a known task with readily available and efficient algorithms. Technically, we don't even need to find the common origin.

$\text{ReRandomizeSecret}$ is more complex and computationally expensive, but it is still ultimately polynomial-time. I don't know the actual speed, but based on the performance of SQIsign, it's likely in the millisecond range.

Security

This technique has been described in several papers, such as this one (page 3) and this one (directed same source only, page 10), although always in a cryptographic context rather than in a signature scheme. However, the concept also applies to signature keys.

Proving unlinkability requires proving that the update curve $E'$ resulting from $RerandomizePublic}(E, r)$ is indistinguishable from a uniformly random distribution of a supersingular elliptic curve. Details begin to become more important, such as the degree of homology used. While I am not a cryptographer, I believe this is an easy proof if we use the facts of supersingular homology graph theory. SQIsign has already proven a similar fact regarding the distribution of the challenge curve. Proving unforgeability will depend on the signature scheme you choose.

Nevertheless, given the novelty of this technology and its relative rarity in the literature, there is still work to be done to prove its security before it can be relied upon in the real world. The lack of a usable implementation means we cannot evaluate its performance. All of this is open work for the future.

Example

For example, imagine we live in a world where the SQIsign and/or PRISM verification algorithms have been standardized in Bitcoin consensus.

BIP32 HD Wallet

Deterministic hierarchical (HD) wallets can function as they do today, deriving a single master secret homologous $\varphi_m: E_0 \to E_m$ and mainchain code $cc_m$ from a human-readable seed:

$$(\varphi_m, cc_m) = H(\text{seed})$$

Strengthened subkeys can be derived by rerandomizing the master key, using $cc_m$, sub-index $i$, and the private key itself as salts, such as CKDpriv in BIP32.

$$(r, cc_i') = H(\varphi_m, cc_m, i)$$

$$\varphi_i' = \text{RerandomizeSecret}(\varphi_m, r)$$

Unenhanced subkeys can be derived by rerandomizing the master key, using $cc_m$, subindex $i$, and the public key as salts, such as CKDpub for BIP32.

$$(r, cc_i) = H(E_m, cc_m, i)$$

$$\varphi_i = \text{RerandomizeSecret}(\varphi_m, r)$$

An observer possessing the extended public key $(E_m, cc_m)$ can derive a non-enhanced sub-public key:

$$(r, cc_i) = H(E_m, cc_m, i)$$

$$E_i = \text{RerandomizePublic}(E_m, r)$$

The result is a near-complete direct replacement for the classic BIP32 HD wallet, which should have quantum security at the cost of slower key derivation.

BIP341 Key Adjustment

Someday in the future, if we have more confidence in same-origin cryptography, we could consider an upgrade that hides the same-origin commitment to the script tree in the raw public key output, much like how Taproot works today.

The raw public key published on-chain will be an elliptic curve $E^\prime$ (approximately 66 bytes). To anyone observing $E^\prime$ on-chain, it appears randomly chosen and opaque. The key holder can execute key path spending by publishing a signature verified under $E^\prime$: PRISM, SQIsign, or any scheme standardized at the time.

Alternatively, the consumer could choose not to disclose the raw signature, but instead reveal the second curve $E$ (which I will specifically call the internal key ) and a Merkle root $m$, making

$$E' = \text{RerandomizePublic}(E, m)$$

The Merkle root $m$ can now be used to prove that the UTXO also commits to certain previously hidden cost conditions, such as time locks, multisignature, or restrictive clause scripts—the so-called script path cost . All of this is very similar to how the BIP341 Taproot address works today.

However, there are some complexities. Currently, there is no equivalent based on homology to replace certain Taproot addresses used to disable the "Nothing-Up-My-Sleeve" (NUMS) point for key path costs. To date, no one has found a transparent algorithm to generate hypersingular elliptic curves—i.e., NUMS curves —with unknown autosomal rings.

Proofreader's Note: The literal meaning of "Nothing-Up-My-Sleeve" is a magician showing their sleeve to the audience before performing a magic trick to prove they are not hiding anything. In cryptography, it takes the meaning of "not hiding anything": a value is generated transparently, not carefully constructed for some ulterior motive. For example, the BIP 341 Taproot cost verification rule defines a NUMS point (public key) whose x-coordinate is the uncompressed hash of the secp256k1 curve generator G.

If the parties involved can interact, they can run a multi-party protocol to generate NUMS curves , moving from an initial curve $E_0$ to a final curve $E_n$. Each $n$ participant contributes an intermediate homologous source $\phi_i: E_{i-1} \to E_i$, and—for security—provides a simple proof that they know $\phi_i$. Each participant promises to forget its homologous source $\phi_i$ after the ceremony.

Any honest agent who participates in the setup ceremony can be certain that the resulting curve is indeed uncostable because, as long as any participant honestly erases their contribution from the same source, there is no known path from $E_0$ to $E_n$, and therefore $\text{End}(E_n)$ is also unknown. However, this protocol requires all relevant parties to participate in the ceremony, even asynchronously, which can be cumbersome in practice.

The Bitcoin community could hold a Perpetual Powers-of-Tau ceremony , similar to the Ethereum community, to generate a continuously evolving set of semi-trusted NUMS curves, which would be periodically committed to the blockchain in a manner similar to OpenTimestamps. However, ideally, we would prefer a more transparent and reproducible solution.

Here is a 2024 paper that investigates various attempts to hash arbitrary inputs into random (NUMS) supersingular elliptic curves.

Silent payment

Silent payment works conceptually as follows:

• Bob posts a static , silent payment address containing the public key $B$ somewhere online (social media, GitHub, etc.).
• Alice sees $B$ and wants to send him the money without interacting with Bob.
• Alice has a UTXO at an address using the public key $A$.
• Knowing her private key $a$, Alice uses the Diffie-Hellman key exchange between her key and Bob's key to compute a shared key $ss$.
• Alice rerandomizes Bob's public key $B' = \text{RerandomizePublic}(B, ss)$ and sends the coins to $B'$.
• Bob scans the blockchain with brute force to find payments to his silent payment address, calculating a shared key for each transaction that might be a silent payment.
• Ultimately, Bob tests Alice's transaction, calculates the same shared key $ss$, and finds that its derived key $B' = \text{RerandomizePublic}(B, ss)$ matches one of the outputs in Alice's transaction.

While it's conceptually possible to achieve this effect using a common source, it's far more difficult than other examples we've seen. As we've seen, the rerandomization part is possible, but agreeing on a shared key while preserving the privacy of both parties is very challenging.

There are indeed many secure key exchange protocols in the IBC world—see CSIDH , POKE , QFESTA , etc.—but none of these key exchanges are directly compatible with SQIsign or PRISM public keys.

To agree on the randomization key controlled by Bob, Alice and Bob must exchange information. Bob begins the conversation by conveying his silent payment address. This happens off-chain, so it can be almost anything we want, and can be quite large within reasonable limits—as long as it fits into a QR code. For example, this could be a 66-byte PRISM public key plus a 64-byte CSIDH-512 public key, totaling 130 bytes.

Alice can easily calculate the shared key after seeing Bob's CSIDH key because CSIDH key exchange is non-interactive. But how does Alice convey her CSIDH public key to Bob? Without it, Bob cannot calculate the shared key or recognize Alice's payments.

Alice could attach her 64-byte CSIDH public key on-chain in her payment transactions to Bob, for example, via OP_RETURN or an inscribed envelope. However, this is detrimental to the privacy of both parties, as on-chain observers could now heuristically identify Alice's payments as silent payment transactions—even though they cannot prove that Bob is the recipient.

Alice could send her CSIDH public key off-chain to Bob, but if Alice can communicate with Bob off-chain, why not just ask Bob for a new address of her own choosing? This would also jeopardize Alice's network layer privacy—Alice might prefer not to connect to Bob over the internet for fear that Bob would track her down by IP address.

In an ideal world, there should be a way to create hybrid key pairs that simultaneously encode a valid key exchange public key and a valid signature public key. Such systems do exist; there are signature schemes that interoperate with CSIDH keys , but these schemes are generally poorly performing, producing signatures much larger than SQIsign and PRISM. A cutting-edge paper here might help bridge this gap . Alternatively, perhaps there's a way for Alice to embed a CSIDH public key in her signature that only Bob can extract. So far, this problem remains elusive.

Another issue is performance. For the system to function fully, Bob must be able to scan every candidate transaction in every block to identify payments. Much optimization has been done on the CSIDH key exchange , but it still takes tens to hundreds of milliseconds per execution, depending on the hardware. This isn't a big deal for the sender, Alice—she only needs to run the key exchange once—but Bob might need to repeat this key exchange thousands of times to identify payments unless the sender provides him with some additional hints.

shortcoming

I would be naive to deny the limitations of existing IBC technology.

First and foremost, its verification performance is not very good. Although there have been significant improvements in recent years, SQIsign's verification algorithm still requires considerable computational power; even optimized code takes more than a millisecond to verify a single signature. This can be mitigated to some extent by parallelization, but it remains the Achilles' heel of cryptography.

Another point worth noting is that SQIsign signatures are malleable:

Please note that SQIsign does not aim for strong unforgeability. In fact, given a valid signature on a message, a second, different valid signature on the same message can be efficiently generated by manipulating the auxiliary isogeny. Replacing the auxiliary isogeny with any other isogeny of the same degree will produce a valid signature. The auxiliary isogeny's role in the signature is merely to enable the response to be represented in a two-dimensional way, but it does not contribute to the security of the protocol. In other words, the two-dimensional representation is not unique in itself: given such a representation, it is easy to find different representations of the same isogeny in most cases. Therefore, SQIsign cannot achieve strong unforgeability.

— SQIsign NIST submission document , page 93

I believe the same applies to PRISM, as PRISM signatures also use a two-dimensional homologous representation to achieve compactness.

However, this should not affect Layer 2 protocols such as the Lightning Network, because nowadays the signature is only included in the witness data and does not affect the calculation of TXID.

While I have been praising the promise of IBC cryptographic flexibility, one thing still missing from the IBC landscape is a compact multisignature scheme. Although some same-origin-based multisignature schemes exist, such as CSI-SharK , they are far less space-efficient than SQIsign and PRISM.

As mentioned earlier, generating a valid NUMS public key in a homogeneous environment seems difficult. We can perform a multi-party setup ceremony, but it would be much easier to simply hash the NUMS hypersingular curve, just as we find the NUMS curve points by hashing today.

Finally, we must acknowledge the learning curve of IBC. Compared to more fundamental concepts like hash-based signatures, homologous cryptography presents a very high barrier to entry for non-mathematicians. I myself am an experienced cryptography developer and engineer, but for the past few months, I've struggled to understand IBC due to a lack of the necessary mathematical background. In comparison, hash-based signatures are a piece of cake.

This problem seems to stem from a lack of beginner-friendly educational resources. Most of the information I found was in academic papers and hour-long video PowerPoint presentations.

in conclusion

Much of the information about homologous cryptography remains hidden in the ivory tower of mathematical academia. I hope this article can provide a more accessible and intuitive window into this world.

To any professional researchers of homology who are reading this: I sincerely apologize if I have inadvertently omitted any inaccuracies. To avoid being too verbose, I have left some things unsaid. Please contact me to correct any serious errors! I would be happy to discuss this with you.

Now that we've seen what homologous cryptography can do, I hope you understand why I titled this article this way. If you care about the future of Bitcoin after the advent of large-scale quantum computers, you should at least dedicate some of your resources to learning which systems might one day replace classical ECC, and I believe homologous cryptography is ahead of the competition here.

To be more specific, my argument is:

• Bitcoin businesses that rely on classical ECC properties should invest in researching how to replace these properties with quantum-safe alternatives. Can you homogenize it?
• Bitcoin developers should learn about homologous cryptography so that they can one day write secure software that uses homologous cryptography.
• Bitcoin layer-2 protocol engineers should think further ahead. Don't spend years building ECC-based protocols only to have quantum computers destroy them all within a decade or two. Build something that at least has a chance of outliving you.
• Bitcoin Core developers should consider what cryptography they want to use as the foundation for long-term scaling and expressiveness of on-chain spending after ECC's demise. As many readers know, I like SLH-DSA and think it's a good backup and stopgap measure, but we can do better in the long run.
• Bitcoin venture capitalists should consider the future of the companies they fund. Startups founded in the coming years may be the first generation of unlisted Bitcoin companies directly impacted by quantum computing, or at least among the first to be severely hampered by quantum FUD. If a CEO doesn't have a credible plan for dealing with quantum computing, you should be skeptical.
• Bitcoin custodians such as Coinbase, Fidelity, Gemini, and Anchorage should fund research into secure post-quantum alternatives to their complex offline and multi-signature custody models. If a CRQC holder decides to launch an attack on Bitcoin, these companies' wallets will be the highest priority targets. They suffer the greatest losses and have the strongest incentive to invest in building scalable post-quantum secure wallets.
• Bitcoin users should be salivating over the possibility that we could be an efficient alternative to classical ECC. We can retain most of the good things we've gotten used to over the years, at a cost that's negligible compared to the billions of dollars spent on quantum computing R&D.

As a freelance Bitcoin researcher focused on alternatives to classic ECC, I know this might sound like I'm asking for lunch, but I'm not necessarily talking about myself or my work. Of course, feel free to contact me if you're interested.

I'm talking about human intellect and the money that motivates so many intelligent people to focus their efforts. The Bitcoin industry today is a force to be reckoned with, and while the community may be fragmented, our collective resources are immense. If we mobilize these resources and apply pressure where leverage is most effective, I am fully confident that Bitcoin can and will survive the upcoming cryptanalysis breakthrough.

It is well known that those who invest in new and powerful technologies early on take the greatest risks but also reap the greatest rewards.

Other information about the same origin

• https://arxiv.org/pdf/1711.04062
• https://www.pdmi.ras.ru/~lowdimma/BSD/Silverman-Arithmetic_of_EC.pdf
• https://www.math.auckland.ac.nz/~sgal018/crypto-book/ch25.pdf
• https://ocw.mit.edu/courses/18-783-elliptic-curves-fall-2025/mit18_783_f25_lec04.pdf
• https://troll.iis.sinica.edu.tw/ecc24/slides/1-02-intro-isog.pdf
• https://math.mit.edu/classes/18.783/2019/LectureNotes5.pdf
• [ https://cs-uob.github.io/COMSM0042/assets/pdf/Isogeny-based%20Cryptography_Advanced%20Cryptology.pdf] ( https://cs-uob.github.io/COMSM0042/assets/pdf/Isogeny-based Cryptography_Advanced Cryptology.pdf)
• https://eprint.iacr.org/2023/671.pdf
• https://eprint.iacr.org/2024/1071.pdf

(over)