02:21:35 <gingeropolous> interesting. so i go and make a transaction
02:21:55 <gingeropolous> i hit "confirm" or whatever. and then it sorta goes back to the wallet. i try and click around to see if things worked..
02:22:14 <gingeropolous> and then a pop up informs me that the transaction succesfully sent
02:22:48 <gingeropolous> i expected it to show up in my transaction history, like, immediately. 
03:01:33 <gingeropolous> hrm. sending to self not a good idea?
03:02:06 <gingeropolous> so i effectively sent all to my own address. (sweep all to same)
03:02:13 <gingeropolous> just by hitting all
03:02:18 <gingeropolous> and it says the tx is failed
03:02:22 <gingeropolous> so, i go and make a new tx
03:02:29 <gingeropolous> and now it says error double spend
03:12:22 <selsta> how long did you wait?
04:13:02 <tobtoht> is there a hard limit on the d++ embargo timeout?
04:13:17 <tobtoht> seems like the current strategy of waiting 3/2 * average_dandelion_timeout before setting a transaction to failed isn't reliable
04:13:55 <tobtoht> I often observe transactions unfailing themselves given enough time
04:14:05 <selsta> tobtoht: yep, it should be reliable with https://github.com/monero-project/monero/pull/7021
04:14:27 <selsta> currently it can take 2 extra minutes which we didn't take into account
04:14:38 <selsta> sending from tor / i2p can result in 4 extra minutes
04:14:54 <selsta> but both should be resolved with 7021
04:17:18 <tobtoht> selsta: ty, looks good
04:18:02 <selsta> I did not test it myself yet but it matches with what I have been experiencing with delays
04:51:55 <gingeropolous> ermagerd i can't send because of this double spend error
04:53:13 <gingeropolous> ah the tx is in the mempool
04:53:20 <gingeropolous> i connected to a different node and wi tworked
04:53:24 <nioc> turn it off and on again.  mebbe rescan_bc
04:53:41 <nioc> oh
04:53:43 <gingeropolous> im using the gui bro
04:53:47 <gingeropolous> there's no button for dat
04:53:56 <nioc> we have a gui now?
04:54:12 <nioc> w0w
04:54:21 <tobtoht> two, even
04:54:25 * tobtoht flees
04:54:27 <nioc> :)
04:54:39 <nioc> ty for that tobtoht 
04:54:59 <nioc> say hello to that other guy
04:57:48 <gingeropolous> gui output control would be neat
04:58:23 <gingeropolous> like a screen with "with note would you like to spend?"
04:58:37 <gingeropolous> and then it has a depiction of different notes (outputs) with their details
04:59:02 <gingeropolous> and you click on them and a little field in the top right starts adding their value together
04:59:25 <gingeropolous> cause here I am waiting 20 minutes to play with my damn magic internet money
04:59:36 <gingeropolous> like a tool!
05:00:13 <gingeropolous> should be ale to just fire it off like lazers! Ptchoooo! ptchooooo!
05:02:18 <tobtoht> feather has coin control if you want the true poweruser gui experience (tm)
05:02:23 <tobtoht> no lazers tho
05:02:29 <tobtoht> we'll look into that
14:17:39 <xiphon> "cause here I am waiting 20 minutes to play with my damn magic internet money"
14:17:47 <xiphon> you have only 1 unspent output
14:18:03 <xiphon> output control won't help you anyhow
14:19:07 <xiphon> btw, i wonder what is the real world use case for output control feature
14:20:21 <xiphon> at a glance it seems as a useless feature to me. Though like i said, would love to hear any real world use case in case i'm missing something
14:20:43 <xiphon> gingeropolous ^
14:25:49 <tobtoht> xiphon: it's mostly for high threat model coin routing: excluding dust outputs, mitigating output merge analysis (by default wallet2 will prefer spending outputs that belong to the same subaddress, this can be undesired behaviour in some scenarios), churning specific outputs
14:27:48 <tobtoht> churning is useful when moving coins from high to low threat model wallets, or vice versa to make make sure there is no longer any association between the two
14:30:04 <tobtoht> also the ability to split outputs is useful when you're expecting to send a bunch of transactions in rapid succession, if you only have one output you're forced to wait 10 blocks after every tx
14:31:44 <tobtoht> multi destination transactions are not a solution in some cases because they are inherently bad for privacy because they allow for trivial off-chain linking
14:34:06 <xiphon> I wouldn't rely on a user doing all this correctly.
14:34:26 <xiphon> Letting users control their outputs could (and in most cases will) do the things worse
14:34:43 <xiphon> Also churning idea is quite questionable
14:35:27 <tobtoht> yes, these address protocol issues that can currently only be mitigated by users that know what they are doing
14:35:36 <moneromooo> Dust outputs can be frozen (and won't be spent if too small already). Rules to weigh outputs when selecting what to spend should be added to wallet2 if they're good.
14:35:49 <tobtoht> churning is indeed very hard to get right
14:37:31 <tobtoht> "mitigating output merge analysis", moreover wallet2 will often prefer 2-in/2-out transactions when the number of coins in the wallet is high enough. This has the possibility of linking those two inputs together which in some cases may be undesirable if the transaction could have been made with 1-in/2-out instead.
19:00:20 -xmr-pr- selsta opened issue #3241: Portable mode .cache traces
19:00:20 -xmr-pr- > https://github.com/monero-project/monero-gui/issues/3241