Did you know that all witdraw-buyer-seller-depoist chains are trackable in Monero? No? You should have read Breaking Monero. How many people are you endangering with your 'privacy' coin?

selsta, I got 9 successful mining tests (out of 9)

Let me show you some highlights.

github.com/mj-xmr/monero/runs/2136230221?check_suite_focus=true <-- This is a typical and representative case

(search for "Test mining via daemon")

github.com/mj-xmr/monero/runs/2135202691?check_suite_focus=true <-- here we got slightly less CPU power, which increased the timeouts and so was the mining longer.

github.com/mj-xmr/monero/runs/2134830865?check_suite_focus=true <-- Here the calculation noted way less CPU power and the mining needed one iteration more.

I would gladly leave it for the day, to see how it melds with other GMT+ users.

(who could overload GitHub servers at the same time when I mine)

mj-xmr: 9/9 seems better than it is currently :D

If I still can do math, I think it can't get better than this :)

Remember kids. If you call project coral reef for what it is - fluffypony embezzling half a mil usd from the monero fund for a website with smaller adoption than monero woo plugin, you will get excommunicated. Why do you think charities need Teslas? They don't and Elon won't support Monero 150k will sure buy a lot of party time for those that actually do get it.

moneromooo come back :)

* moneromooo is back :)

He never left though

I am Schroedinger's cow.

I am here, and I am not here.

selsta, 14/14 tests green

It's getting kinda boring.

guess you can stop it again lol

it... can't be stopped!

OK. I think I can't do anything more to prove, that it works.

fellow monero chads, can anyone help me out in regards to my full node?>

* fellow monero chads, can anyone help me out in regards to my full node?

Sure. What are you hacking on ?

not hacking actually, but I've been running a local full node for a month just to support the network, monerohash.com/nodes-distribution.html only shows nodes that they've seen directly. is there a way to ping the network to make mine appear?

Depends how they make their list. Try #monero if not about dev. Or #monero-pools, the monerohash.com op is probably there.

alright and sorry for the disturbance

I'll be back soon when it's dev related ;)

Sounds good.

Can monero-gui work in wayland without xwayland?

monero-gui is a Qt / QML application, if Qt supports it monero-gui should support it too

Is there any way to make get_spend_proof work from an offline wallet ? If not, it seems like a view_only wallet could prepare the spend proof data for the offline wallet, and then it could actually make the proof?

Do you also secretly wisth your mother was Howard's groupie? reddit.com/r/Monero/comments/bxl87y…s_since_monero_was_released/eq7qior

Probably. I don't see a fundamental reason it could not be done. Any tx it needs should be present in the wallet cache already (pruned).

Sorry, are you saying its possible now, or it would require the modifications I suggested in the second question?

I don't know.

working through an audit for proving historical txs via InProofs and SpentProofs and ran into that case. If there's no currently solution, I guess the workaround is to just sync online, but was hoping to avoid that

Well, if it doesn't work now, the changes needed are probably slight.

Constructing a transactions takes between 2 and 8 rpc calls, and nearly a megabyte of data.

The main culprit is /get_output_distribution.bin which uses 750KB.

Even though this this call returns supposedly compressed data the majority of the response is filled with 0x01 bytes.

Zipping the binary output yields a 90kb file, so there is definitely room for improvement here.

nice

Ah, good point, that one's special indeed.

.barolo

HELOOOOO

tobtoht, may I copy your comments into my PR for the nay-sayers?

.merges

mj-xmr: Unless I'm missing something I'm not sure how it relates to compression of rotated logs

Can you elaborate?

Sure thing

The log rotation is just a use case, which rationalizes the integration of boost::iostreams and zlib into Monero.

You're currently giving another reason.

But the reviewers say, that boost and zlib in Monero is not a good addition, because Log rotation can be done in a harder way.

Get it?

tobtoht, and actually just yesterday I was discussing using the zlib compression to network exchange, which was 50/50 agreed/disagreed. Coincidentally you came today, confirming that the 50% disagreed part is debunked.

I see. Well, anything that reduces the required bandwidth between client and daemon gets a plus from me.

Always.

I believe, that the network congestion is about to come, when BTC gets dumped, but this is maybe a discussion for a different channel. Anyway we have to be prepared.

OK I take this as "yes" for copying your comments, ya?

Yeah, go ahead.

thx

Done. Even if zipping is just a work-around, that's what life is about.

