would changing --public-node to --public-rpc-node muck things up much?

luigi1111: When tag? :-P

fluffypony, Snipa: Perhaps available to set the tag?

tag tag tag

you're it

Guten Tag.

ideally.

tag is up for those doing reproducible builds

yay

What kind of person steals from own community?reddit.com/r/Monero/comments/6d5yt5…/what_fluffypony_just_did_is_not_ok Your own leaders are laughing at how moronic you are for falling for thier 'Magical Crypto Friendship'.

Has anyone started reproducible builds yet? I want to try it today, any link to instructions?

mine just finished

just read contrib/gitian/README.md

Ok, I'll try today with Ubuntu 18.04 VM

gitian supports docker and lxc, but I think it's easiest to use docker

sech1: half way

hyc wowario I'm running the build in a VM (6 cores of Ryzen 5600X). How long should it normally take?

2 hours ~

<selsta "tag is up for those doing reprod"> Started, will try to PR signed hashes for the first time today!

still running, but at least I have the same hash for monero-x86_64-linux-gnu-v0.17.1.8.tar.bz2 (I haven't checked others yet)

Running v0.17.1.8 without the ban list on my node now

my hashes: paste.debian.net/1179027

thanks hyc, iDunk, sech1

I just noticed I don't have Apple build. Do I need to do something more to build it?

Is the block height off by 2 issue still around? Still seeing it with commit 36dfd41e0 (and no ban list)

looks like it

yes, my 0.17.1.8 node got +2 issue and hasn't banned any IP so far

hmm, and it's back to normal again

Height: 2263568/2263568 (100.0%) on mainnet, not mining, net hash 1.67 GH/s, v14, 64(out)+22(in) connections, uptime 0d 1h 24m 25s

We don't care much now since the gui was fixed.

I'll apply the ban list anyway (the one without tor IPs)

Probably helps to apply ban list for everyone else, so you don't advertise bad nodes to people who might not be on latest version

moneromooo: you mean the gui,cli wallets can tolerate the off by two? If so can you explain how?

I'm using the ban list that does not include tor nodes, to help tor users. No issue so far with latest tag

binaryFate: where is that list?

coffeeroaster: gui.xmr.pm/files/block.txt for bad nodes, and gui.xmr.pm/files/block_tor.txt for bad nodes + tor exit nodes

15:44 <moneromooo> We don't care much now since the gui was fixed. <-- it was not fixed yet, we wrote some code for it but with the memory attack I did not look into it further

coffeeroaster: did you check if the +2 nodes get kicked after a while?

selsta: I had it running for the past 9 hours or so and off by one still there. Didn't see any evidence of bans. Btw how do I check the block height of each peer?

sync_info

we had to revert a fix that was related to the +2 attack because it had issues with reorgs

we focused on getting a release out because of the oom attack

selsta: makes sense. wow 10/13 of peers (from sync_info) are in the ban list

10/12 rather

It did kick +2 nodes in the past days so I wonder if they changed behaviour again

selsta: might be interesting to add more detail in "sync_info". Are there other tools to detect anomalies?

coffeeroaster: weird... they do get kicked on my node

after like 15 seconds

Same here, I see the +2 only intermittently, doesn't last long (~15s)

yes, I saw +2 and then it vanished. Running with the ban list now

whoops sorry team

huh I'll do a new build to be sure then.

Love Windows anti virus deleting stuff while I’m trying to do binaries :D

i just compiled v0.17.1.8 and i still get synchronized OK spam

4000 lines outta the last 10k lines

4000 times?

yep

maybe these are old logs?

i noticed it cause i'm tail -f bitmonero.og

I have been running it for the past days without ban list and don’t get it.

which log level are you running?

an ip just got blocked

yeah sorry old logs. but i was getting it recently, and then it got blocked, and it stopped, so yay

Running without the ban list again, so far so good. No synchronized OK spam, no +2 issue.

is it easy to try out a reproducible build under docker?

Inge- not that hard, just create Ubuntu 18.04 VM and follow the instructions github.com/monero-project/monero/blob/master/contrib/gitian/README.md

I had one small issue when the script couldn't connect to /var/run/docker.sock (permission denied), but I solved it by chmod 666 /var/run/docker.sock

I use ^ in a fresh 18.04 VM

And this VM will need more than 10 GB space (VirtualBox default), mine ran fine with 25 GB

sech1: so I can't just run a docker container in say a 20.04 box

Inge- I don't know, the instructions say 18.04 specifically

maybe it will compile fine in 20.04, but with different hashes

yeah that would kind of defeat the purpose.

afaik some people use 20.04 for host

I

I'll give it a spin. won't hurt to try.

update: clean build looks much better. Haven't seen the +2 error yet

still probably only a matter of time until the attacker changes his method and it comes back

But what's the point of continuing +2 attack if GUI has been fixed?

I'm expecting something new on New Year's eve :D

it does not have it fixed

we have the code but I did not have time to fully test it

and the ui was not optimized for it

so it looked weird

But but <moneromooo> We don't care much now since the gui was fixed.

we didn’t include it in the release

seeing regular stack traces in the logs with "allocLargePagesMemory". (also running on non-standard hw RPI4 64 bit)

you need to allocate more huge pages to fix these stack traces

selsta then +2 attack will probably continue. I don't really care since I use CLI, but I'm curious how the attack will be carried out this time.

Height: 2263636/2263636 (100.0%) on mainnet, not mining, net hash 1.65 GH/s, v14, 64(out)+20(in) connections, uptime 0d 1h 29m 9s

This is without ban list, so far

Looks like +2 attack doesn't work on 0.17.1.8

But I don't see any banned IPs either

sech1: I'm seeing the same (with no bans). Can you elaborate on how to "allocate more huge pages"?

sech1: like I said, we had to revert the +2 fix so they might get kicked because they also try to do the "synchronized ok" spam.

we will see

coffeeroaster sysctl -w vm.nr_hugepages=2048

I use this on my node, but I run both xmrig and monerod

you need to allocate as few huge pages as possible because unused pages will just sit in memory, leaving less free

They only get allocated if the mmap flag is set ?

if you change vm.nr_hugepages, they'll be always in the memory, just not used by any process

and of course my kernel doesn't it

my hashes: paste.debian.net/1179051

everyone doing hashes please also submit to github.com/monero-project/gitian.sigs/pulls

Is there latest instructions for the gitian builds?

I'll kick one off today.

I use irccloud.com/pastebin/m3f2mEuk

but I run that inside a VM that I later delete again

Thanks.

trying to gitian build monero but something didn't work out: paste.debian.net/1179056

mfoolb: did you follow the readme or the steps I posted?

I followed this: github.com/monero-project/monero/tree/master/contrib/gitian

can you compare with irccloud.com/pastebin/m3f2mEuk to see if you did anything different?

I'm using Ubuntu 18.04

I forked and cloned the gitian.sigs too

didn't do your 11 and 12

?

11?

ah sorry, misread

row number on your paste

that's what I did: paste.debian.net/1179059

I think you need to add --docker to the last line

sure I do

sorry about that

Man that OSX cross-compile takes awhile.

Snipa: it's probably me but I started from scratch again just to be sure and it stops a bit later: paste.debian.net/1179066

in builder/var/base-bionic-amd64.manifest I find: Reinstallation of linux-modules-extra-4.15.0-126-generic is not possible, it cannot be downloaded. + linux-modules-4.15.0-126-generic and linux-image-4.15.0-126-generic)

