<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 9, 2015 at 11:21 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Last night there was a presentation [0] on bitcoin's sidechains that said, copying from twitter:<br>
<br>
     * Also replaced ECDSA with Schnorr<br>
        - Efficient (non-accountable) multisig<br>
        - Batch verification (2x speedup)<br>
<br>
<br>
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.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div><div>Deploying a new signature algorithm to mainline Bitcoin doesn't seem that hard to me. I'd recommend this approach:</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>*Don't do this. Please don't do this.</div><div><br></div></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>