Feed for tag: schnorr
Ledger's Nano S 1.5.5 Firmware Update Causes Troubles

The Ledger Nano S’ firmware has been recently updated to 1.5.5, while this update brings several features like the support of Groestl and Blake2b as new hashes, Schnorr with Zilliqa as a new signature scheme, Bip32-ed25519 as a new derivation scheme and several other major security updates.

It also caused troubles for its owners wanting to update. As this firmware is slightly larger in size than old ones, HSM servers hosting this update became unresponsive as many users were simultaneously trying to update their device, causing access to the Manager and installing apps to be slower than usual, a significant amount of users reported their device getting stuck during the update which would be later addressed with another update and an apology from Ledger.

Schnorr and Taproot Update

An effort to put a solid taproot proposal was done by developer Anthony Towns, the proposal was about segwit v1 with several adjustments to the current segwit version which included :

  • replacing the ECDSA Checksig/CheckMultiSign ops with new Schnorr ops
  • introducing a 33-byte v1 witness addresses that encode a secp256k1 ECC Point P that is spendable either by a direct schnorr signature of a script with the witness data and a taproot/merkle path to the script.
  • Versions for taproot scripts
  • Adding OP_MASK to support script masking via sighash
  • Making invalid opcodes upgradeable to have more flexibility than OP_NOP

read the proposal here

Workshop Summary Scaling Bitcoin V Tokyo 2018

Content originally published by BitcoinOptech on newsletter #16.


The fifth Scaling Bitcoin conference was held Saturday and Sunday in Tokyo, Japan. In the sections below, we provide brief overviews to some of the talks we think might be most interesting to this newsletter’s readers, but we also recommend watching the complete set of videos provided by the workshop organizers or reading the transcripts provided by Bryan Bishop.

Mast and Schnorr Signatures
Bitcoin’s development effort for the past few years has been focused on a few key concepts, privacy, scalability and efficiency. One of the first improvements was Segregated witness which is ushering in the rest, Lightning Network followed but was an effort in a different direction as it took transactions off-chain rather than optimizing the on-chain process. Some of the upcoming technologies aimed at optimizing this process are Schnorr Signatures and Merkelized Abstract Syntax Trees or MAST for short.
BLS Library

A library has been released for BLS signature aggregation using a construction based on Musig. Musig is a scheme for non-interactive signature aggregation built on the Bellare-Nevan multisignature scheme which makes it possible to create just one public key from multiple public keys.

BLS signatures can be aggregated non-interactively although it makes the process slightly slower. They also have the same aggregation features with Schnorr signatures such as a resulting signature of constant size, reduced data size for easy validation and transmission on networks and high security.

This release is the first draft but is fully functional however it’s not yet reviewed for security.

An other known BLS library can also be found here

Generalized Taproot

Taproot is a mechanism that works like MAST but without the 32 byte overhead, it was created earlier this year by developer Greg Maxwell.

An update on Taproot was recently published on the Bitcoin-dev mailing list dubbed Generalized Taproot, its essentially a recursive taproot which is as space efficient as taproot in some cases and sometimes potentially more efficient in cases like when one merkle branch is more likely than the other.

Generalized Taproot is not something that we will see being deployed any time soon but it could be a further enhancement to the increasing amount of applications built on Schnorr Signatures coming in the next months/years.

BIP Proposal for 64-byte Elliptic Curve Schnorr Signatures

One of the core components of Bitcoin is the Digital signature algorithms, it is used in making public keys out of private keys, signing transactions and in multisig transactions. Bitcoin so far has been using Elliptic Curve Digital Signature Algorithm ECDSA, for the past few months developers in the Bitcoin community have been talking about changing this algorithm into another one called Schnorr Signatures.

Schnorr is another signing algorithm that bring multiple benefits to the table. A new BIP was recently submitted by Peter Wuille about the changes that should happen in the future to Bitcoin’s signing algorithm with all the bells and whistles it should bring. The security of Schnorr is easily provable given a certain assumption, this is not the case for ECDSA.

Scriptless Scripts With ECDSA

Pedro Moreno Sanchez via Bitcoin Dev linked the following paper, Multi-Hop Locks for Secure, Privacy-Preserving and Interoperable Payment-Channel Networks.

…my co-authors and I have been working hard to get ready an extended version of the paper for this work…

In this paper, we describe in detail the scriptless script (SS) ECDSA construction and formally prove its security and privacy guarantees. Additionally, we describe several other constructions of interest for the LN:

-The SS Schnorr, initially proposed by A. Poelstra. We formally describe the protocol and prove its security and privacy guarantees

-Interestingly, we show that it is possible to combine SS ECDSA and SS Schnorr without losing security or privacy. This allows interoperability between different implementations.

-A framework to combine script-based cryptographic locks using partially homomorphic one-way functions.

-Possible applications. For instance, SS ECDSA could be used today in Bitcoin to perform atomic swaps where the resulting transaction no longer reveals the cryptographic condition. Instead, it is embedded in a regular ECDSA signature. This provides several advantages such as reduced transaction size and better privacy/fungibility among others.

A cornerstone of their approach is to provide interoperability between different signature schemes. The utility of such an approach is a form of “cryptographic future-proofing” where if one scheme is broken there are fall-back functions that are still secure.