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

[ianG]

On 30/05/2015 02:49 am, Tony Arcieri wrote:
> On Fri, May 29, 2015 at 6:24 PM, ianG <iang at iang.org
> <mailto:iang at iang.org>> wrote:
>
>         Strongly disagree. I have a long-form comment on this as part of
>         this
>         blog post (see "A Bitcoin Crypto Meltdown")
>
>         http://tonyarcieri.com/the-death-of-bitcoin
>
>
>
>     Except, you changed the topic.  Coming back to the topic ... do you
>     disagree that Bitcoin uses one alg for each function?  Oh wait, your
>     post is about how you agree that it's only using one alg.
>
>     You're real disagreement is that you don't like that it is using one
>     alg, and predict it will therefore melt-down :)
>
>
> Satoshi chose a bad curve. Nobody who knows anything about ECC would
> suggest using secp256k1 over Curve25519. They should switch, if only
> because that 1-bit backdoor is particularly scary, but they can't do
> that easily because the Bitcoin protocol has nothing to signal that
> wallet keys are anything but ECDSA with secp256k1.


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.

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.

Indeed hypothetically if the curves/crypto in mainnet never change [2], 
and weaknesses are discovered, then there might be a force that migrates 
all value over time to new chains.  This is a complicated thing, and 
I'll go out on a limb and say, it might actually be a good thing as much 
as a bad thing.

Each of these new sidechains can use a new selection of crypto. 
Probably most will use the same selection of crypto, indeed it is going 
to be pretty rare to change.

Now, given this migration path from bitcoin to sidechains, and given the 
fundamental premise of the bitcoin concept that it should be hard to 
change, I'd suggest that they (the devs) are naturally going to prefer 
one suite and only one suite for any given chain.

Let's say you decided that algorithm agility was good, universally and 
therefore you wanted to put it in.  If you want to employ agility you 
have a real hard time designing something that actually added value.  In 
part because you're not improving the security of old keys, in other 
part because of the downgrade attack - imagine having the possibility of 
two signature mechanics coming from one key, not happy at all, because 
you get the full weakness of both!

And in other part because as soon as you start fiddling with the crypto, 
you find it's actually not the biggest concern, and full review of all 
concerns are driving you to build entirely new software sets.  I.e., 
look at yesterday's talk.

In short, we want sidechains or altCoins, depending on our religion.

In short, 1TCS.  Bitcoin may be a good engineering example of where it 
dominates as the solution, and algorithm agility does not.



iang




[0] Greg Maxwell, there is what appears to be a practice run here 
https://www.blockstream.com/developers/ for those who weren't at the 
developers meet-up.
[1] http://elementsproject.org/
[2] Greg mentioned in the talk there is a soft fork going through now to 
do with 'signature minutea'.


>     Actually, I suspect regardless of our views, Bitcoin is locked into
>     the 1TCS for now.  Because if they add another algorithm, it is
>     totally worthless until every client has got it.  Which to
>     paraphrase Peter "will make them think."  And we will benefit from
>     the experience.
>
>
> I expect that Bitcoin and/or future pubkey-based decentralized
> transaction consensus protocols will begin switching to Ed25519 soon.
> The interop problem is a difficult one, and the reason why most sites
> continue to use RSA certificates for TLS. But forward progress is
> possible. AES-GCM is seeing widespread usage now where just a few years
> ago AES-CBC and RC4 were the norm.
>
> Given Bitcoin's lack of cipher agility, using Ed25519 instead of
> secp256k1 provides another checkmark on a gumball chart for any would-be
> Bitcoin killer. Secure elliptic curve according to safecurves.cr.yp.to
> <http://safecurves.cr.yp.to>? Usurper: check.