03:23:29 <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
03:23:29 <jeffro256[m]> to the scenario in which this vulnerability wasn’t publicly known.
03:24:00 <jeffro256[m]> Obviously now we know all the details about it, it should’ve been released at the beginning
03:26:51 <jeffro256[m]> We also wanted to have a patched release ready when the announcement is made
03:35:57 <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
03:35:57 <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 
03:38:47 <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
03:39:16 <sgp[m]> So, thank you for everything else :)
03:39:17 <DiegoSalazar[m]> Stack release should come out tomorrow btw. Also pretty blindsided but whatever. 
03:40:04 <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
03:41:00 <sgp[m]> Literally just 6-7 lines: https://github.com/cake-tech/cake_wallet/pull/942
03:45:28 <jeffro256[m]> <sgp[m]> "jeffro256: fwiw, I definitely..." <- And thanks to UkoeHB and moneromooo  who were the first ones to find the bug 
03:45:28 <jeffro256[m]> !
03:46:25 <jeffro256[m]> And jberman[m] for also confirming and and reviewing 
08:37:10 <putinsputout> Subject: Seeking Technical Assistance: Available Balance Limitation for Consecutive Transactions in Monero Mobile App
08:37:11 <putinsputout> Hello everyone,
08:37:11 <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:
08:37:11 <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).
08:37:15 <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.
08:37:19 <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.
08:37:25 <putinsputout> I appreciate your time and support. Thank you in advance for sharing your insights and expertise.
08:37:27 <putinsputout> Best regards,
08:37:29 <putinsputout> Putin'sPutout
08:38:48 <putinsputout> Please note that I am not using any monero library. I am connecting to the rpc directly
08:43:06 <sech1> This is the 10 block lock: https://monero.stackexchange.com/questions/4579/is-the-10-block-lock-time-a-protocol-rule-what-rules-accompany-it
08:43:44 <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.
08:43:50 <sech1> *in your wallet
09:22:09 <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
09:23:12 <sech1> no, you can't fix it by changing source code, it's a consensus level rule
09:23:21 <sech1> you have to wait 10 blocks before you can spend again
09:23:27 <sech1> but you can have many outputs in your wallet
09:24:38 <sech1> use "sweep_single [<priority>] [<ring_size>] [outputs=<N>] <key_image> <address>"
09:24:43 <sech1> to split one output into many
09:24:48 <sech1> you can split it into up to 16 outputs
09:25:11 <sech1> sweep_single outputs=16 <key_image> YOUR_WALLET_ADDRESS
09:26:03 <sech1> and key_image you can get from running "incoming_transfers available verbose" command in cli wallet
09:26:11 <sech1> I don't know what RPC methods are used for this
09:30:47 <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.
09:31:19 <putinsputout> and so on*
09:32:31 <sech1> you can achieve with code you already have, you just need to have many outputs in your wallet
09:36:18 <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.
10:02:34 <moneromooo> It might be worth changing to these values in wallet2.cpp:
10:02:36 <moneromooo> #define DEFAULT_MIN_OUTPUT_COUNT 0xffffffff
10:02:36 <moneromooo> #define DEFAULT_MIN_OUTPUT_VALUE 0
10:03:00 <moneromooo> This will prevent (by default) using two inputs when the first one is enough.
10:03:38 <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.
10:04:03 <moneromooo> Rucknium[m]: you might have an opinion on this, statistically wise.
14:33:53 <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?
14:48:08 <sech1> from my experience, it usually creates 2in/2out transactions, so you use 2 inputs and receive back only 1 output
14:48:15 <sech1> so it converges to only 1 available input
14:57:40 <moneromooo> Yes.
15:20:27 <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:
15:22:33 <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. 
15:23:42 <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).
15:24:23 <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.
15:25:36 <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).
15:26:12 <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.)
17:01:02 <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
17:02:17 <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