Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Net: Improve blocks only mode. #7046

Merged
merged 4 commits into from
Nov 22, 2015
Merged

Net: Improve blocks only mode. #7046

merged 4 commits into from
Nov 22, 2015

Conversation

pstratem
Copy link
Contributor

  • Process inv messages in blocks only mode if we would relay the peers transactions
  • Bail early in tx message processing if we will neither AcceptToMemoryPool nor RelayTransaction

@gmaxwell
Copy link
Contributor

Don't ignore for whitelisted peers?

@pstratem pstratem changed the title [WIP] Net: Ignore "tx" messages in blocks only mode. [WIP] Net: Improve blocks only mode. Nov 17, 2015
@dcousens
Copy link
Contributor

concept ACK, utACK

@pstratem pstratem changed the title [WIP] Net: Improve blocks only mode. Net: Improve blocks only mode. Nov 18, 2015
@paveljanik
Copy link
Contributor

utACK

We should probably document/popularize blocks only mode, because it can be very useful for some usecases - thank you for it!

@tulip0
Copy link

tulip0 commented Nov 20, 2015

When documenting some care needs to be taken to ensure people don't enable this on their nodes thinking it will let them receive blocks faster, "not processing transaction messages will leave more time to do blocks quickly" isn't an unreasonable assumption to make. In actuality running with blocksonly has a massive negative impact on the speed of block verification by never filling ECDSA signature cache.

@gmaxwell
Copy link
Contributor

The impact on mining is much of why I wasn't thinking to promote it yet. We also yet don't do smart things with peers that send no relay. E.g. a node that somehow ends up with 8 blocksonly peers won't do anything smart about it, and probably we'd like to do something about that before encouraging it's widespread use.

@dcousens
Copy link
Contributor

@gmaxwell wasn't this going undocumented (or at least, a huge "highly discouraged" warning) next to if it at all made it in to 0.12?

@pstratem
Copy link
Contributor Author

The help message is only displayed in debug more.
On Nov 20, 2015 8:48 AM, "Daniel Cousens" notifications@github.com wrote:

@gmaxwell https://github.com/gmaxwell wasn't this going undocumented
(or at least, a huge "highly discouraged" warning) next to if it at all
made it in to 0.12?


Reply to this email directly or view it on GitHub
#7046 (comment).

else
{
if (fBlocksOnly)
LogPrint("net", "peer sent inv %s in violation of protocol peer=%d\n", inv.ToString(), pfrom->id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm missing something, but why wouldn't a peer send us a inv? We're advertising NODE_NETWORK, and we haven't sent them a bloom filter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the previous PR (which was merged into master) we set fRelayTxs = false in the version message in blocks only mode.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird, I can't seem to find the actual code that does that. :(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! Sorry, I'm blind, found it!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also reads better if reworded to say "peer %d sent"

@petertodd
Copy link
Contributor

@gmaxwell Re: the only blocksonly peers risk, it probably makes sense to have blocksonly unset NODE_NETWORK for now.

@gmaxwell
Copy link
Contributor

@petertodd I'd rather not, we still serve and relay blocks. You can IBD off a blocks only node, etc. There are already quite a few nodes out there that silently won't relay transactions, at least with the option undocumented I don't think it's a huge marginal risk. -- also, compare to setting your fee settings very high, or your mempool very small. Same outcome.

// We are in blocks only mode and peer is either not whitelisted or whitelistalwaysrelay is off
if (GetBoolArg("-blocksonly", DEFAULT_BLOCKSONLY) && (!pfrom->fWhitelisted || !GetBoolArg("-whitelistalwaysrelay", DEFAULT_WHITELISTALWAYSRELAY)))
{
LogPrint("net", "peer sent transaction in violation of protocol peer=%d\n", pfrom->id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reads better if reworded to say "peer %d sent"

@petertodd
Copy link
Contributor

Tests done:

[x] Triggered inv and tx "violation of protocol" cases
[x] Tested with a bitcoinj wallet, which just ignored the fRelayTxs (edit: actually, looks like it only does that in the "trusted peer" case)

ACK (modulo https://github.com/pstratem/bitcoin/pull/3)

@petertodd
Copy link
Contributor

@gmaxwell Fair enough; I'm convinced.

pstratem and others added 3 commits November 20, 2015 16:07
Previously in blocks only mode all inv messages where type!=MSG_BLOCK would be
rejected without regard for whitelisting or whitelistalwaysrelay.

As such whitelisted peers would never send the transaction (which would be
processed).
Previously unsolicited transactions would be processed as normal.
@gmaxwell
Copy link
Contributor

Sorry to nitpick, esp at odds with PT's nitpick: but I think these log entries should be made consistent:

2015-11-21 23:42:08 getblocks 384665 to 00000000000000000c8d710c468516e11f76188c18def174581317b8faac716d limit 500 from peer=86
2015-11-21 23:42:08 getblocks stopping at 384666 00000000000000000c8d710c468516e11f76188c18def174581317b8faac716d
2015-11-21 23:42:08 sending: inv (37 bytes) peer=86
2015-11-21 23:42:08 received: pong (8 bytes) peer=86
2015-11-21 23:42:08 sending: ping (8 bytes) peer=56
2015-11-21 23:42:08 received: tx (29246 bytes) peer=1
2015-11-21 23:42:08 peer 1 sent transaction in violation of protocol

E.g. "transaction (txid?) sent in violation of protocol peer=%d"

@gmaxwell
Copy link
Contributor

@petertodd come reack that I undid your nit. :)

@petertodd
Copy link
Contributor

@gmaxwell That wording looks fine, although I'd point out that phrasing it "[THING] sent in violation of protocol, peer=%d" - note the added comma! - should be fine too.

What can I call that? A μnit? :)

@gmaxwell
Copy link
Contributor

ACK

@gmaxwell gmaxwell merged commit 80ae230 into bitcoin:master Nov 22, 2015
gmaxwell added a commit that referenced this pull request Nov 22, 2015
80ae230 Improve log messages for blocks only violations. (Patick Strateman)
08843ed Add relaytxes status to getpeerinfo (Peter Todd)
d8aaa51 Bail early in processing transactions in blocks only mode. (Patick Strateman)
3587f6a Fix relay mechanism for whitelisted peers under blocks only mode. (Patick Strateman)
zkbot added a commit to zcash/zcash that referenced this pull request Mar 31, 2021
Add -blocksonly option

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6993
- bitcoin/bitcoin#7046
- bitcoin/bitcoin#6780
  - The third commit (we backported the rest in #2390).
- bitcoin/bitcoin#7126
- bitcoin/bitcoin#7439
- bitcoin/bitcoin#15990
  - Only the `-blocksonly` documentation changes.
- bitcoin/bitcoin#16555
- bitcoin/bitcoin#18391
  - Only the `-blocksonly` documentation changes.

Part of #2074.
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants