Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
limitfreerelay edge case bugfix #6842
Currently if a new incoming transaction will cause -limitfreerelay
What I've been seeing during this attack is that dFreeCount will often get up to 140 to 149KB then the next spam transaction of 15KB will still slip through to bring the total up past the 150KB limit ( limitfreerelay default set at 15), whereas I think it shouldn't be accepted if it's going to exceed the limit. This only allows the attacker to slip through large transactions past the limit, which could be any size up to the transaction size maximum.
No strong opinion on this change; since it arguably makes the behavior more intuitive I think it's fine.
But I think there's no need to include this in 0.12, as this is a pretty small effect, and I'm not sure I'd call the current behavior a "bug" -- just different semantics (bytes allowed now are at the expense of bytes in the future).