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!
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!
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.
Sarang has verified that all the proposed fixes have been implemented properly but has recommended two small changes that would result in slightly more efficiency and a fixed-size prepend when updating transcripts with vectors This is best practice to mitigate any concatenation collisions as part of a defense in depth strategy.
Add vector size into transcript
Move inner product domain separator further up
The changes are small enough that it can be implemented today though testing should still be done. The testnet would need to be rewound a bit to incorporate this change.
This delays by a few days but sets long term improvements so I took the decision to do it. Appreciate the patience.
Levon also got into a bad car accident a few days ago but is thankfully okay just a bit shaken up so we gave him a few days off but is now back at work.