00:11:19 <endor00[m]> Maybe you have some overly restrictive --up-limit or --down-limit in your monerod config?
00:11:43 <endor00[m]> Or very bad quality signal/lots of interference on your local network
00:11:53 <endor00[m]> Or some bad firewall/routing rules
01:28:44 <bobandback> endor00[m], no limits set for monerod, regular file transfers work at full gigabit speed in both directions.
03:01:11 <gingeropolous> bobandback, if your running the new release, you need to modify your rpc bindings
03:01:39 <gingeropolous> well wait. what u have might be ok.
03:02:08 <gingeropolous> bah, i better update that info on moneroworld
03:02:57 <bobandback> Well it works, kinda, i do need to set my GUI to remote node and connect like 5 times before it will connect. And launch monerod from terminal, doesn´t work if i run these parameters in the GUI node.
03:03:58 <bobandback> I assumed the GUI would just launch monerod with those parameters as if you would just launch it yourself, but it seems it´s doing something a little different.
03:10:00 <gingeropolous> i thought it just launches the node with those configured parameters.
03:10:16 <gingeropolous> wait, are you trying to connect the GUI to a remote node?
03:10:23 <gingeropolous> or are you running monerod on the same computer as the GUI?
03:20:23 <bobandback> running monerod and GUI on same system.
03:20:57 <bobandback> But i cannot run monero node from within the GUI with the same parameters, it won´t work. I have to set GUI to remote node and keep trying to connect to localhost until it ´gets it´.
03:23:11 <bobandback> So that´s the first strange thing. Second is that using monerujo with this machine running monerod is extreeeemely slow, like a few blocks per minute at best. But when i connect to the external IP through mobile data, it´s as fast as my connection can handle it seems.
03:32:00 <gingeropolous> yeah that is weird
03:32:36 <bobandback> I would guess not many would run a public node from within the GUI, so maybe it´s a bug that has gone unnoticed?
03:35:23 <gingeropolous> perhaps yeah. what OS?
03:35:57 <gingeropolous> and is this v0.17.1.6?
03:41:21 <bobandback> ubuntu, yes 0.17.1.6
04:15:41 <gingeropolous> ah gui on ubuntu...
12:06:52 <binaryFate> something seriously wrong at google, both youtube and drive are down
12:07:15 <binaryFate> gmail too
12:08:22 <moneromooo> Good. Next step, Cloudflare.
12:10:08 <sech1> Everything google is ded
12:10:28 <sech1> But youtube werks in private mode (not logged in)
12:23:52 <ComplyLast> google down, good for humanity. next facebook, let's do it.
12:31:30 <ocb> hello
12:37:30 <jess> binaryFate: seems to be back, rumour is their account lookup was returning partial json which broke anything downstream trying to us it
12:38:39 <binaryFate> interesting
12:39:11 <ocb> i have a question about monero. a few versions back, possibly about 1-1.5 year ago received a small amount of monero, around 2 xmr to a subaddress let's call it X that has integrated payment id. then, as soon as the tx was confirmed sent 0.5 xmr from X to Y. as soon as that one was confirmed, sent 0.3 xmr from Y to Z. ring member from X to Y was the 0-th ring member, assuming due to the transaction age. i've repeated this again and again, it was the 0-th ring m
12:39:22 <ocb> is this the way it should work? ^
12:40:46 <moneromooo> Subaddresses don't have integrated payment ids. You must be mistaken.
12:40:51 <ocb> i may have not explained it correctly, if a transactionw as spent as soon as it was confirmed, #0 ring member was always the one that was the sender.
12:41:56 <binaryFate> if you spend literally exactly as soon as you can, it's impossible that there would be a newest output (it would be invalid). There might be some with the same age. But it's likely your own output will be the newest
12:42:08 <moneromooo> That sounds extremely unlikely. Evidence will be needed.
12:43:19 <moneromooo> One thing though, this was using our software ?
12:44:07 <ocb> i have repeated this 3 times, and it was always #0 ring member. since then i haven't used monero - was completely out of internet and crypto. i will do some tests in an hour-two and see if it still happens. setup remained the same except i've just updated monero. moneromooo - yes this was using monero official software however only the -cli version without gui. it was ~1.5 year ago or so. changes might have been introduced since then.
12:44:18 <ocb> i will let you know shortly if i stumble upon it again.
12:44:47 <moneromooo> Run with --log-level 2 on the wallet. If it happens again, this should give clues as to why.
12:45:15 <ocb> ok. thank you binaryFate and moneromooo for giving a heads up
12:45:17 <moneromooo> This will log private data (though not keys).
12:45:27 <moneromooo> Private data as in, which outputs are yours.
12:45:42 <ocb> got it, i will take care. thanks.
12:46:04 <moneromooo> You can encrypt it to me (my GPG key's in the tree in utils/gpg_keys) if you'd rather.
12:46:29 <moneromooo> Then upload the log to git, or paste the armoured text on pastebin or so.
12:47:47 <ocb> if i encounter it again, i will surely send you the log. either i'm super lucky to have it happen 3 times in a row.. or something was wrong. i think 0.11 was actual back then.
12:47:50 <ocb> brb
12:57:45 <binaryFate> you're not lucky if you send as soon as your previous output has 10 confirmations, that's likely to happen.
12:59:32 <ocb> binaryFate: if i understand you correctly, that's how it should work?
13:00:23 <moneromooo> No, if you send as soon as unlocked, it should be the last one with very high probability. First one is close to 0 probability.
13:01:03 <binaryFate> I assume that's what ocb meant (the most recent one was theirs)?
13:01:51 <binaryFate> if you had the oldest yeah that's definitely off
13:03:07 <ocb> ok thank you. will test in a few.
13:05:51 <Lyza> mmm that makes me think of a dumb question: why is it bad to pick ring members chronologically near the output being spent? Like, if you spend as soon as unlocked, all 11 could be really recent but if you're spending an older output then it picks a bunch of old ones. sorry I'm sure this is being discussed but I don't immediately see why this isn't the same or better as picking over a wider distribution. it obviously reveals more about the time the output
13:05:51 <Lyza> being spent was generated, but it also effectively increases the number of ring members and deals with this issue where spending an output immediately almost guarantees it to be the freshest output
13:06:11 <Lyza> has been*
13:11:36 <moneromooo> Is it bad ?
13:11:38 <binaryFate> note it's not an issue that the real output is the most recent. Still nobody knows that it is the real one.
13:12:45 <Lyza> binaryFate technically true but what are the odds of a *just* unlocked output being picked randomly? does that match the number of people who actually spend immediately? I mean, maybe it does but it seems like an edge case that could buck the overal selection distribution
13:12:56 <Lyza> <moneromooo> I assumed it would be worse since that's not what's done but Idk
13:14:05 <binaryFate> Lyza if the distribution used to pick decoy is good enough, it should reasonably match
13:14:37 <binaryFate> Then looking at a single transaction, if the real output is the most recent, it does not reveal anything particular or isn't a "less private" transaction
13:15:05 <ocb> at first i was afraid somebody could tailor a type of side channel attack around it. but my monero understanding in non existant.
13:15:15 <ocb> s/in/is/
13:16:24 <Lyza> yeah I understand that even if the distribution doesn't match it's at best a heuristic, not something that can be determined absolutely
13:19:52 <Lyza> the distribution *should* match but Ig what I'm expressing now is that outputs being spent immediately upon becoming unlocked is likely a disjoint spot on what would otherwise be a smooth function. the number of people who spend on block 10 is going to be something like the cumulative # of people who *would* have spent before that, if they could have
13:21:22 <binaryFate> Good point. I vaguely remember that it is the case (if an age smaller than 10 is picked, 10 is assigned instead), but maybe I'm confusing with an old version
13:21:42 <binaryFate> moneromooo: ^?
13:22:24 <moneromooo> If a negative value is picked, it is "re-rolled" IIRC.
13:23:04 <binaryFate> the value picked is offset to the real output age, or to current height?
13:23:31 <Lyza> "if an age smaller than 10 is picked, 10 is assigned instead" <--- this seems smart, if it's not like this already maybe something like it should be considered
13:23:34 <moneromooo> Index of either the block or output to pick, backwards.
13:25:20 <aubergine> hi guys
13:25:23 <binaryFate> Mmm I'm not sure what you mean. So if a value that would lead to a decoy with age in (0, 10) is drawn, it is drawn again rather picking one with age 10?
13:25:40 <moneromooo> I think so.
13:26:33 <aubergine> how to debug error "Request have return error: cannot load multisig_txset"
13:27:05 <moneromooo> Check if the file exists, is not empty, was saved with the same version of monero-wallet-cli, on the same arch.
13:27:11 <binaryFate> Pretty sure it would make more sense to assign 10 instead of redrawing, I agree with Lyza's point
13:27:35 <moneromooo> I'm not doing that until someone from MRL opines it's not a dumb idea.
13:27:40 <binaryFate> oc
13:31:56 <Lyza> yeah 100%
13:49:20 <xmrpow> Shouldnt the point release v17.1.6 remove the problem with the syblings?
13:51:57 <Lyza> more mitigations are forthcoming in the next two point releases I believe
13:52:12 <Lyza> it was initially said that 1.6 would remove the need for the block list but it hasn't quite worked out that way
13:53:08 <xmrpow> Ok, then it does make sense. I initially thought that I would no longer need the block list.
14:02:02 <moneromooo> You'll need it until the current asshole gets bored.
14:17:14 <aubergine> any clues?
14:31:27 <xmrpow> Im currently writing  a summary of the network attack for the people at r/monero. Just to make sure that everything is correct. Is the following logic of the attack right? Sibling pretends higher block height -> Honest nodes try to sync -> Cant sync because sibling keeps the connection  in waiting loop
14:33:30 <moneromooo> Sybils :) And yes.
14:35:13 <xmrpow> ok. Thanks ;)
16:18:01 <ocb> i will do more tests over tested, as for now it appeared as the last ring member.
16:18:21 <ocb> testnet *
16:19:03 <Lyza> does "last" mean oldest or newest?
16:22:59 <moneromooo> Newest.
16:43:17 <binaryFate> ocb please say "newest" or "oldest" instead of first/last, will be more clear
16:43:54 <cryptoexplorer> Hi, what is the meaning of the error "E Failed to set ring for x"?
16:49:11 <binaryFate> trump may pardon assange apparently
16:51:07 <moneromooo> Possibly trying to write to a DB you do not have the right to write to.
16:53:09 <cryptoexplorer> a db?
16:53:49 <moneromooo> Yes. If you meant "what is a db ?" then it's a database.
16:54:48 <cryptoexplorer> I didn't expect monero to use a database
16:55:01 <cryptoexplorer> unless you mean the blockchain itself as the database
16:55:27 <azy> the blockchain is stored in a database, LMDB
16:55:50 <moneromooo> Indeed. I wasn't on about that one though.
16:56:14 <moneromooo> There's one for the wallet, called shared-ringdb or similar, which stores the rings you've used.
16:56:32 <moneromooo> It's useful if you try to send txes, but they fail.
16:56:49 <cryptoexplorer> I am sweeping the wallet and I keep getting that error. The wallet is mine though
16:57:03 <moneromooo> You want to reuse the same things later when you spend the same output, to avoid breaking your own privacy.
16:57:29 <moneromooo> Run with --log-level 2, see if you get more info in the log file.
17:02:54 <rbrunner> The Mattermost-to-IRC bridge is, sadly, down again. Can somebody please kick it back to life? Thanks!
17:10:47 <cryptoexplorer> ok the log shows a disrupted SSL connection "E SSL handshake failed on an autodetect connection, reconnecting without SSL" and a "Failed to parse multisig tx data" warning
17:12:21 <moneromooo> FWIW, if you won't be using that wallet again, failing to save rings is not a problem.
19:15:21 <ocb> binaryFate: newest
19:23:45 <binaryFate> v0.17.1.7 binaries are now available at https://www.getmonero.org/downloads