As far as I know, the plan for hard forks is to always release the code for a hard fork approximately six months into the main repository as a point release before the hard fork code activates. However, there was some issue recently (mid-December 2016), that requires all users to update their clients again before the next hardfork in early January 2017. What was the issue that resulted in everyone being required to update in a matter of a few weeks? How was it resolved? Links to Github commits would be appreciated, but also a plain English (as much as possible) explanation as well.

1 Answer 1


First, some background. In MRL-0005 - Ring Confidential Transactions there's a section on range proofs, relevant quotes below.

5 Aggregate Schnorr Range Proofs

In [11], the confidential transactions without ring signatures uses a type of ring signature based on [1] called a Borromean ring signature, which helps to prove a committed value lies within a certain range. In this article, I will outline an alternative method, inspired by [7], which has the same space savings, but perhaps simpler security proofs.


For space savings, one can either use a Borromean ring signature (as in [11]) to combine all of these simple ring signatures, or a type of aggregate ring signature defined as follows:

5.0.1 Aggregate Schnorr Non-linkable Ring Signature (ASNL) Generation

Now, why do we need these? From the same paper (emphasis mine):

... as -1 is a very large number modulo the curve group order, free money has been created. It is therefore necessary to prove that the C_out,i are commitments to values which are positive and lie in a restricted range [0,2^n] for some n.

These signatures are used to prove that one is not using just anything to hide the amounts, ie to prove what I've highlighted above. It's important because allowing just anything would make it possible to cheat the sum(ins) == sum(outs) part of transaction verification. Thus, it's important that the proof be air-tight.

Now, an issue had been discovered with proof for ASNL signatures used in ringCT. If I understand well, it would open a theoretical possibility of someone forging the range proof somehow. Because of this, it had to be changed from ASNL to Borromean signatures.

If there was no update, everyone running the already deployed code of 0.10.0 would move on and start making rCT-ASNL transactions, but the theoretical problem would still be there and present an unnecessary risk.

Thankfully, at the time of this writing, there's still approx. 27 days until the HF (as reported by monerod).

See also: Failure of an exchange or pool to upgrade to Monero v0.10.1 by January 5th

  • Is there any plan to try and correct the issue with ASNL signatures, or Borromean is what will be used for the foreseeable future?
    – jwinterm
    Dec 14, 2016 at 23:02
  • 2
    Borromean will be used instead. From the comment in the Github discussion looks like that "fixing" the problem turns ASNL into Borromean, or something like that. Quoting divbit: I previously noted that there was a flaw in my previous comment- and that one needs to commit to the L1 values. After working this change through on paper, I realized that doing this essentially reduces to the Borromean sigs in any case (after replacing the sum with a hash of the L1)
    – JollyMort
    Dec 15, 2016 at 0:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.