[Cryptography] Bitcoin sidechains to use Schnorr (was: Open Questions)

[Tony Arcieri]

On Tue, Jun 9, 2015 at 11:21 AM, ianG <iang at iang.org> wrote:

> Last night there was a presentation [0] on bitcoin's sidechains that said,
> copying from twitter:
>
>      * Also replaced ECDSA with Schnorr
>         - Efficient (non-accountable) multisig
>         - Batch verification (2x speedup)
>
>
> See here [1] for more of what that means, but your central point is taken
> - the crypto needs an update.  As it happens, they are not changing the
> curve, just the signature.
>

So instead of using a standard Schnorr variant with a modern SafeCurve like
Ed25519, they're going to homebrew their own variant of Schnorr with an
elliptic curve that nobody else would choose today?

That doesn't make a whole lot of sense. Changing the signature algorithm
means all clients will need to be updated before people can start using it
regardless of what curve we use. So as long as you're doing that, why not
just use a standard off-the shelf digital signature algorithm like Ed25519
which already has already received a decent amount of cryptanalytic
scrutiny and has multiple robust implementations across a variety of
platforms?

Doing what they propose would let people keep their old secp256k1-keyed
Bitcoin addresses, at the cost of developing and maintaining their own
signature algorithm which nobody with any sense would use for anything.

Instead of homebrewing their own crypto*, they could switch to an
off-the-shelf solution like Ed25519, and people who want to take advantage
of it can move their Bitcoins to a new Ed25519-secured wallet.

But, let's talk about the real issues:  engineering and deployment. It's
> easy to pick another cipher suite, it's difficult to deploy it. This change
> likely will deploy in sidechains only for the short and medium term, so the
> mainnet bitcoin will probably have to wait a while.  It may never change.


Deploying a new signature algorithm to mainline Bitcoin doesn't seem that
hard to me. I'd recommend this approach:

1) Pick a target date by which all clients MUST implement the new
algorithm. Perhaps a year? Two years? Whatever makes sense when people
discuss it.
2) Begin adding support for the new algorithm to all clients, but disabled
until the target date, flipping on automatically when the target date is
reached.
3) Once it's the target date, clients can begin using the new algorithm.
Miners that haven't updated will fork the block chain because they'll be
unable to verify the new signatures, but hopefully the majority of
clients/miners have implemented the new signature algorithm by then.

Bitcoin may already have a better upgrade path than this built in (I
understand wallet addresses contain a version number), but I don't think
it's as difficult as you suggest.

*Don't do this. Please don't do this.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150609/195f6c84/attachment.html>