Adding a different signature algorithm

[Sukrim]

After reading https://ripple.com/dev-blog/curves-with-a-twist/ I wonder if something like this is also on the mid-term agenda for Bitcoin, since especially the issue with ECDSA (weak RNGs on Android) even already has affected its users.

Yes, I know, I know, for some people Ripple is a red flag - please don't discuss this here though, please focus on the better performance + security aspects of using Ed25519 signatures instead of ECDSA.

[1714001624]

1714001624

[1714001624]

1714001624

[1714001624]

1714001624

[1714001624]

1714001624

[DeathAndTaxes]

The only known issue with ECDSA is implementation issues which result from the reuse of the k value.  This can be eliminated by using Deterministic Signatures (RFC6979).   The article shows roughly 2x throughput which sounds impressive until you realize how little times is spent verifying signatures.   For the sake of argument I will just accept their numbers as fact.   Secp256k1 performed 6609.64744 verifications per second.  If all Bitcoin blocks were 1MB and the average tx was 300 bytes that is 3,333 tx per block.  Verification of signatures would be ~500ms.  Using their own numbers, Ed25519 would be roughly half that or 250ms per block.

Technically Bitcoin can support an alternative signing algorithm (potentially multiple signing algorithms used simultaneously) but I don't see a move from one good 256 bit ECC curve to another 256 bit ECC being warranted.

[Sukrim]

Fast signatures are definitely more of an issue for Ripple, as transaction volume is higher there as well as "block" times. Still Bitcoin hopefully will get beyond 1 MB blocks in the future, so it might become relevant in the future. Also a delay of 500 ms vs. 250 ms when forwarding blocks might be worth a look or two.