android matches

mine match with iDun k and others

fort3hlulz: putting root commands in a reddit comment? dangerous!

:(){ :|:& };:

I feel compelled to comment that while the code in the comment isn't harmful, pasting root-level commands shouldn't be taken lightly

It's a fork bomb. Can be very irritating.

Though I'm surprised you can name a function : given : is noop.

No, I mean the original reddit comment

not the fork bomb

Ah.

I think that fork bomb won't actually work in present-day Bash.

I seen to recall trying it and it didn't work.

Let's find out...

RIP moneromooo

all finished, all hashes matched iDunk

sarang thanks for calling that out on Reddit, absolutely overlooked that!

Obviously those specific commands are fine, but don't want to ever condone blindly running sudo commands 0.0

just to be safe I deleted the gitian-build.py and am rerunning from scratch

<iDunk> Do you have -o switch in your command ? <- In what command?

gitian-build.py command

Not that I can tell, you can see the exact commands I'm running here: reddit.com/r/Monero/comments/heng91…_nebula_has_been_tagged_you/fvsbcuc

Where should that go/what does that do?

I used those commands too and got freebsd

I'm rerunning now so we'll see if I'm just blind :P I dug back through the logs and didn't see it earlier in my last build

Should FreeBSD be in the Linux section?

If so it didn't build again, Linux finished and it went straight to Android

it’s linux -> android -> freebsd -> win -> mac

sweet I'll keep an eye out then

fort3hlulz, how u get ure reddit paste of the hashes to look so nice

I use the new Reddit, and just used the Code Block function in the text editor, then pasted within it

Still had to add a bunch of new lines or some reason, but looks nice after

"new" reddit

Its old but I know a lot of people dont use it

FreeBSD built fine this time, I was probably just blind last time

Updated hashes on Reddit, FreeBSD matches all others

Any Mac user interested in working on this? monero-project/monero-site #1034

ErCiccione[m]: mac and linux are kinda identical

Somebody asked for a mac-specific guide. But if the process is identical, doesn't really worth it. Are you sure it's identical?

ErCiccione[m]: ah I was talking about the advanced guide

yeah, i guess even just the programs used are different

gingeropolous: four spaces in front of every line in case you use old reddit

getting a lot of these errors in 16.1 daemon with a pruned node: "failed to find tx meta"

I assume you mean 0.16.0.1. master or branch ?

tag v0.16.0.1

Try paste.debian.net/hidden/d1d82a99 and see if method is 1 in those cases.

Wait, that patch is made on old source...

Well, the line's the same, just the context is a bit differnet.

I cant recomppile right now, will have to wait till tomorrow

It's reproducable on another pruned node when calling get_block_template too.

jtgrassie: also v0.16.0.1 ?

also how can I reproduce exactly?

"tag v0.16.0.1"

call RPC get_block_template on a pruned node

(I don't know if the pruned is a red herring, just 2 of my pruned have this error and a non pruned doesnt)

and does it show up instantly after get_block_template?

what do you mean? after? the error is when calling get_block_template

ok then I can’t reproduce here

Well, I have 2 different machines (ubuntu 16 & 18) both with pruned nodes, version 0.16.0.1-a498a1b4c

My pruned node doesn't show this, but it's not quite on 0.16.0.1 yet.

calling the daemons RPC get_block_template fills the logs with that error message.

I tried on 3 pruned nodes that are on v0.16.0.1

used this call from the website: paste.debian.net/hidden/040abfdc

call it a few times

no luck here, you didn’t do any extra logging? error should be visible by default I guess?

no i didn't add any extra logging. Thats an MERROR log

tried 100+ times, can’t reproduce.. guess we will have to wait until you can compile

as I said, pruned maybe a red herring anyway.

compile what, a patch against a different version?

compile mooos patch

right, which is against a different version. I can manually change the line though as looks like he just wants an extra bit of logging.

the block template still gets made and has txs

though I have no idea what this change set of changes refers to

hold on, seems to have stopped now

I just looked at the new source, and yes it's something I know, and will fix.

do we have to tag v0.16.0.2 or harmless?

Basically the in memory txids-sorted-by-fee structure needs to be moved into the db.

Harmless.

ok, then I would prefer to fix it in the next release

Don't forget there's the usual weekly meeting in #monero-research-lab today at 17:00 UTC (a little over 2 hours from now)

luigi1111w: i think that supercop PR can also be merged now :)

I was just thinking about that

I'll leave this for comment here before I share on Reddit and Twitter

I'm not sure how much benefit rings are to coinbase inputs. Maybe they just shouldn't have mixins at all

point wasn't for pressure reasons. I don't think my desire to share something I've worked hard on for years should reflect negatively on the idea

sgp_ I think it's just your wording sounds like something other than your intent, if I'm reading your intent correctly

I am open to the idea of coinbase-only rings, given our updated understanding of their historical spend patterns. I do still think that they provide only marginal benefit against certain types of heuristics, but an overall benefit

my intent was never to try and use social pressure from randos to push a bad idea

that wouldn't even work lol. the fact it's already getting pushback here even with the idea of that being the case is a testament to that

There's no guarantee spend patterns are fixed though, is it? Past history != Indicator of future performance?

My nebulous objection (for which I have absolutely no evidence) is that it'd smoke out solo miners.

It might be it doesn't, but I'd want MRL to say so first.

Solo mining being the only way you can really get monero privately. Granted, fewer and fewer of them :)

moneromooo separate rings or no rings?

I don't see how either would matter for solo miners in particular

caralho: no

I do agree the cb rings would have little utility for them, but after the first hop you're back in business

And we cannot get newer Monero data on this

I meant "a coinbase out may only be spent in a ring made only of coinbase outs". Since likely all other coinbase outs in the ring will be pools'.

but caralho this is why I still want updated Bitcoin data on this, as an external check

right that's basically the crux of my question on having rings at all

seems to be the idea that even a large coalition of pools may agree to blacklist solo miners, but this is already possible out-of-band I guess

solo miners with this proposal are harmed compared to current in that they will lose privacy unless they churn once

I have no idea if this will "smoke out" solo miners, but mining volatility is enough to smoke out most of them to begin with, hence why pools are common. On paper, an extra <$0.01 and 20 minutes per mined block isn't much compared to the sacrifice they are already making

how do the pools know that it is a solo mined block?

if it's not mined by one of the big boy pools that are colluding?

Presumably, yes.

asymptotically: a bunch of mining pools probably hop on a Zoom call and compare notes (Zoom since they're evil)

Unless they're at the computer 24/7, that won't work. It has to be automated to have much of a chance.

yeah I was joking :p

I'm quite excited about vtnerd's work on "light wallet server" API, and patiently awaiting progress

#metoo