Hey guys! Is there any way to disable banning hosts on rpc errors? this is really annoying

Not without changing the source I think. Why is it annoying ?

Because this is our public node (for stagenet in this case). We test api, we test wallet. It happens quiet often we get an error

Moreover it stands behind nginx and therefore the only host is sending the request is ... nginx server!

in this case rpc stops working at all

I think you can disable this in src/rpc/core_rpc_server.cpp, by removing: m_net_server.set_connection_filter(&m_p2p);

of course I can modify the source code. but this will cause troubles in the future when updating public node

right now my public node has RPC spam from over 100 addresses being auto-banned

removing the ban feature would be pretty bad

perhaps tweaking it to exclude localhost would be OK

what about making optional command line flag to disable rpc banning?

excluding localhost would help only if you have your nginx on localhost

You know there's a RPC to unban an IP, right ?

My node shows `Transaction spends at least one output which is too young`, I guess that means someone changed the 10 block lock time in source and my node rejected it?

Guess it doesn't work if it's been banned though pu:D

I thin so.

> You know there's a RPC to unban an IP, right ?

no, i didn't. should i call it by timer?

If you want to. Not from the testing IP though.

localhost should work fine for that

and what if your nginx proxy is on another host?

you don't need to issue the unban RPC from the same host as your nginx box

in fact you woouldn't be able to. come on, think about it.

in fact, all of the requests are coming from nginx this way. of course i wouldn't be able to call unban

so once again - use localhost

do you mean deploy monerod on the same host with nginx?

no

issue the unban request from the same box that runs monerod

call rpc from localhost?

I understand that. But the problem is there always be situations when some can make malicious calls to stop entire rpc working

entire rpc?

how can someone else make malicious RPC calls from your nginx host?

because users are working with it through nginx interface and the only client to monerod rpc interface is nginx's host in the particular setup

Sounds like we should support PROXY protocol for RPC

I have a feeling all remote users are being proxied through a single host, and moenrod only sees that proxy host.

ah

yes, exactly

So, self inflicted wound :)

indeed

sorry if i undestand it poorly

*explained

omartijn: link to an explanation ? "proxy" is going to match loads of irrelevant stuff :)

ty

Basically it's an efficient way of forwarding connection information from a proxy to the underlying backend

btw, what is the rpc call to unban host? :)

i can't find it in the sources

set_bans

thanks

hey guys

quick question

on wallet create_address RPC call

when was "address_index - unsigned int; Index of the new address under the input account." added?

2017-02-19

You can find yourself with: git blame src/wallet/wallet_rpc_server_commands_defs.h

thanks!

is there any security concern of showing that to the users?

If you're asking "can someone steal money from this info", then no.

because monero-python library didn't return that until the latest version, and they really didn't alert of this change, so I've generated around 20 addresses and showed that to the users

If you're asking "can people glean info about my customer base", then yes.

ah alright

good

woodser: if you can get me scripts to build boost/openssl etc with emscripten, which you likely have already if you're building monero, I'll try to fix the monero source :)

boost is supposed to build with --toolset=emscripten, but 1.71 rejects this :/

does your boost source tree have tools/build/src/emscripten.jam ?

I have it in 1.69 tree

No, but it has tools/build/src/tools/emscripten.jam.

ah yes, that.

so that ought to work

Maybe they moved stuff and broke it...

I can try 1.69.

unless that's only support for compiling their b2 program

which would be kind of useless all by itself

Still though, I don't want to waste my time figuring out how to build random dependencies. Only monero :)

yeah, not much fun in that

<woodser> I use this process to build boost: 1. cd <emscripten_root> 2. ./emsdk install latest-upstream (their development is now focused on their upcoming upstream release) 3. ./emsdk activate latest-upstream 4. source ./emsdk_env.sh 5. export EMSCRIPTEN=<emscripten_root>/emscripten/emsdk/fastcomp/emscripten 6. Invoke this shell script:

github.com/monero-ecosystem/monero-…_send/bin/build-boost-emscripten.sh 7. Which uses this emscripten.jam: github.com/monero-ecosystem/monero-…3_after_send/configs/emscripten.jam

<woodser> credits to mymonero for the script scaffolding

Docs say "latest", not "latest-upstream", you sure about this ?

<woodser> IIRC I was not able to get openssl building with boost, but endogenic said they were able to

yes

with emscripten, nothing to do with boost

(I already did steps 1234, but with latest)

woodser look at mymonero-libapp-js for openssl w emscr

it did take some time to make it happy

but it ended up working

<woodser> I think you can use “latest”. I was using “latest-upstream” to access their new upstream features

Well, it's busy installing latest-upstream atm. Maybe it'll help.

you're welcome..

Well, still no emscripten file/direcory in the single directory called fastcomp. Or is it supposed to be that way and it gets created later ?

<woodser> hmm

<woodser> <emscripten_root>/emscripten/emsdk/upstream/emscripten?

Yes, I have a src/emsdk/upstream/emscripten

<woodser> that’s probably what you want. fastcomp must be the old one

ty

<woodser> sure

Well, it seems to be going now, thanks.

<woodser> great

Heh: First, Building Boost.Build engine with toolset gcc..., but then /bin/sh: line 1: clang++: command not found

