[bch-dev] Schnorr algorithm selection

[Mark Lundeberg]

Hi Tomas, by no means are you late, rather you're early! I just started
packaging it together mainly to get the ball rolling.

(this is the current link for anyone not aware:)
https://github.com/markblundeberg/bitcoincash.org/blob/schnorr/spec/schnorr-spec.md

You're absolutely right about one thing with the specified approach -- "the
security of signing becomes as weak as the weakest algorithm".

An alternative approach might be to override the first byte of public keys
(say, use 08 & 09 for compressed schnorr pubkeys) which would force
'schnorr addresses' to be distinct from 'ecdsa addresses' even if the
mathematical keypairs are identical. This would allow to still use
OP_CHECKSIG and so we would still have P2PKH addresses. If we were to add a
new opcode like OP_CHECKSCHNORRSIG, it would get ugly since we would need a
new cashaddr address version for the new opcode.

If there are any worries about weaker security, such a pubkey prefix byte
alteration would be the way to go. In future, a change in the pubkey prefix
byte would also be a good approach if we decide to add an algorithm that
doesn't use secp256k1. So it could be simpler in the very long term.

-Mark

On Thu, 6 Dec 2018 at 03:17, Tomas <tomas at bitcrust.org> wrote:

> Hi all,
>
> Thanks Shammah, for opening the discussion on the mailing list. Much
> appreciated.
>
> I have a question regarding the choice of algorithm selection mechanism
> for Schnorr. In the spec it is stated that the first byte of the signature
> serialization is 0x73 to mark the signature as using the Schnorr algorithm.
>
> As better algorithms may arise in the future I wonder whether this
> mechanism is suitable for future extensions; specifically compared to
> adding an (optional) algorithm-number argument to the checksig family of
> OPcodes.
>
> A flaw of putting the algorithm in the signature seems to be that the
> security of signing becomes as weak as the weakest algorithm. As such it
> seems more natural to use an argument; the choice of algorithm is clearly
> part of the OPeration.
>
> Maybe I am late to the game, but I am wondering whether this has been
> taken into consideration?
>
> Tomas van der Wansem
>
>
> On Sat, Dec 1, 2018, at 17:10, Shammah Chancellor wrote:
>
> Hello Gentlepeople,
>
> In the spirit of enabling others to work, I'd like to get the draft
> specification for May MERGED into the Bitcoincash.org repository.  Please
> review the existing spec here:
> https://github.com/bitcoincashorg/bitcoincash.org/pull/179
>
> And either explicitly reject, or approve it.  The hope is that it will get
> merged, and then further people can do pull requests on top of that to
> improve it before Jan 3rd.
>
> If you're unable to start a review in Github for some reason, please let
> me know.  However, I believe anyone is able to do it at this time.
>
> Kind Regards,
> Shammah Chancellor
> Bitcoin-ABC
> *_______________________________________________*
> bch-dev mailing list
> bch-dev at lists.bitcoinunlimited.info
> https://lists.bitcoinunlimited.info/cgi-bin/mailman/listinfo/bch-dev
>
>
> _______________________________________________
> bch-dev mailing list
> bch-dev at lists.bitcoinunlimited.info
> https://lists.bitcoinunlimited.info/cgi-bin/mailman/listinfo/bch-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bitcoinunlimited.info/pipermail/bch-dev/attachments/20181206/9abbf9a7/attachment.html>