Hacker News Reader

Comment by MichaelZuo | Hacker News Reader

It’s interesting that they were keeping the change in reserve for expiration day. I wonder what else is being kept in reserve that could enhance bitcoin?

View on HN

Schnorr signatures were also kept in reserve for many years due to a patent that recently expired. Should be merged in the next major feature release.

Not that recently... The patent expired in 2008. Schnorr signatures were implemented in the Bitcoin Cash chain in May 2019, and Schnorr multisignatures in November 2019.

Schnorr signatures are sort of a challenge to use, unfortunately.

Schnorr signatures (e.g., Ed25519) are just another kind of digital signature, there's nothing that makes them more challenging to use.

There is nothing more challenging about schnorr signatures themselves, but 100% of the lauded "advanced" things that can be done with a schnorr signature over ECDSA-- such as threshold signatures-- as substantially more complicated and error prone.

Until recently (or still) pretty much none of them had production usable implementations anywhere for any application, and most academic coverage has mostly been a glib "trivially you can do that"-- ignoring that naive "obvious" implementations end up being completely insecure.

As someone familiar with bitcoin but not cryptography, in what sense is it more challenging to use?

Schnorr is most useful when used as a multi party signature. It works how you would expect it to, you can literally take a bunch of people signing the same message and end up with a single signature at the end by adding them all together. However this is annoying to do in practice because it requires back and forth communication between every party to produce the signature, which precludes its use in something like a hardware wallet where a user manually confirms a signature, as they'd have to do it many times.

I wonder if this is something a hardware wallet provider could solve on their end in the software. Like one signature is a go for subsequent needed signatures as long as nothing changes with the transaction or something like that.

Possibly, it still has the expectation that all parties are online to some degree which isn't something we have in Bitcoin today, where signatures can be added even years after the fact when needed. None of this is killer or a reason to not use Schnorr, it's just not quite as much of a magic bullet as people originally expected. To my knowledge this wasn't a very well known property until anybody had implemented it for bitcoin, I doubt it was ever used once it was patented.

"where signatures can be added even years after the fact when needed"

Why would you need this to be the case? In my mind (im not an expert) I just imagine schnorrs batching signatures into one tx on the chain. And then its done. Why would you need to add years after?

Signature aggregation would be only on a transaction level, not on a block level as you require interaction between all signing parties, and any party can block the signature. You would also have to have some system of making a block, then everybody re-signing their transactions to make the block aggregated- it's just not happening.

In Bitcoin today we can do things like make a conditional signature in a multi signature. With three parties, one can pre-sign a transaction and lock it until a future date, then hand it to the other parties who can sign it at their leisure when that time is elapsed. This would not be possible with schnorr unless you also had the expectation that all parties would be online when the lock time expires.

Your comments are unintentionally misleading people, see vmception's comments above.

Yes, to get the space/validation improvements you can get from schnorr you need interaction. But it's perfectly possible to use it in the same way as ECDSA, it only adds options, it doesn't remove them. For some applications the requiremetn that the participants isn't a big deal and they can enjoy those benefits, otherwise they don't.

It is sad that bitcoin's solutions have a liveness expectation, whereas other chains have a lot of competing solutions where only some of those solutions have a liveness expectation

It is like watching a state-capital system versus a free-er market compete.

People in the state-capital system have completely binary things to argue about, with dissidents being shunned while everyone is stuck in a quagmire of false dilemmas. Third and fourth and additional options are not considered.

Whereas in the free-er market, people are allowed to take risks and fail, fail with LOTS of money and value, and iterate en masse towards solutions that are most "useful" ideally, but also service a variety of use cases.

I'll let Pieter Wuille explain: https://twitter.com/pwuille/status/1297630790713348096?s=19

>...that could enhance bitcoin

It does not its irrelevant it chances nothing about bitcoin or its limits. Its a client side it does not speed up usage or something the CPU just useless less cycles and idles more.

It reduces synchronization time substantially, as it involves literally billions of signature verification operations.

So what? It changes nothing at all. Block time/confirmation time is still the same/fees still explode if transaction reach the limit. Its completely irrelevant from a user PoV.

Given that the network is checking constantly from numerous sources. It's a pretty significant improvement in efficiency.

Users still need to be able to verify data independently.

Not really, but they can if they want and still can with the "new" code it changes nothing.

Reply on news.ycombinator.com