<woodser> might need to change “clang” to “gcc” in the .sh and/or .jam

Maybe. It's going with clang now. I saw "cat: /home/user/configs/emscripten.jam: No such file or directory", but it was not fatal.

Finished already. Suspiciously fast.

got any actual .a files ?

<woodser> it doesn’t take very long on my machine. That script is only building these as-is: system,thread,chrono,serialization,filesystem,regex

Yes.

so this db bug, should i use the systems libunbound to make it happen?

<woodser> moneromooo if it helps, this is my latest branch of monero-project which supports wallet2 refreshing and getting balances and transfers in webassembly: github.com/woodser/monero/tree/wasm49_update_pool_state

Thanks. I'm searching the web for libzmq-with-enscriptem atm. Not there yet.

17:33 <gingeropolous> so this db bug, should i use the systems libunbound to make it happen? <-- we don’t know yet

Oh, but that means it's all building then, easylogging was the only problem ? So I can cut this short ? :)_

<woodser> I had problems with easylogging (now fixed), some wallet2 dependencies, like http client, boost::asio, and epee::net_utils, and some dependencies throughout the code like perf_timer and CRITICAL_REGION_LOCAL in contrib/epee/src/mlocker.cpp

<woodser> this comparison shows where I had problems and made changes: github.com/monero-project/monero/co…wasm49_update_pool_state?diff=split

OK, so do you need me to go fix anything in the monero code anymore ?

I build all deps now, and it's failing in miniupnpc. My questoin is: am I going to waste my time if you've done this already, or not ?

Because I don't care about emscripten for the sake of it. I care about making monero build with it if many people are going to find it useful.

<woodser> changes are going to be needed to make monero build with it

Alright. I'm confused as to why you can be running monero if it's still going to need changes to build I guess. Unless you're talking daemon, not wallet ?

<woodser> I can run wallet2 refresh and get balances and transfers but only with the modifications I’ve made in my branch, so changes will need to be made upstream if we want others to be able to run it

OK, great. So I'm back to I don't need to do anything more, right ?

I guess I'm assuming you're going to PR those changes. Are you ?

<woodser> sure I can PR them and bring them up as I make progress

Thanks. I'll interpret that as I don't need to do anything anymore.

hi, How can I enable hugepage in MacOs?

Sounds like something people in #monero-pools would know.

thx +moneromooo

<woodser> I got around the wallet2 dependency problems by separating incompatible dependencies into another wallet2 file and passing an abstract http client as a constructor argument where needed. It would be good to get feedback on that and if there is a better way, maybe through environment-based imports (?)

Paste the changes and I'll have a look. I don't know what environment-based imports are.

<woodser> here is the base wallet which accepts an abstract_http_client argument: github.com/woodser/monero/blob/c5f9…1e/src/wallet/wallet2_base.cpp#L627

<woodser> then wallet2 is whatever cannot run in webassembly and a http_simple_client instance: github.com/woodser/monero/blob/c5f9…3d3b5fbb1e/src/wallet/wallet2.h#L47

Can you paste a diff with whatever you started from ?

Hi guys! How to deal with "median offset index is too low (median is 1200799 out of total 2135177offsets)" during transaction creation ?

<woodser> this diff is verbose paste.debian.net/1119250

<woodser> as a result of the name change to wallet2_base and commits to monero-project

spedex: what wallet are you using ?

moneromooo: monero-wallet-rpc 0.15.0.1

Passing a http client to the ctor seems just fine to me.

Why can't some parts of wallet2 rnu with emscripten ?

SpellChecker: try: "unset_ring TXID" with the txid of the transaction that's failing. Then try sending again.

If you're using a stranger's daemon, that stranger will be able to tell the real spend since the wallet will request a new set of fake outs.

That error is to catch wallet implementations which use idiotic ways to pick fake outs, but given it's a random distribution, correct code can also rarely trigger it.

It's got to be the daemon checking it though, since you wouldn't expect a dumb wallet to add code proving it's dumb.

So false positives are going to be there, unfortunately.

wallet2 could re-roll when it knows the daemon's checks will trigger. That'll technically bias a little...

<woodser> there were compile errors with boost::asio, epee::net_utils::ssl_options_t, and http_simple_client

face it reproducible on stagenet with my own daemon. didn't touch it for a long time (since 0.14.1 release)

Compile errors in monero code itself, when using the apis you mention ?

So I do have something to fix after all ?

It's reproducible since once the wallet has selected a set of fake outs for a given output, it'll always use those, for privacy reasons wrt hte daemon.

<woodser> I’d have to go back and check. I can try importing the original wallet2 and seeing what breaks

<woodser> so, I will get back to you

OK. Maybe you can just paste the errors, that might be enough.

<woodser> ok

moneromooo: I'm using monero-wallet-gui 0.15.0.1. Why? Or was the question aimed at someone else? :D

I guess it was addressed to me, spedex :)

Yes. Sorry I did not see your question spedex, can you ask again ?

Lol (Uncaught tab completion fail)

Oooh I see now. Sorry :)

luigi1111w: did those patches fix your problems ?

I think I only saw one patch, and I didn't get around to compiling it to test

Oh.

I'll PR once you confirm.