-
Notifications
You must be signed in to change notification settings - Fork 36.9k
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
Conversation
pstratem
commented
Nov 17, 2015
- 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
Don't ignore for whitelisted peers? |
concept ACK, utACK |
utACK We should probably document/popularize blocks only mode, because it can be very useful for some usecases - thank you for it! |
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 |
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. |
@gmaxwell wasn't this going undocumented (or at least, a huge "highly discouraged" warning) next to if it at all made it in to |
The help message is only displayed in debug more.
|
else | ||
{ | ||
if (fBlocksOnly) | ||
LogPrint("net", "peer sent inv %s in violation of protocol peer=%d\n", inv.ToString(), pfrom->id); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. :(
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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"
@gmaxwell Re: the only blocksonly peers risk, it probably makes sense to have blocksonly unset NODE_NETWORK for now. |
@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); |
There was a problem hiding this comment.
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"
Tests done: [x] Triggered inv and tx "violation of protocol" cases ACK (modulo https://github.com/pstratem/bitcoin/pull/3) |
@gmaxwell Fair enough; I'm convinced. |
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.
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 E.g. "transaction (txid?) sent in violation of protocol peer=%d" |
@petertodd come reack that I undid your nit. :) |
@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? :) |
ACK |
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)
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.