@reuben I didn’t notice this message and randomly chose this time frame to click “anonymize funds” from the QT wallet. The coins are all in pending since then. Are they stuck in that state until this review is done or is there a way to unanonymize and switch them back to Transparent balance? I’m not in a super rush so if it’s safer and better to just leave them pending until Lelantus is enabled I’ll do that. Just wanted to make sure my coins are safe!
Thank you
You can return them to your transparent balance by right-clicking on the transaction, choose Abandon transaction, and restarting the wallet.
While Trail of Bits and Sarang are continuing to review the fixes, we’ve also dived deeper into other components of Lelantus to ensure that the balance proof holds. The team is in deep discussion on this and while we cannot think of any possible attack vector for this balance proof we are rechecking the security proofs to ensure they hold before we reactivate.
We hope to get the fixes approved in the next few days while we evaluate whether it’s safe to reactivate. I hope to get something concrete this week and get our researchers to comment once they have reached consensus.
I’m optimistic though these things are a bit hard to estimate until I get confirmation from our researchers but significant headway is being made.
You have enough time to systematically fix it.
Trail of Bits have gone through our fixes and have verified them. The analogy for the attack can be thought of something like this:
“If the audience sees you shuffle the deck first, it’s easier to think you did something wild and magical. This attack is like being allowed to examine the deck and order it in front of the audience, the trick doesn’t seem so magical anymore…” Sarang
“The attacker forges a spend then time travels back just a bit to set up events so the spend would seem legit” Peter.
So if the above is all we need to do, Lelantus can be re-enabled next week.
What we have to decide is something more subtle. Unrelated to the attack, Aram, Sarang, Peter and Levon have still been discussing another subtlety of the Lelantus balance proof. Currently, all parties cannot think of a way to take advantage of this and it intuitively seems correct but we are assessing whether we should add an additional check to harden it or is it safe as it is. This check adds 64 bytes per transaction with negligible performance cost but it would involve about a week of work again and we are still debating its value. We also have reached out to other researchers and some have said they would only be able to look at it next week.
So right now while we can re-enable Lelantus pretty soon with the fixes, we are debating on whether to address the 2nd “potential” issue before activating.
I hope this gives some light into what’s happening behind the scenes!
Great work by a professional set of people.
We voted to enable the ‘dead man switch’ on Lelantus and this is exactly what it was for.
Hard to say whether to do two separate fixes right now or go with the “card shuffle” fix and release everybody’s private balances. The risk is – like chainlocks – the second case gets exploited before addressing it – if indeed it is even a bug
In the long run what is a couple of extra weeks? In my opinion it is better to leave Lelantus ‘off’ until the additional cryptographers have had the chance to review the work of Aram, Sarang, Peter and Levon.
64 bytes per transaction is a small price to pay for heightened privacy. When the old chain gets cleaned up (next year?) it will pale into insignificance.
The current plan is to incorporate the additional proof for safety which we hope will be ready for review on Monday and maybe it’ll be a few days to push and deploy. It doesn’t affect privacy but may improve security.
Hi!
Great to read about the progress so far, thanks for being transparent and taking the time to post updates.
Yet there is some aspect in using the CLI-wallet which seems related to the currently disabled Lelantus protocol that I don’t understand: Similar to user darkfusion (see above), I chose a rather unfortunate time to run firo-cli mintlelantus to about half of my wallets funds before noticing this thread.
I understand that the to-be-minted part of my funds is now locked until this is resolved but what remains unclear to me is that I also cannot seem to transfer any of the remaining funds (sendtoaddress returns with code -6 and message Insufficient funds), so basically my whole wallet went into some kind of locked state.
This might probably be not the right place to ask but is there a cli-equivalent to what anwar proposed as a temporary workaround (choosing Abandon transaction in the gui-wallet)?
Thanks for any hints on this and good luck for the upcoming implementation tasks!
You can use abandontransaction "txid". A successful abandon will return a (null). You might need to restart for it to show up as abandoned properly.
sendtoaddress most likely did not succeed because it is waiting for change from the now disabled Lelantus transaction.
Trail of Bits has also agreed with the opinion of the team to add the additional proof for safety even if there is no obvious weakness.
An excerpt of their comment:
That being said, given that this extra proof seems pretty cheap, I’m definitely on board for adding it for defense-in-depth purposes. It sounds like we’re all not 100% certain on the balance proof being secure without it. Beyond that, it could protect from some unforeseen malicious behavior in the sigma proof itself, or it could potentially mitigate some exploit that relies on some yet to be discovered weakness.
The current timeline is deploy code on testnet on Monday, test/review and hopefully binaries end of week with a one week activation time.
that was a good hint, thanks!
after locating my mint-transaction with listtransactions to get the txid and applying it to abandontransaction i can now use my wallet normally again. yet i’m looking forward to trying out lelantus minting capabilities!
thanks again for your guidance!
We are going to be testing the fixes on testnet later today.
We have made public the code
List of Changes:
Q_k to properly argue the polynomial cancellation needed for showing balanceWe are deployed on testnet 
keep you guys posted.
The fixes were deployed on testnet and we found a few performance related issues which we are diving into. They aren’t serious (they are related to UI transaction list lags and fee calculation lags) but we are proceeding to make sure it’s in a good state for launch and should be fixed soon.
Thank you for you patience and understanding.
鲁公子 啥时候来中国 开开宣传 中国欢迎你 
PR is under review status now. Tests are going well.
Wish us luck!
Any news about lelantus?
等待一切都是好消息 我们将稳步前进