BitcoinCash/specification
1
Fork 0
Code Issues Pull Requests Releases Activity

Make sure the specification is less implementation specific

Browse Source
This commit is contained in:
TomZ
2021-02-24 22:08:18 +01:00
parent 022f960125
commit ce59a25e2e
8 changed files with 2 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/forks/2019-05-15-schnorr.md
+1 -1
View File
@@ -203,7 +203,7 @@ The advantage of re-using the same encoding (and potentially same keypairs) is t
* It may be possible eventually to remove ECDSA support (and thereby allow fully batched verification), without blocking any old coins.
There is a theoretical disadvantage in re-using keypairs.
In the case of a severe break in the ECDSA or Schnorr algorithm, all addresses may be vulnerable whether intended solely for Schnorr or ECDSA --- "the security of signing becomes as weak as the weakest algorithm".<sup>[ref](https://lists.bitcoinunlimited.info/pipermail/bch-dev/2018-December/000002.html)</sup>
In the case of a severe break in the ECDSA or Schnorr algorithm, all addresses may be vulnerable whether intended solely for Schnorr or ECDSA --- "the security of signing becomes as weak as the weakest algorithm".
For privacy reasons, it may be beneficial for wallet developers to coordinate a 'Schnorr activation day' where all wallets simultaneously switch to produce Schnorr signatures by default.