You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -30,27 +30,33 @@ This document is licensed under the 3-clause BSD license.
30
30
31
31
Motivation for making Bitcoin quantum resistant is given in [https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki BIP-360]
32
32
33
-
===Rationale===
33
+
===Design===
34
34
35
-
Based on these design principles in [https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki BIP-0360]. In this BIP we enable tapscript programs to verify two Post-Quantum (PQ) signature algorithms, ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+).
36
-
We choose to use the SHA-256 variant of SLH-DSA rather than the SHA-3 variant as dedicated SHA-256 instructions make it far more performant on mobile devices.
35
+
In this BIP we enable tapscript programs to verify two Post-Quantum (PQ) signature algorithms, ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+) via the addition of four new opcodes.
36
+
For each signature algorithm we define two new opcodes, an OP_CHECKSIG equivalent and an OP_CHECKSIGADD equivalent.
37
+
These opcodes preserve the behavior of OP_CHECKSIG and OP_CHECKSIGADD opcodes applied to a new PQ signature algorithm.
38
+
We define four new opcodes: OP_CHECKSIG_SLH, OP_CHECKSIGADD_SLH, OP_CHECKSIG_ML, and OP_CHECKSIGADD_ML.
37
39
38
-
The addition of PQ signatures to tapscript used in tandem with [https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki BIP-0360] provides Bitcoin
39
-
transactions that fully resist quantum attacks.
40
-
Additionally PQ signature opcodes can be used in P2TR outputs.
41
-
However PQ signature opcodes in P2TR outputs would only provide quantum resistance if the key-spend paths will be disabled in P2TR.
40
+
These opcodes will only be available in tapscript and can be used with P2TSH (Pay-to-Tapscript-Hash), P2TR (Pay-to-Taproot) and any future Tapscript supporting output types.
41
+
When used in tandem with P2TSH (Pay-to-Tapscript-Hash) [https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki BIP-0360], this enables Bitcoin transactions that fully resist quantum attacks.
42
+
This includes both short-exposure and long-exposure attacks.
43
+
These opcodes can be used in P2TR outputs, however they would not provide quantum resistance due to P2TR key-spend paths being vulnerable to quantum attacks.
44
+
If at some point in the future P2TR key-spend paths were to be disabled, then these opcodes enable P2TR to also provide quantum resistance.
42
45
43
-
Consider the P2QRH or P2TR output with three tapscripts:
46
+
=== Rationale ===
44
47
45
-
* Spend requires a Schnorr signature
46
-
* Spend requires a ML-DSA signature
47
-
* Spend requires a SLH-DSA signature
48
+
We used the following principles to guide our rationale and design decisions:
48
49
49
-
One intent in supporting Schnorr, ML-DSA, and SLH-DSA in tapscript is to allow parties to construct outputs such that funds are still secure even if two of the three signature algorithms are completely broken.
50
-
In the event that Schnorr signatures are broken, users can spend their coins using ML-DSA.
51
-
If both Schnorr and ML-DSA are broken, the user can still rely on SLH-DSA.
52
-
This is motivated by the use case of securely storing Bitcoins in a cold wallet for very long periods of time (50 to 100 years).
50
+
'''Minimize changes.''' We should reuse existing Bitcoin code and preserve existing software behavior, workflows, user expectations and compatibility whenever possible.
51
+
52
+
'''Use standardized post-quantum signature algorithms.''' Standardized algorithms have undergone the most scrutiny and are likely to be most well supported and well studied going forward. The entire Bitcoin ecosystem will benefit
53
+
from using the most popular post-quantum signature algorithms, including leveraging hardware acceleration instructions, commodity trusted hardware, software libraries and cryptography research.
53
54
55
+
'''Provide security against unexpected cryptanalytic breakthroughs.''' Consider the risk if Bitcoin only supported one PQ signature algorithm, and then following the widespread rollout of CRQCs, a critical
56
+
weakness is unexpectedly discovered in this signature algorithm.
57
+
There would be no safe algorithm available.
58
+
We believe that prudence dictates we take such risks seriously and ensure that Bitcoin always has at least two secure signature algorithms built on orthogonal cryptographic assumptions. In the event one algorithm is broken, an alternative will be available. An added benefit
59
+
is that parties seeking to securely store Bitcoin over decades can lock their coins under multiple algorithms, ensuring their coins will not be stolen even in the face of a catastrophic break in one of those signature algorithms.
54
60
55
61
==== Algorithm Choice ====
56
62
@@ -59,6 +65,7 @@ Of these three algorithms, SLH-DSA has the largest signature size, but is the mo
59
65
Both FN-DSA and ML-DSA signatures are significantly smaller than SLH-DSA signatures but are based on newer lattice-based cryptography.
60
66
Since ML-DSA and FN-DSA are both similar lattice-based designs, we choose to only support one of them as the additional value in diversity of cryptographic assumptions would be marginal. It should be noted that ML-DSA and FN-DSA do rely on different lattice assumptions and it may be that case that a break in one algorithm's assumptions would not necessarily
61
67
break the assumptions used by the other algorithm.
68
+
We choose to use the SHA-256 variant of SLH-DSA rather than the SHA-3 variant as dedicated SHA-256 instructions make it far more performant on mobile devices.
62
69
63
70
We also considered SQIsign.
64
71
While it outperforms the three other PQ signature algorithms by having the smallest signatures,
@@ -71,6 +78,21 @@ SLH-DSA has a radically different design and set of cryptographic assumptions th
71
78
P2TSH, ML-DSA, and SLH-DSA could be activated simultaneously in a single soft fork or P2TSH could be activated first and then ML-DSA and SLH-DSA could be independently activated.
72
79
If at some future point another signature algorithm was desired it could follow this pattern.
73
80
81
+
==== Multi-Algorithm Security ====
82
+
83
+
Consider the P2TSH or P2TR output with three tapscripts:
84
+
85
+
* Spend requires a Schnorr signature
86
+
* Spend requires a ML-DSA signature
87
+
* Spend requires a SLH-DSA signature
88
+
89
+
One intent in supporting Schnorr, ML-DSA, and SLH-DSA in tapscript is to allow parties to construct outputs such that funds are still secure even if two of the three signature algorithms are completely broken.
90
+
In the event that Schnorr signatures are broken, users can spend their coins using ML-DSA.
91
+
If both Schnorr and ML-DSA are broken, the user can still rely on SLH-DSA.
92
+
This is motivated by the use case of securely storing Bitcoins in a cold wallet for very long periods of time (50 to 100 years).
93
+
94
+
==== Activation ====
95
+
74
96
We consider two different paths for activating PQ signatures in Bitcoin. The first approach is to redefine OP_SUCCESSx opcodes for each signature algorithm.
75
97
For ML-DSA this would give us OP_CHECKSIG_ML and OP_CHECKSIGADD_ML.
76
98
The second approach is to use a new tapleaf version that changes the OP_CHECKSIG opcodes to support the new PQ signature algorithms.
@@ -90,8 +112,6 @@ In the OP_SUCCESSx case, the increased size limit would only be in effect for tr
90
112
Otherwise this stack element size limit increase would be a soft fork.
91
113
If the tapleaf version is used, then the stack element size limit increase would apply to any tapscript program with the new tapleaf version.
92
114
93
-
94
-
95
115
==== Raising tapscript's stack element size ====
96
116
97
117
A problem faced by any attempt to add PQ signatures to tapscript is that the stack elements in tapscript can not be larger than 520 bytes because the MAX_SCRIPT_ELEMENT_SIZE=520. This is programmatic because PQ signature algorithms often have signatures and
@@ -115,7 +135,6 @@ Note this change to OP_DUP is not consensus critical and does not require any so
115
135
As OP_DUP isn’t the only opcode which duplicates stack elements, we would also need to extend this to all opcodes that duplicate stack elements.
116
136
The opcodes which must have a limitation added are: OP_DUP, OP_2DUP, OP_3DUP, OP_DUPIF, OP_TUCK and OP_OVER, OP_2OVER, OP_PICK, and OP_TUCK.
117
137
118
-
119
138
==== Public keys larger than 520 bytes ====
120
139
121
140
Turning our attention to public keys larger than 520 bytes.
1. OP_PUSHDATA HASH256(expected_pubkey) updates the stack to [HASH256(expected_pubkey), pubkey||signature]
139
-
2. OP_CHECKMLSIGVERIFY pops HASH256(expected_pubkey) and pubkey||signature, checks HASH256(expected_pubkey) == pubkey and verifies signature against pubkey.
158
+
2. OP_CHECKSIG_ML pops HASH256(expected_pubkey) and pubkey||signature, checks HASH256(expected_pubkey) == pubkey and verifies signature against pubkey.
140
159
141
160
This approach has four benefits: First, it does not necessitate altering OP_PUSHBYTES so that it can push objects larger than 520 bytes onto the stack.
142
161
This allows us not to have to reason about any complex consequences of such a change. Second, it allows the large public keys used by ML-DSA to make use of the witness discount.
@@ -146,13 +165,14 @@ To explain this third benefit, let's look at an example. Consider a 1-of-3 multi
146
165
If we commit to the entire public key in the tapscript, the script contains three 520 byte public keys despite only needing to verify one public key.
147
166
If we commit only to the 32-byte hash of the public key, we would only need to include three 32-byte hashes, and then only include the single 520-byte public key in the witness input stack.
0 commit comments