Network activity toggle

jonasschnelli commented at 3:25 pm on November 19, 2014: contributor

brings back @jonls #2412. Rebased and overhauled:

togglenetwork RPC command renamed to “setnetworkactive true|false”
GUI toggling is now by pressing the connections icon in the status bar (it’s a hidden feature now!)

Allow network activity to be temporarily suspended.

Added the function SetNetworkActive() which when called with argument set to false disconnects all nodes and sets the flag fNetworkActive to false. As long as this flag is false no new connections are attempted and no incoming connections are accepted. Network activity is reenabled by calling the function with argument true.

bf9a7fba44

Add RPC command "togglenetwork" to toggle network activity temporarily.

RPC command "togglenetwork" toggles network and returns new state after command.
RPC command "getinfo" returns "networkactive" field in output.

649272f6e0

Add gui feedback and control of network activity state.

Add getNetworkActive()/setNetworkActive() method to client model.
Send network active status through NotifyNetworkActiveChanged.
Indicate in tool tip of gui status bar network indicator whether network activity is disabled.
Indicate in debug window whether network activity is disabled and add button to allow user to toggle network activity state.

fd6456d001

overhaul @jonls network-activity-togle

- rename rpc command "togglenetwork" to "setnetworkactive (true|false)"
- add simple testcase
- GUI toggle added to connections icon in statusbar

ba0456186a

gmaxwell commented at 2:37 am on November 20, 2014: contributor

Can you write up a proposed testing procedure?

jonasschnelli commented at 8:19 am on November 20, 2014: contributor

I started a very simple unit-test case in this pull (here).

In general The network toggle should react as you would block your local traffic (iptables, soft-firewall, etc.) or as you would unplug yourself off the inet. IMO, there should not be a special answer to sendtoaddress, etc. when your toggled your network off. If we start treating the network-toggled-off state anyhow special, we might slide into a new, probably heavy to maintain state.

jonasschnelli commented at 1:28 pm on November 26, 2014: contributor

Any opinion on that? I would love to see this in 0.11.

Diapolo commented at 1:47 pm on November 26, 2014: none

I always liked that, didn’t look at the pull lately…

laanwj commented at 2:17 pm on November 26, 2014: member

I’m still too focused on the 0.10 release to even think about what should make it into 0.11, which is half a year away.

I’d prefer traffic throttling or “quotas per time unit” a la Tor (see https://www.torproject.org/docs/faq.html.en#LimitTotalBandwidth) to a manual, complete shutoff. But this may be better than nothing in that regard, and much easier to test.

jonasschnelli commented at 2:23 pm on November 26, 2014: contributor

@laanwj no worries. You should/can focus on 0.10.

IMO: Throttling is another thing and can address other user scenarios. Disabling != throttling. I could imagine having both features side a side.

gmaxwell commented at 7:28 pm on November 26, 2014: contributor

I’d like to see a host network friendlyness features in upcoming versions. This should be one them.

There are some corner cases to contemplate here. Say a transaction has one confirmation and you network off a host and the chain reorgs and drops the transaction. The wallet will be giving incorret information until the network is turned back on. So, should such a patch be disabling confirmation counts on newly confirmed transactions?

jonasschnelli commented at 7:46 pm on November 26, 2014: contributor

Disabling the confirmation count during disabled network state would be possible. But the reorg-drop-transaction thing could also happen when you disconnect on a hardware basis (weak wifi, 3g connection, etc.). Should we also check for hardware-like-network-disconnections? Probably not.

Adding code to handle the toggled off state in case of UI, etc. could bring in more effort when it comes to maintainability.

IMO, let’s just allow users cut themselves off the nodes, brutal and with all known sudden-disconnect issues.

Or an option would be: Warn user on Qt level before they disconnect.

laanwj added the label P2P on Nov 28, 2014

in doc/assets-attribution.md: in ba0456186a

105+Yusuke Kamiyamane
106+-----------------------
107+
108+### Info
109+* Designer: Yusuke Kamiyamane
110+* License: Creative Commons (Attribution 3.0 Unported)

luke-jr commented at 8:00 am on December 25, 2014:

Can we find an icon that doesn’t require a new license?

luke-jr commented at 8:12 am on December 25, 2014:

In fact, NACK merging with this license. Section 4(c) seems to give the author special privileges that are non-free and could conceivably be problematic.

luke-jr commented at 8:29 am on December 25, 2014:

@jonasschnelli Can you make a new one that fits better with #5219 ? :)

jonasschnelli commented at 8:34 am on December 25, 2014:

Yes. The icon should not be the problem. Will do a new one soon.

gmaxwell commented at 8:17 am on December 25, 2014: contributor

The “toggle” rpc is a bad interface. It depends on the caller knowing the current state, and even if the caller checks it could race with another caller.

Can we make the api/interface so that it can have more than two states? A useful middle ground is “make outbound connections every X hours, fetch blocks, go back offline”. This ensures you won’t be waiting a long time when you go to actually use it.

So, e.g. off/scheduled/on I think it’s likely that when we add support for bandwidth rate limiting we’ll add code to parse cron style schedules.

IMO, let’s just allow users cut themselves off the nodes,

Our responsiblity to the user is to help them not footgun themselvels. If they understood the software and risks as well as we do, they’ve be writing it, not us. :)

That doesn’t mean it’s reasonable to pack every potential protection we can think of into every pull. But if we have something that increases risk to the user we ought to give some thought as to how we can mitigate that risk.

could bring in more effort when it comes to maintainability

I think overall we should have more affordances for risky situations. E.g. making it clear that confirmations are uncertian when we know the network has forked. Presumably all these modes of cautionary handling can be covered by a single piece of interface infrastrcture. Some hurestic of “if you’re off line N minutes, then blocks N*2 minutes prior to when you went off now have a displayed confirm count of ‘?’” would be simple to add if there was already code that hid confirmation counts under other dangerous condtions.

ghost commented at 11:22 am on December 30, 2014: none

one thing i see is that this is a good first step for the issue with the in-wallet paper wallet generator

jonasschnelli commented at 9:05 am on April 16, 2015: contributor

There is no consensus about this. Closing for now.

jonasschnelli closed this on Apr 16, 2015

jonasschnelli commented at 6:50 pm on June 29, 2015: contributor

@gmaxwell: I still think a pause/resume feature could be useful.

What about pausing the validation process (during initial sync)?
What if a user could disable block relaying? Do you expect that this causes a harm to the network? I think diving into network throttling is a job outside of bitcoind (router/net level).

ghost commented at 9:54 am on July 1, 2015: none

I agree with @jonasschnelli in supporting this PR. For example, some have data plans that have limited day useage with unlimited night use, in such cases (very common around here) one would appreciate the option to pause access in the morning and resume after hours. Closing the app and restarting is always a scary thing because if it gets corrupted, you have to start from scratch. Also this ties in well with the pull request to add an internal paper wallet printer, another PR that i think would make a great addition to the wallet.

DrahtBot locked this on Sep 8, 2021

Network activity toggle #5314