Mine's working fine, just not running the build in parallel for some reason.

How do I know what the actual method name is for that request?

I tried curl 127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"blocks_by_height","params":[1,2]}' -H 'Content-Type: application/json' and curl 127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_blocks_by_height","params":[1,2]}' -H 'Content-Type: application/json'

Or more correctly, it is, just not in an obvious way.

grep this in core_rpc_server.h

Mmmmmmmmmm: see web.getmonero.org/resources/developer-guides/daemon-rpc.html

I tried thinking the more doing gitian builds the better but I failed for different reasone with 0.17.1.6 0.17.1.7 and 0.17.1.8..

Oh, "Not all daemon RPC calls use the JSON_RPC interface." That part is key. Thanks ndorf

mfoolb: can you post the exact command you used?

./gitian-build.py -j 3 --memory 6000 --docker --detach-sign --no-commit --build mfoolb v0.17.1.8

mfoolb, what is your host system?

ubuntu 18.04 on a vm

is the ubuntu on bare metal?

people have had issues with using virtualbox on a mac... that's what i'm getting at

vm with qemu on ubuntu 20

vm with 18.04.5 LTS over 20.04.1 LTS to be precise

Why not just do it natively instead of in a VM?

If you’re running Ubuntu already its simple to just do it natively.

It all happens in Docker containers so the host doesn’t matter as long as you have Docker.

