Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Transaction Queue banning #2524

Merged
merged 13 commits into from
Oct 27, 2016
Merged

Transaction Queue banning #2524

merged 13 commits into from
Oct 27, 2016

Conversation

tomusdrw
Copy link
Collaborator

@tomusdrw tomusdrw commented Oct 7, 2016

No description provided.

@tomusdrw tomusdrw added A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. M4-core ⛓ Core client code / Rust. labels Oct 7, 2016
@taoeffect
Copy link

What is this?

There is no reason for a blacklisting mechanism to be included in a public blockchain node. That is what the gas/fee mechanism is for. Introducing a generic blacklisting mechanism is:

  1. Unnecessary, you can always ban an IP using ufw / iptables / your-favorite-firewall.
  2. Guaranteed to increase censorship in the network.
  3. Incorrect, fees are how you solve spam issues.

@rphmeier
Copy link
Contributor

rphmeier commented Oct 7, 2016

@taoeffect Unfortunately, the gas mechanism is fundamentally mis-priced. In the period before the instruction costs are adjusted, I hope you can forgive some interim measures intended to smooth over the corner cases of the current pricing scheme.

It's not truly a blacklist but a (local) timeout for senders who appear to be producing transactions exploiting those weaknesses.

@taoeffect
Copy link

taoeffect commented Oct 7, 2016

Thanks @rphmeier, I just reached a similar conclusion after finishing reviewing the code. It's (thankfully) not user-specified but automatic based on txn processing time.

I still get nervous anytime I see blacklisting mechanisms, even if they seem fairly benign like this, simply because once you introduce a blacklisting mechanism it becomes trivial to expand it. Every now and then you'll get someone else adding another "minor" change to it and after a while you're left with the full censorship-experience shebang.

Therefore, if there is really no option but to do this, then I hope this code can be removed after a proper fix is introduced, e.g.: ethereum/EIPs#150

@taoeffect
Copy link

In the period before the instruction costs are adjusted, I hope you can forgive some interim measures intended to smooth over the corner cases of the current pricing scheme.

Once the pricing scheme is fixed, this should no longer be necessary, correct? Therefore, can we get a commitment that this code will be removed in a future release?

And if no such commitment can be given, can it please be explained why that is, and also why the extreme divergence from the Yellow Paper?

@rphmeier
Copy link
Contributor

rphmeier commented Oct 7, 2016

@taoeffect I don't see any problem in removing it once EIP 150 is in. If the costs are adjusted correctly we shouldn't see any transactions hitting the time limit here, making the mechanism effectively dead code.

@taoeffect
Copy link

@taoeffect I don't see any problem in removing it once EIP 150 is in. If the costs are adjusted correctly we shouldn't see any transactions hitting the time limit here, making the mechanism effectively dead code.

@rphmeier Awesome, thank you. 🙇

@taoeffect
Copy link

taoeffect commented Oct 8, 2016

Every now and then you'll get someone else adding another "minor" change to it and after a while you're left with the full censorship-experience shebang.

Err, what am I saying, that's not how it usually works.

Usually it works more like we're seeing here right now.

  • Attacker wants to achieve something (for Ethereum it's usually censorship, brought about by various means).
  • So the attacker creates a problem, in this case it's a spam attack.
  • Then, while everybody's freaking about whatever problem, the attacker proposes, or gets somebody else to suggest, a "solution", that happens to be an actual solution to the problem.
  • Undoubtedly this solution will always have a caveat, sometimes it will be obvious, other times it might appear innocuous because it's part of a more subtle long-term plan. In this case, if such an attack were taking place, it would be the beginnings of a generic censorship mechanism.

So, this stuff is real. This is how sophisticated sabotage attempts actually work, and we have plenty of case studies of existing attempts on Bitcoin.

That is why it is very important to take this seriously and to really remove the code ASAP, or better yet, don't merge it at all.

@openethereum openethereum locked and limited conversation to collaborators Oct 19, 2016
@gavofyork
Copy link
Contributor

@tomusdrw i'm generally happy to merge this, but i think it'd be better we HEAVY_TRANSACTION_THRESHOLD_MS and generally activating it---to be configurable. should probably start either with a fairly conservative threshold (e.g. 1s) or disabled.

@tomusdrw
Copy link
Collaborator Author

Sure, will have a look at this.

@tomusdrw tomusdrw changed the title Transaction Queue blacklists Transaction Queue banning Oct 25, 2016
byteorder = "0.5"
transient-hashmap = "0.1"
lru-cache = { git = "https://github.com/contain-rs/lru-cache" }
Copy link
Contributor

Choose a reason for hiding this comment

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

why move to the direct version? i've found that they'll usually publish a new version if you ask :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Either I broke something during merge or it was already like this on master:
https://github.com/ethcore/parity/blame/master/ethcore/Cargo.toml

@tomusdrw tomusdrw added A0-pleasereview 🤓 Pull request needs code review. and removed A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. labels Oct 26, 2016
[ci:skip]
@gavofyork
Copy link
Contributor

would prefer to see the "180 seconds" parameterised, too. looks good otherwise.

@gavofyork gavofyork added A6-mustntgrumble 💦 Pull request has areas for improvement. The author need not address them before merging. and removed A0-pleasereview 🤓 Pull request needs code review. labels Oct 26, 2016
@tomusdrw tomusdrw added A0-pleasereview 🤓 Pull request needs code review. and removed A6-mustntgrumble 💦 Pull request has areas for improvement. The author need not address them before merging. labels Oct 27, 2016
@tomusdrw
Copy link
Collaborator Author

Updated.

flag_remove_solved: false,
flag_notify_work: Some("http://localhost:3001".into()),

// -- Footprint Options
flag_tracing: "auto".into(),
flag_pruning: "auto".into(),
flag_pruning_history: 64u64,
flag_pruning_history: 128u64,
Copy link
Contributor

Choose a reason for hiding this comment

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

why change pruning history default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sorry, will move it to separate PR - I haven't changed the default, but rather fixed a bug where config value would not be used (usage.txt had [default: instead of (default:)
This change was only to verify that it's not working.

@tomusdrw tomusdrw added A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. and removed A0-pleasereview 🤓 Pull request needs code review. labels Oct 27, 2016
@tomusdrw tomusdrw added A0-pleasereview 🤓 Pull request needs code review. and removed A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. labels Oct 27, 2016
@gavofyork gavofyork added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels Oct 27, 2016
@gavofyork gavofyork merged commit 152a551 into master Oct 27, 2016
@gavofyork gavofyork deleted the queue-blacklist branch October 27, 2016 17:28
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants