Support environment variable to hide broadcasted raw transactions.

[tornadocontrib]

Hello.

Since I have no kind of fetish or voyeurism of spying broadcasted raw transactions though local node it would be great if we have any kind of ENV variable or command line option to not list those on local console output.

I thought about disabling console logs but since I need info about peer connections or imported blocks it wouldn't be possible to hide the log about txid without hiding all those info.

I know that it would be best to run a local node but since nodes require decent connections have no choice but to host them on remote location.

But I don't want to store those info about broadcasted transactions since I am not a fed, biden or macron.

I mean, it would be like 2~3 additional lines to https://github.com/ethereum/go-ethereum/blob/master/internal/ethapi/api.go#L1570 which should hide those logs right?

[namiloh]

Hadn't considered it before, but yes, I agree that we should not log this by default.

However, it is extremely useful to see the address of a contract about to be created, particularly in dev-mode when debugging.

Open to suggestions for how to both provide nice UX and be a bit less leaky-to-logs. I think using envvars sound a bit too clunky.

[MariusVanDerWijden]

I think you can try to do a debug.vmodule("internal/ethapi/api.go=0") to get rid of the Submitted transaction log

[tornadocontrib]

@MariusVanDerWijden It would be hard to check if the logs are on or off programmatically ( Also integrating IPC connection are not easy ). Would it be possible to support it on config or command line options?

[holiman]

Would it be possible to support it on config or command line options?

Right, so @MariusVanDerWijden 's suggestion would work. Should be something like --log.vmodule=internal/ethapi/api.go=0 (0 is silent in legacy verbosity).

EDIT: This is wrong

[holiman]

Sorry, but that's not how it works. The vmodule pkg-specfic log filter works like this:

filtering a log record through the global, local and backtrace filters, finally emitting it if either allow it through.

So, if the global log level (INFO) allows it, then the message will be allowed through. The vmodule can thus only be used to increase the verbosity, not to filter it.

Tangentially, the vmodule is very difficult to use, now that we have a mishmash of legacy loglevels and slog loglevels. I think the vmodule loglevel is not quite correctly translated.