I use a VM so every time I can start again from zero and I prefer not to mix those two systems

anyway I thought most of you used vm's for gitian builds

You can always start from zero if you just clear out Docker afterwards.

I build reproducible on an Ubuntu 20.04 server with no issues.

i use VM because i don't want to install docker on my host. but i haven't tried .8 yet

didn't have any issues with earlier releases, though

also using qemu/kvm

and last but not least in github it states clearly: Gitian host OS should be Ubuntu 18.04 "Bionic Beaver".

Thats what the Docker containers use as a base — that doesn’t need to be the host for Docker itself.

ndorf: 0.17.1.7 couldn't work.. was missing some packages giving 404

yea that was fixed

Thats the whole point of doing it in Docker — the host OS doesn’t matter.

afaik there are some things done on host OS but 20.04 is fine

well I can surely stay away from vm's but not in that system.. I could try on another one tomorrow

next time you try ignore the readme and try following the paste I posted line by line

My exact commands from an Ubuntu 20.04 base: paste.centos.org/view/c745d210

that is what I usually do

selsta: that was for MAC OSX, wasn't it?

I mean the last curl

selsta: thanks I'll try those..

sethsimmons: could you explain to me this one curl -O bitcoincore.org/depends-sources/sdks/MacOSX10.11.sdk.tar.gz ?

It’s a necessary dependency for the OSX builds AFAIK

Should only need to download it once unless you wipe all the directories after building for some reason.

ok

not trace of this on github

If you don’t build OSX you don’t need it.

i did the build on a fresh 18.04 ubuntu droplet on digital ocean

it does say "Note: if you intend to build MacOS binaries, please follow these instructions to get the required SDK." but yea could be explained better

mfoolb: i'll fire it up in my VM shortly and let you know if i run into any trouble

ok thanks.. consider I started from scratch.. I mean gitian.sigs fork and clone too

oh this is interesting, my old .7 daemon doesn't seem to want to exit on SIGTERM

mfoolb: you can fork gitian.sigs after you are done with building the binaries

ok

sethsimmons: it surely is me .. I tried on Ubuntu 20.04 LTS.. you exact commands.. I received: bin/gbuild:23:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)

build.log shows: paste.debian.net/1179081

Hmm not sure what to make of that, the builds worked fine for me on .8 but I don’t know how to debug actual build issues

mfoolb: there's no error message in your build logs

hmm

addedd some lines on top

ok yea you are running out of ram

try less parallel jobs

-j2

I'll do.. I used -j7 --memory 14000 on a 3900x with 16gb

what did you set your VM to?

or no VM?

no VM this time

ok, yea try -j4

rebuild or still build?

I don't know. Never used rebuild

ok

Binaries for new version 0.17.1.8 are available on getmonero.org

Thanks to everyone who contributed to this one way or another!

:o

binaryFate: thanks to you

I'm merely stamping the crazy work of others

"crazy" as in impressive, and "crazy" as in actually crazy round the clock in the last days and nights

yes, we followed the situation and hard work put into it

Interesting, +2 malicious nodes connect and get kicked quickly: paste.debian.net/1179092

I assume they get kicked because they also do "syncrhonized ok" spam

we will see

satisfying: paste.debian.net/hidden/e8896752

looks like the cli linux 64 version has not been updated on the website

downloads.getmonero.org/cli/linux64 give you .7 not .8

you might have the old version cached

we still have the website setup wrong, we should remove local caching for redirect

that was it.

thank you!