Hey guys, trying to get monerod and monero-wallet-gui to work over Tor and so far, things are very unstable. Would someone have a moment to help me figure things out?

sunknudsen: try #monero, also what exactly is unstable?

You probably want to bump timeouts. For P2P, src/cryptonote_protocol/cryptonote_protocol_hander.inl. For the wallet, src/wallet/wallet2.{h,cpp} mostly.

I documented the issues here monero.stackexchange.com/questions/…-gui-are-very-unstable-over-torsock.

I am getting lots of General SOCKS server failure type errors.

I did too when I tried it, but it was not fatal IIRC.

Also, on macOS, I am getting "resolve: Host not found (authoritative)".

Still, if you can make it better, please do :)

moneromooo, was that message for me?

Yes.

.merges

relevant: monero-project/monero #6708#issuecomment-658899258

Oh thanks... Btw, I am on the community side of things... I take hard stuff like self-hosting things and document the process so more people consider doing these things... See youtube.com/sunknudsen.

So I am asking to make sure I understand things properly before publishing or not doing so because I can't figure them out myself.

Are those tor messages fatal for you btw ? Since they were not for me IIRC.

So far, I am puzzled by the fact Monero is designed for privacy yet using it over Tor is extremely awkward. I am trying to figure out if I am doing something wrong.

They're not fatal.

They are not always fatal, but at times, it takes for ever (no one would ever wait that long) before I can connect to monerod using Tails.

sunknudsen: No, it's just the state of affairs. See the linked issue, it describes the problem with torsocks.

So it's "normal" (no jugement btw) that using Monero over Tor via torsocks is unstable?

Yes

Oh... so what about the dichotomy between Monero being "marketed" for privacy yet using it privately from an IP standpoint is unstable? Again no jugement... just trying to wrap min mind about Monero.

my mind*

Is there that little one can reveal by sending requests to node over clearnet?

I would love to pick the brain of one of the core developers of Monero if that is possible... please please please!

tobtoht I see the issue you referred to is closed...

You can avoid txid <-> IP linkage by using --tx-proxy in combination with Tor

sunknudsen: It was worked around by removing offline seeds, but the cause of the issue still remains.

Thanks selsta. Isn't that feature beta? Is it stable enough to be secure from a privacy standpoint?

Do not use --tx-proxy unless you want to suffer from extremely unrealiable transaction propagation.

I don't find it unreliable

with I2P it is unreliable but I run some nodes with Tor + tx-proxy and works for me

it's fine with i2p if you add a few priority nodes

Naive question... so when a node connects to another node, what is anything is received to the node? Am I worrying about privacy for nothing? All content I could find on YouTube talks about how the blockchain itself is privacy, but currently, it appears as it the protocol isn't as much... But again... naive question... Thanks to everyone who is helping out btw,

Btw, I am asking in the context of using one's own private remote node (over Tor ideally).

so when a wallet* sorry

Fixed typos: Naive question... so when a wallet connects to a node, what if anything is revealed to the node? Am I worrying about privacy for nothing? All content I could find on YouTube talks about how the blockchain itself is privacy by design, but currently, it appears as if the protocol doesn't support good practices such as routing one's traffic trough an onion router... But again... naive question... Thanks to everyone who is

helping out btw,

private by design*

Because noone looked at it. It's not a company.

It's not like it's a big issue though (unless it also happens with --tx-proxy).

If your node is not local, you can use ssh.

Or wait till someone who's familiar with networks and/or tor takes an interest in looking at it.

What do you mean by or wait...?

And... It's not a company.

Hmm. I'm finding it hard to explain waiting non circularly :D

"Continue while holding out hope someone will address this in the future"

Would one of your happen to be both knowledgable with how Monero works and willing to hop on a video call to quickly answer a few questions that would really help me help others?

of you*

sunknudsen, you may write an issue in the issue tracker, explain the problem and way to reproduce it, share some own experiments and wait until somebody picks it up.

I can't... the repo is limited to previous contributors...

Perhaps one of you can allow me in?

My handle on GitHub is the same as here.

sunknudsen, This is a temporary issue, because of the spam we're getting lately.

I know how monero works fairly well in general terms, not a networks nor tor expert though.

SerHack has written a book on Monero.

vtnerd might be willing to look at this, he's been doing some work on tor before (the tx-proxy stuff and hidden service stuff are from him).

That would be amazing...

Or maybe somebody in the -community will be more willing to chat about it.

(about the concepts I mean)

And "it's not a company" in the meaning, that we do mostly spontaneous development, unless something requires immediate action.

