[Bitcoin-ml] Can we decide on a roadmap now?

Jan Nightingale turifex at protonmail.ch
Sun Sep 3 11:43:15 UTC 2017

>Faster transaction validation

True, but that's what I mean by cosmetic. I don't think anyone would actually be able to notice this.

>Smaller transactions

Not really, the real difference is just one bit, which could be removed at a negligible performance cost.

>CoinJoin support

Everything that's possible with Schnorr is possible with ECDSA. Introducing ECDSA signature aggregation would require much smaller changes, as everything already has all needed code. Schnorr requires a much bigger update.

> -------- Original Message --------
> Subject: Re: [Bitcoin-ml] Can we decide on a roadmap now?
> Local Time: September 3, 2017 9:46 AM
> UTC Time: September 3, 2017 7:46 AM
> From: bitcoin-ml at lists.linuxfoundation.org
> To: bitcoin-ml at lists.linuxfoundation.org <bitcoin-ml at lists.linuxfoundation.org>
>> > Schnorr signatures
>> Can I ask why?
>> The difference is imo cosmetic
> Schnorr advantages:
> Faster transaction validation
> Smaller transactions
> (^= smaller fees)
> CoinJoin support
> (^= more privacy)
> Here's an article about it: https://bitcoinmagazine.com/articles/the-power-of-schnorr-the-signature-algorithm-to-increase-bitcoin-s-scale-and-privacy-1460642496/
> Here's a list of Schnorr's ALL advantages: [https://bitcoin.stackexchange.com/a/35351/](https://bitcoin.stackexchange.com/a/35351/38618)
> Bitcoincore.org article: https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> Technical documentation: https://github.com/sipa/secp256k1/blob/968e2f415a5e764d159ee03e95815ea11460854e/src/modules/schnorr/schnorr.md
> Maybe we should add FlexTrans and Schnorr in the same hard fork when Schnorr is ready, making the transaction size much smaller?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170903/f37d7784/attachment.html>

More information about the bitcoin-ml mailing list