Maybe you have some overly restrictive --up-limit or --down-limit in your monerod config?

Or very bad quality signal/lots of interference on your local network

Or some bad firewall/routing rules

endor00[m], no limits set for monerod, regular file transfers work at full gigabit speed in both directions.

bobandback, if your running the new release, you need to modify your rpc bindings

well wait. what u have might be ok.

bah, i better update that info on moneroworld

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.

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.

i thought it just launches the node with those configured parameters.

wait, are you trying to connect the GUI to a remote node?

or are you running monerod on the same computer as the GUI?

running monerod and GUI on same system.

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´.

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.

yeah that is weird

I would guess not many would run a public node from within the GUI, so maybe it´s a bug that has gone unnoticed?

perhaps yeah. what OS?

and is this v0.17.1.6?

ubuntu, yes 0.17.1.6

ah gui on ubuntu...

something seriously wrong at google, both youtube and drive are down

gmail too

Good. Next step, Cloudflare.

Everything google is ded

But youtube werks in private mode (not logged in)

google down, good for humanity. next facebook, let's do it.

hello

binaryFate: seems to be back, rumour is their account lookup was returning partial json which broke anything downstream trying to us it

interesting

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

is this the way it should work? ^

Subaddresses don't have integrated payment ids. You must be mistaken.

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.

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

That sounds extremely unlikely. Evidence will be needed.

One thing though, this was using our software ?

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.

i will let you know shortly if i stumble upon it again.

Run with --log-level 2 on the wallet. If it happens again, this should give clues as to why.

ok. thank you binaryFate and moneromooo for giving a heads up

This will log private data (though not keys).

Private data as in, which outputs are yours.

got it, i will take care. thanks.

You can encrypt it to me (my GPG key's in the tree in utils/gpg_keys) if you'd rather.

Then upload the log to git, or paste the armoured text on pastebin or so.

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.

brb

you're not lucky if you send as soon as your previous output has 10 confirmations, that's likely to happen.

binaryFate: if i understand you correctly, that's how it should work?

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.

I assume that's what ocb meant (the most recent one was theirs)?

if you had the oldest yeah that's definitely off

ok thank you. will test in a few.

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

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

has been*

Is it bad ?

note it's not an issue that the real output is the most recent. Still nobody knows that it is the real one.

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

<moneromooo> I assumed it would be worse since that's not what's done but Idk

Lyza if the distribution used to pick decoy is good enough, it should reasonably match

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

at first i was afraid somebody could tailor a type of side channel attack around it. but my monero understanding in non existant.

s/in/is/

yeah I understand that even if the distribution doesn't match it's at best a heuristic, not something that can be determined absolutely

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

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

moneromooo: ^?

If a negative value is picked, it is "re-rolled" IIRC.

the value picked is offset to the real output age, or to current height?

"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

Index of either the block or output to pick, backwards.

hi guys

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?

I think so.

how to debug error "Request have return error: cannot load multisig_txset"

Check if the file exists, is not empty, was saved with the same version of monero-wallet-cli, on the same arch.

Pretty sure it would make more sense to assign 10 instead of redrawing, I agree with Lyza's point

I'm not doing that until someone from MRL opines it's not a dumb idea.

oc

yeah 100%

Shouldnt the point release v17.1.6 remove the problem with the syblings?

more mitigations are forthcoming in the next two point releases I believe

it was initially said that 1.6 would remove the need for the block list but it hasn't quite worked out that way

Ok, then it does make sense. I initially thought that I would no longer need the block list.

You'll need it until the current asshole gets bored.

any clues?

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

Sybils :) And yes.

ok. Thanks ;)

i will do more tests over tested, as for now it appeared as the last ring member.

testnet *

does "last" mean oldest or newest?

Newest.

ocb please say "newest" or "oldest" instead of first/last, will be more clear

Hi, what is the meaning of the error "E Failed to set ring for x"?

trump may pardon assange apparently

Possibly trying to write to a DB you do not have the right to write to.

a db?

Yes. If you meant "what is a db ?" then it's a database.

I didn't expect monero to use a database

unless you mean the blockchain itself as the database

the blockchain is stored in a database, LMDB

Indeed. I wasn't on about that one though.

There's one for the wallet, called shared-ringdb or similar, which stores the rings you've used.

It's useful if you try to send txes, but they fail.

I am sweeping the wallet and I keep getting that error. The wallet is mine though

You want to reuse the same things later when you spend the same output, to avoid breaking your own privacy.

Run with --log-level 2, see if you get more info in the log file.

The Mattermost-to-IRC bridge is, sadly, down again. Can somebody please kick it back to life? Thanks!

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

FWIW, if you won't be using that wallet again, failing to save rings is not a problem.

binaryFate: newest

v0.17.1.7 binaries are now available at getmonero.org/downloads