-
jeffro256[m]
<tobtoht[m]> "> <@jeffro256:monero.social> New..." <- Now, in hindsight, I think it should’ve been released to the public earlier. But I wanted to make absolute sure that 1) the patch really did have the effect on decoy selection that I thought it did (so as not to create a false alarm) and 2) that there was no way that an malicious observer using heuristics knowing this vulnerability information would have an advantage as compared
-
jeffro256[m]
to the scenario in which this vulnerability wasn’t publicly known.
-
jeffro256[m]
Obviously now we know all the details about it, it should’ve been released at the beginning
-
jeffro256[m]
We also wanted to have a patched release ready when the announcement is made
-
jeffro256[m]
<sgp[m]> "jeffro256: if possible, please..." <- I’m sorry to have caused such a commotion. While I think this bug should’ve been announced earlier for everybody in general, in this specific case, like you mentioned, it doesn’t benefit to notify devs earlier than users because attackers get more external metadata on users the longer they stay on the old versions in aggregate. There’s no going back to “unleak” chain
-
jeffro256[m]
information or retroactively fix security holes by pushing secrets updates, it’s just a leaky implementation. If there was e.g. a remote code execution bug, there would likely be a lot more backchannel communication with third party devs months ahead of public notification
-
sgp[m]
jeffro256: fwiw, I definitely want to thank the fix, report, and the desire to make sure the fix actually worked in practice for something so sensitive
-
sgp[m]
So, thank you for everything else :)
-
DiegoSalazar[m]
Stack release should come out tomorrow btw. Also pretty blindsided but whatever.
-
sgp[m]
Luckily the fix is very simple, I just always want to make sure we're fighting for good user privacy, and that I'm doing my job to stay in the loop
-
sgp[m]
Literally just 6-7 lines:
cake-tech/cake_wallet #942
-
jeffro256[m]
<sgp[m]> "jeffro256: fwiw, I definitely..." <- And thanks to UkoeHB and moneromooo who were the first ones to find the bug
-
jeffro256[m]
!
-
jeffro256[m]
And jberman[m] for also confirming and and reviewing
-
putinsputout
Subject: Seeking Technical Assistance: Available Balance Limitation for Consecutive Transactions in Monero Mobile App
-
putinsputout
Hello everyone,
-
putinsputout
I hope you're all doing well. I have a technical question related to my project, and I'm reaching out to this community for some guidance. Although I'm not extensively familiar with Monero technology, I have a decent technical understanding and feel confident in making necessary changes to address the issue at hand. Here's a brief explanation:
-
putinsputout
In my project, I've set up a system with a primary account that holds a lump sum. This account is used for making payments to my team and performing withdrawals to secondary accounts. To facilitate these actions, I've developed a mobile app that connects to the Monero wallet through RPC (Remote Procedure Call).
-
putinsputout
The problem I've encountered is that whenever I make an outgoing transfer, the entire balance becomes unavailable. As a result, I'm unable to make consecutive payments or withdrawals without encountering the "not enough available balance" exception.
-
putinsputout
I'm turning to you all with the hope that someone can suggest a solution or workaround to overcome this limitation. I believe that even though I may not be an expert in Monero technology, I can implement any technical changes required.
-
putinsputout
I appreciate your time and support. Thank you in advance for sharing your insights and expertise.
-
putinsputout
Best regards,
-
putinsputout
Putin'sPutout
-
putinsputout
Please note that I am not using any monero library. I am connecting to the rpc directly
-
sech1
-
sech1
solution is to have more than 1 available output in your available. Preferably you should have as many outputs as you need to make all payments at once.
-
sech1
*in your wallet
-
putinsputout
unha...how do you suggest I go about this? What I've gotten from the solution in stack exchange is just to change the repo's source code before installing the daemon. Apologies if I sound like a noob, but is it possible to set it even lower than 1? most of the transfers i want to do are frequent micro-transactions, all the way own to 10 dollars
-
sech1
no, you can't fix it by changing source code, it's a consensus level rule
-
sech1
you have to wait 10 blocks before you can spend again
-
sech1
but you can have many outputs in your wallet
-
sech1
use "sweep_single [<priority>] [<ring_size>] [outputs=<N>] <key_image> <address>"
-
sech1
to split one output into many
-
sech1
you can split it into up to 16 outputs
-
sech1
sweep_single outputs=16 <key_image> YOUR_WALLET_ADDRESS
-
sech1
and key_image you can get from running "incoming_transfers available verbose" command in cli wallet
-
sech1
I don't know what RPC methods are used for this
-
putinsputout
Let me expound on the functionality I want to achieve. I want to be able to say send 0.02xmr to X, 0.44xmr to Y just a few minutes later an so on. There is no method to the transfers.
-
putinsputout
and so on*
-
sech1
you can achieve with code you already have, you just need to have many outputs in your wallet
-
putinsputout
Unha, I see, I see...Let me go do more research to build on this. Thank you very much for your time and help @sech1. Much appreciated.
-
moneromooo
It might be worth changing to these values in wallet2.cpp:
-
moneromooo
#define DEFAULT_MIN_OUTPUT_COUNT 0xffffffff
-
moneromooo
#define DEFAULT_MIN_OUTPUT_VALUE 0
-
moneromooo
This will prevent (by default) using two inputs when the first one is enough.
-
moneromooo
It was a "it seemed like a good idea at the time" attempt to make as many txes are possible be 2 output, to make them look like most others.
-
moneromooo
Rucknium[m]: you might have an opinion on this, statistically wise.
-
Rucknium[m]
moneromooo: The effect of the current config values is to cause consolidation of outputs over time (compared to changing the config values), right? The disadvantage of the current config is that users would more likely have their entire effective balance locked by the 10 block lock since they would not have multiple available outputs, correct?
-
sech1
from my experience, it usually creates 2in/2out transactions, so you use 2 inputs and receive back only 1 output
-
sech1
so it converges to only 1 available input
-
moneromooo
Yes.
-
Rucknium[m]
The current config is probably bad for user experience, but may be good for privacy. It's hard to say. Consider timing analysis on multi-input transactions:
-
Rucknium[m]
If a user has 5 transactions where each one has two inputs (which is more likely with the current conifg), that create a certain (low) risk of timing analysis on each pair of rings in those transactions.
-
Rucknium[m]
If the config changes, then that same user may have 4 one-input transactions and then one 5-input transactions when they send all or most of their wallet somewhere (e.g. to a centralized exchange).
-
Rucknium[m]
I don't know the statistical gain of accuracy from using 5 inputs on timing analysis vs just two, but it is probably a nonlinear convex function. Maybe approximately exponential.
-
Rucknium[m]
So you might have many transaction that are not very vulnerable to timing analysis (current config) vs. one single transaction that is highly vulnerable to timing analysis (if the config was changed).
-
Rucknium[m]
The actual impact would depend on actual user behavior (which is partially observable on the Monero blockchain and fully observable on transparent coins with UTXO models.)
-
LyzaL
seems like that 5-input tranaction would also be likely to be made of mostly change outputs which could also imply the transactions that created those outputs belong to a single user
-
LyzaL
speaking of user behavior, there's at least one popular wallet with full coin control (feather) so perhaps less people using the default output selection algo than expected