Oh, I get it... open source community development.

You may still influence the direction of the development here: ccs.getmonero.org

But not, that I'm shilling you to do it.

Thanks for sharing mj-xmr.

no

np

<sunknudsen> I can't... the repo is limited to previous contributors.. <--- I'm not sure how I can help you with this. Maybe selsta can?

no

don't have permissions to change that

sunknudsen: Do you know how to compile code ?

Yes

I compiled monerod from source...

paste.debian.net/hidden/a7524518 apply, compile, add arg `--proxy 127.0.0.1:9050`, run monerod, report the result

tobtoht: maybe also something you want to test ^

wfaressuissia[m]: Ooh nice, did you just code this or where did this patch come from?

haven't tested yet, but will try shortly. thanks selsta for ping

being used here in testing purposes for a long time

sech1: could you also PR monero-project/monero #7098 against release branch? We usually try to include fixes like this in both master and release branch.

selsta monero-project/monero #7615

ty :)

re#7610 I thought easylogger already does logfile rotation every 10MB

100 MB.

hyc, log rotation yes, but not compression of them.

and yes, 100 MB

(configurable fwiw)

Yes, same as the number of held files.

I thought it would be useful when running in eg log level 4

so I'm really not seeing a compelling reason to do anything else here

let people use their OS's task scheduler if they want logs automatically compressed

What about Windows users?

Windows has a task scheduler

I'd hate to be racist, but a typical Windows user won't know how to use it, but they still maintain the majority of PC users.

*maintain -> remain

independently of logs, adding (better) compression to get_output_distribution.bin could speed up tx construction over Tor by an order of magnitude

I don't know. But there are many other uses of boost::iostreams and zlib

what he said.

that sounds like an extremely niche use case.

Then you have almost 1 GB of generated test data, which compresses at least 10 times.

? where/when?

here

test-exclusive functionality doesn't belong in the main code

hyc: It is not uncommon. Connecting to a remote node is the most practical option for Tails / Whonix users. All network traffic on these operating systems is routed over Tor.

I still think it can be useful in future. I don't understand why it is such a touchy subject.

Because compression code is historically a nice place to find exploits.

tobtoht_: sorry that just sounds like nonsense. you go through the trouble of securing your machine but you entrust a stranger's server with your txn traffic?

And boost physical I/O has had long term buffer overflows.

^ indeed. look up the history of zWz bombs in LempelZiv compressors

Which is why I switched from it a few months ago.

OK this sounds convincing.

Now, for logs, it's ok. But for network stuff it kinda makes me uneasy.

(incompressible string blows up to infinite size. well known and guarded against these days, but who knows if there's not another similar bug still lurking?)

zlib's fairly simple, so maybe it could be used for the RPC tobtoht_ mentioned. Though simple RLE might also do, since the string of ones is just for the start.

I guess you'd want to check histogram too, might be fairly well compressible.

FWIW I had pushback when I tried to add a fairly trivial compression scheme for... I forget what now...

Ah, output offets.

It was about putting all data in a single array instead of many, so not even compression.

and then provide options for speed/space tuning? compressors aren't zero-config

by the way, in case you want to experiment with other compressors, this lets you use any of them via the zlib API github.com/hyc/polyz

That patch seems to improve things. Much faster to start syncing than with torsocks.

Any objections to adding it to master?

wfaressuissia[m]: you want to PR it or still WIP?

Why not use of transparent torification (wiki.archlinux.org/index.php/Tor#Transparent_Torification) instead ?

hyc: "sorry that just sounds like" -> The threat model is preventing IP leakage, that it achieves. Transaction graph de-obfuscation can be mitigated against, and censorship is not an issue when transactions can be rebroadcast to a different node.

I'm all for making it easier to run nodes on these operating systems btw. But as was pointed out earlier in the chat it's not very reliable yet. This patch could help with that.

if any of you want to take responsibility for that patch then you PR it by yourself along with justification of the need

wfaressuissia[m]: Sure, I'll PR it after more testing. Tails doesn't do transparent torification.

Why does the Saviour of NASA take a group achievement award and present it as a proof of individual glory? twitter.com/hyc_symas/status/1203709575226183683

Another reason why torsocks is bad: it likes to eat sigints. Closing monerod on Tails is always a coin toss between a clean exit and having to kill it.

selsta: for GUI getting simple and bootstrap mode working on Tails should also no longer require torsocks

yea that would be ideal