On Sep 15, 2011, at 1:17 PM, Gavin Andresen wrote:
>> On Sep 15, 2011 11:20 AM, "Gavin Andresen" wrote:
>>> I'm ignoring bandwidth DoS attacks-- we already have the
>>> -maxreceivebuffer option to deal with those.
>>
>> I disagree with this comment. The way this is currently implemented is a mem
I took it off the list because snarky comments are not appropriate for
bitcoin-dev, and I was being snarky.
Please try to keep your comments on-topic; if you want to talk about
fixing -maxreceivebuffer (a change I would wholeheartedly embrace, the
code I slapped together was reacting to phantomcir
On Sep 15, 2011 11:20 AM, "Gavin Andresen" wrote:
> I'm ignoring bandwidth DoS attacks-- we already have the
> -maxreceivebuffer option to deal with those.
I disagree with this comment. The way this is currently implemented is a mem
exhaustion dos in itself waiting to happen and does nothing to p
On Thursday, September 15, 2011 12:04:37 PM kjj wrote:
> On the other hand, the vast, vast majority of all transactions follow a
> particular pattern. If someone gives you one that doesn't match the
> standard pattern, you might be a little suspicious, but it is no big
> deal. But, if they emit d
I don't think that any kind of peer disconnection should be present in the
reference client implementation. This is a lot like using packet filters and
stateful firewalls - they are implemented based on local policy and they
require constant tweaking because they always cause problems when some
> If I think you're trying to DoS me, why would I be nice to you?
The issue is, what if I'm not trying to DoS you, but something went wrong?
> think response messages would just give an attacker another potential
> attack vector, and it is clear from the debug.log what triggers a ban.
Only clear
I hate to get specific about potential attacks on a public mailing
list, but I think the debate over what to do with non-standard
transactions means we need to.
I agree with Gregory; if there are NO rules about what transactions
peers can send at you, then an attacker can trivially get around othe
Luke-Jr wrote:
> On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
>> Luke-Jr wrote:
>>> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
I'm looking for review of this pull request:
https://github.com/bitcoin/bitcoin/pull/517
>>> "Non-standard" transactions, or t
On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
> Luke-Jr wrote:
> > On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
> >> I'm looking for review of this pull request:
> >>https://github.com/bitcoin/bitcoin/pull/517
> >
> > "Non-standard" transactions, or those with "ins
On Thu, Sep 15, 2011 at 10:06 AM, Gavin Andresen
wrote:
> If I think you're trying to DoS me, why would I be nice to you? I
> think response messages would just give an attacker another potential
> attack vector, and it is clear from the debug.log what triggers a ban.
Fail hard, log the reason l
> Should the DoS protection auto-disable if the node has less than a minimum
> number of connections? The idea being that if our node seems to be kicking
> everybody off the roster maybe there is something wrong with the
> protections.
Darn good question. If the protection fails, would it be bette
A few thoughts:
Should the DoS protection auto-disable if the node has less than a
minimum number of connections? The idea being that if our node seems to
be kicking /everybody /off the roster maybe there is something wrong
with the protections.
It would be nice if the node sent a message to
Luke-Jr wrote:
> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>> I'm looking for review of this pull request:
>>https://github.com/bitcoin/bitcoin/pull/517
> "Non-standard" transactions, or those with "insufficient" fees should not be
> penalised. These are properly relay/m
Thanks Mike, that's exactly the kind of detailed review I was looking
for. I think you're right an all points.
I'll simplify: I'll add a -banscore option (default 100), and if a
node accumulates more than -banscore misbehavior points it'll get
dropped and banned for -bantime (default 60*60*24) s
Probabilistic disconnections could make it quite hard to debug protocol
implementations and increases the risk of flaky behaviour in the wild
significantly. I don't see why a simpler solution isn't better.
The most likely failure mode of this is not an attack but the same as
previous breakages - s
I'd be happy with a sort of BitTorrent like snubbing, and dropping in
extreme cases.
Sharing blacklist decisions would be dangerous. We could even extend the
protocol to include some sort of choking/unchoking in order to warn peers
that we might drop him if he continues to misbehave.
In general I
16 matches
Mail list logo
