* [Bitcoin-development] Request review: drop misbehaving peers
@ 2011-09-15 1:57 Gavin Andresen
2011-09-15 2:06 ` Luke-Jr
2011-09-15 11:45 ` Mike Hearn
0 siblings, 2 replies; 19+ messages in thread
From: Gavin Andresen @ 2011-09-15 1:57 UTC (permalink / raw)
To: Bitcoin Dev
I'm looking for review of this pull request:
https://github.com/bitcoin/bitcoin/pull/517
The big idea: if a peer is sending you obviously wrong information,
punish it by maybe dropping your connection to it, and ban it's IP
address so it cannot immediately re-connect.
The probability of dropping the connection, and the length of the ban,
depend on how how potentially wasteful/damaging the peer is behaving.
So sending an extra 'version' message is a minor transgression that is
usually tolerated, sending a more-than MAX_BLOCK_SIZE block is a major
transgression that gets the peer disconnected immediately.
Detailed how-it-works, using "I got a version message I wasn't
expecting" as the specific example:
Getting an unexpected version message from a peer increases that
peer's 'misbehaving' score by 10, and (assuming that is the peer's
first bad behavior) gives it a 10% chance of being disconnected. If
it is disconnected, then that peer's IP address is banned from
connecting for a couple of hours. If it is not disconnected, then
nothing happens unless the peer misbehaves again; if it does, then its
chances of being disconnected go up, and the length of time it will be
banned increases.
Misbehavior/ban information is stored only in memory, and information
about misbehaving peers is never broadcast. Also, peers that are
disconnected/banned are just dropped, there is no warning or reason
sent.
I think this will eliminate a lot of potential denial-of-service
attacks, and could be a good framework for responding to other
potential attacks. "We" should still look through the code and limit
the potential size of any data structures that an attacker might
target (transaction pool, orphan block pool); the DoSprevention
changes are meant to make it harder for an attacker to stay connected
long enough to pull off an attack.
The danger is that I got something wrong; what if an attacker can
leverage the DoSprevention code to split or shatter the network?
Here's my thinking on that, please help check my work:
+ I'm relying on TCP to prevent IP address spoofing (otherwise an
attacker could force you to disconnect from your peers by pretending
to be them and sending you a bad block).
+ Peers are only penalized for sending messages that won't, and
shouldn't, get relayed. So an attacker shouldn't be able to poison the
network with a bad message that is propogated and then causes
everybody to disconnect from everybody else.
+ I specifically do not punish peers for relaying what look like
double-spend transactions. If I did, then an attacker could try to
segment the network into two pieces by broadcasting a series of
double-spends from two halves of the network, and waiting until the
nodes "in the middle" disconnected/banned across the 'seam'.
So: please let me know if or how I'm being an idiot.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 1:57 [Bitcoin-development] Request review: drop misbehaving peers Gavin Andresen
@ 2011-09-15 2:06 ` Luke-Jr
2011-09-15 10:43 ` Christian Decker
2011-09-15 12:56 ` kjj
2011-09-15 11:45 ` Mike Hearn
1 sibling, 2 replies; 19+ messages in thread
From: Luke-Jr @ 2011-09-15 2:06 UTC (permalink / raw)
To: bitcoin-development
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/miner policy decisions, not protocol
violations, and should be made more easily configurable, not punished for
configuration.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 2:06 ` Luke-Jr
@ 2011-09-15 10:43 ` Christian Decker
2011-09-15 12:56 ` kjj
1 sibling, 0 replies; 19+ messages in thread
From: Christian Decker @ 2011-09-15 10:43 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]
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 think that we have to be careful in what we consider
misbehaving, it should be really conservative to begin with, and extend the
rules over time. Making them too restrictive might make future development
difficult, not to speak of alternative clients.
Regards,
Chris
On Thu, Sep 15, 2011 at 4:06 AM, Luke-Jr <luke@dashjr•org> 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/miner policy decisions, not protocol
> violations, and should be made more easily configurable, not punished for
> configuration.
>
>
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2427 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 1:57 [Bitcoin-development] Request review: drop misbehaving peers Gavin Andresen
2011-09-15 2:06 ` Luke-Jr
@ 2011-09-15 11:45 ` Mike Hearn
2011-09-15 12:25 ` Gavin Andresen
1 sibling, 1 reply; 19+ messages in thread
From: Mike Hearn @ 2011-09-15 11:45 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
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 - scaling or legitimate version skew that causes problems
as the network evolves.
Agree with Luke that non-standard transactions should not be considered an
attack.
If you stay with the scoring system I'd be tempted to have a flag (defaults
to 100) that sets a minimum threshold for the badness scores and ignores any
below that. Attacks based on sending transactions that aren't syntactically
valid don't seem likely to me, this isn't a good way to DoS somebody because
discarding them is so cheap. If it turns out later there is a problem,
people under attack could flip the flag until a new version is released.
The formula for the DoS score in the case of invalid signatures/merkle roots
seem unnecessarily elaborate. An invalid signature should never occur and
could always result in immediate disconnection.
Treating a block with too many sigops as invalid means legitimate relayers
might be treated as an attacker if/when the constant changes in future. I'd
suggest not treating this as an attacking situation at all.
Why use a mutable field with a const setter?
Unit tests that rely on sleeps like this can be flaky because the OS delay
isn't always precise, not to mention slow/irritating to run. It's better if
tests can override the clock, eg, if GetTime() did something like
if (nMockTime) { return nMockTime} else { ... }
then unit tests could reliably modify and advance the clock in a
fast/efficient manner.
[-- Attachment #2: Type: text/html, Size: 2003 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 11:45 ` Mike Hearn
@ 2011-09-15 12:25 ` Gavin Andresen
2011-09-15 13:00 ` Stefan Thomas
0 siblings, 1 reply; 19+ messages in thread
From: Gavin Andresen @ 2011-09-15 12:25 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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) seconds.
I'll make bad signatures a banning offense, and I'll remove the
number-of-sigops and non-standard-transaction penalties.
I used a mutable field with const setter to avoid modifying a bunch of
methods to take non-const blocks/transactions instead of const; I
think it is appropriate because a block/transaction's DoS score is
really meta-data and not part of it's state.
I'll make GetTime() unit-test friendly as you suggest.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 2:06 ` Luke-Jr
2011-09-15 10:43 ` Christian Decker
@ 2011-09-15 12:56 ` kjj
2011-09-15 15:36 ` Luke-Jr
1 sibling, 1 reply; 19+ messages in thread
From: kjj @ 2011-09-15 12:56 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
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/miner policy decisions, not protocol
> violations, and should be made more easily configurable, not punished for
> configuration.
>
>
A few non-standard transactions are probably legitimate. A whole bunch
of them are probably not. I would think that assigning a point or two
of badness to a peer sending one is pretty reasonable, with the
understanding that we would need to adjust that as the network evolves.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 12:25 ` Gavin Andresen
@ 2011-09-15 13:00 ` Stefan Thomas
2011-09-15 14:06 ` Gavin Andresen
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Thomas @ 2011-09-15 13:00 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]
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 the banned peer with a
code indicating the reason for the ban, specifically the offense that
put Bitcoin over the edge. Logging the reason is probably fine for most
cases, but I wanted to put the idea out there, because it might make
debugging easier if there are some weird bans happening in the wild and
we can't figure out why.
Should sending lots of messages that don't pass the protocol-level
checksum test be a bannable offense? Or generally sending garbage data?
The attacks I'm thinking of are cross-protocol attacks. So as rough
example: The attacker puts an iframe on a website with a url like
http://victim.com:8333 so lots of people's browsers connect to it. Maybe
he could even use something like [magic-bytes]tx\0[...][valid orphan
transaction] in the URL, so the browser would send GET /[magic-bytes]
etc. and the Bitcoin node would interpret it.
kjj wrote:
> A few non-standard transactions are probably legitimate. A whole bunch
> of them are probably not. I would think that assigning a point or two
> of badness to a peer sending one is pretty reasonable, with the
> understanding that we would need to adjust that as the network evolves.
Strongly disagree. What is a non-standard transaction today may /be /a
standard transaction tomorrow.
On 9/15/2011 2:25 PM, Gavin Andresen wrote:
> 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) seconds.
>
> I'll make bad signatures a banning offense, and I'll remove the
> number-of-sigops and non-standard-transaction penalties.
>
> I used a mutable field with const setter to avoid modifying a bunch of
> methods to take non-const blocks/transactions instead of const; I
> think it is appropriate because a block/transaction's DoS score is
> really meta-data and not part of it's state.
>
> I'll make GetTime() unit-test friendly as you suggest.
>
[-- Attachment #2: Type: text/html, Size: 3006 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 13:00 ` Stefan Thomas
@ 2011-09-15 14:06 ` Gavin Andresen
2011-09-15 14:21 ` Gregory Maxwell
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Gavin Andresen @ 2011-09-15 14:06 UTC (permalink / raw)
To: Stefan Thomas; +Cc: bitcoin-development
> 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 better for it
to 'fail hard', leaving people complaining "bitcoin won't stay
connected!"
Or fail soft, so you at least have a couple of connections.
I think fail hard is better-- we'll immediately know about the
problem, and can fix it. Fail soft makes me nervous because I think
that would make it more likely a bug splits the network (and,
therefore, the blockchain).
> It would be nice if the node sent a message to the banned peer with a code
> indicating the reason for the ban
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.
> Should sending lots of messages that don't pass the protocol-level checksum
> test be a bannable offense? Or generally sending garbage data?
Good question. Anybody see a reason not to? How much tolerance (if
any) should there be for sending garbage data (I assume the
lower-level network stack almost never garbles data, is that a good
assumption)?
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 14:06 ` Gavin Andresen
@ 2011-09-15 14:21 ` Gregory Maxwell
2011-09-15 16:21 ` Mike Hearn
2011-09-16 12:57 ` Joel Joonatan Kaartinen
2 siblings, 0 replies; 19+ messages in thread
From: Gregory Maxwell @ 2011-09-15 14:21 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
On Thu, Sep 15, 2011 at 10:06 AM, Gavin Andresen
<gavinandresen@gmail•com> 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 locally. Problem becomes tractable. Also,
for any problem big enough to cause a network outage the issue won't
be reproducibility.
I support the imposition of txn rules— otherwise the dropping is
nearly pointless due to the hole that any attack can just take the
form of junk txn— but you must be super careful that an attack can't
be transitive: There should be nothing I can give a node that it will
forward on that will make that node's peers drop it. (and this needs
to remain true while forwarding rules evolve)
So, I'd suggest that you'd only drop on transactions that would
invalidate a block if included in it but the problem there is that
double spends meet that criteria. Better would, perhaps be something
like "would invalidate a block if included; except that double spends
after the last checkpoint are allowed, and nodes should not forward
any txn until they are current with their last checkpoint"
(That bit of complexity is to reduce exposure where a new node gets
hit with double spends that its yet too stupid to reject, and it
forwards them onto its friendly peers who then hang up on it thus
prolonging its period of ignorance— in general care needs to be taken
to avoid hanging up on nodes that are just too young to know better)
> Good question. Anybody see a reason not to? How much tolerance (if
> any) should there be for sending garbage data (I assume the
> lower-level network stack almost never garbles data, is that a good
> assumption)?
It would be fine to hang up on any garbage data: something is
obviously wrong. I'd be hesitant to ban on a single instance of it,
it's rare but happens. (e.g. see
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.150&rep=rep1&type=ps)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 12:56 ` kjj
@ 2011-09-15 15:36 ` Luke-Jr
2011-09-15 16:04 ` kjj
2011-09-15 16:19 ` Gavin Andresen
0 siblings, 2 replies; 19+ messages in thread
From: Luke-Jr @ 2011-09-15 15:36 UTC (permalink / raw)
To: kjj; +Cc: bitcoin-development
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 "insufficient" fees should not
> > be penalised. These are properly relay/miner policy decisions, not
> > protocol violations, and should be made more easily configurable, not
> > punished for configuration.
>
> A few non-standard transactions are probably legitimate. A whole bunch
> of them are probably not. I would think that assigning a point or two
> of badness to a peer sending one is pretty reasonable, with the
> understanding that we would need to adjust that as the network evolves.
No. There is no such thing as "non-standard transactions" really; it is simply
"transactions outside of the bounds that I as a user/miner will relay/accept".
It is perfectly legitimate for other users/miners to relay/accept transactions
more liberally. By penalising for transactions falling outside of your
*personal policies*, you would end up banning many legitimate nodes.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 15:36 ` Luke-Jr
@ 2011-09-15 16:04 ` kjj
2011-09-15 16:41 ` solar
2011-09-15 17:29 ` Luke-Jr
2011-09-15 16:19 ` Gavin Andresen
1 sibling, 2 replies; 19+ messages in thread
From: kjj @ 2011-09-15 16:04 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
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 those with "insufficient" fees should not
>>> be penalised. These are properly relay/miner policy decisions, not
>>> protocol violations, and should be made more easily configurable, not
>>> punished for configuration.
>> A few non-standard transactions are probably legitimate. A whole bunch
>> of them are probably not. I would think that assigning a point or two
>> of badness to a peer sending one is pretty reasonable, with the
>> understanding that we would need to adjust that as the network evolves.
> No. There is no such thing as "non-standard transactions" really; it is simply
> "transactions outside of the bounds that I as a user/miner will relay/accept".
> It is perfectly legitimate for other users/miners to relay/accept transactions
> more liberally. By penalising for transactions falling outside of your
> *personal policies*, you would end up banning many legitimate nodes.
It is certainly true that standardness is an artificial construct that
only has meaning to this particular implementation of the software, but
no meaning in the context of the protocol or the system as a whole.
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 dozens or hundreds, it is hardly unreasonable
to disconnect them until you figure out what's going on.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 15:36 ` Luke-Jr
2011-09-15 16:04 ` kjj
@ 2011-09-15 16:19 ` Gavin Andresen
2011-09-15 17:41 ` Douglas Huff
1 sibling, 1 reply; 19+ messages in thread
From: Gavin Andresen @ 2011-09-15 16:19 UTC (permalink / raw)
To: bitcoin-development
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 other
the DoS rules.
I also agree we need to think hard about what will happen when new
'standard' transaction types are deployed.
There are two significant DoS attacks I can imagine using transactions
that will never be included in blocks. The "will never be included in
blocks" bit is important, because if an attacker can make you do
significant work at no cost to themselves then they win. And if the
transactions will never be included in blocks the attacker can include
lots of transaction fees that will never be spent.
1) Exhaust memory by filling up the transaction memory pool. I think
another patch needs to be written to deal with that (keep the size of
the transaction pool reasonable by evicting low-priority
transactions).
2) Waste CPU time validating transactions They can make you use an
arbitrary amount of CPU time just by flooding you with a stream of
valid-but-won't-ever-get-into-a-block transactions.
The code already refuses to relay non-standard transactions, and
doesn't check their signatures or add them to the memory pool, so I
think no DoS check is needed for them (and would be harmful when we do
start supporting new standard transactions).
It also drops transactions with "too few fees" before checking
signatures or doing other CPU-intensive work, so no I think no DoS
check is needed there, either (and again, would be harmful when
transaction fee rules change).
I'm ignoring bandwidth DoS attacks-- we already have the
-maxreceivebuffer option to deal with those.
PS: I'll add Gregory's comment:
"There should be nothing I can give a node that it will
forward on that will make that node's peers drop it. (and this needs
to remain true while forwarding rules evolve)"
... as a comment in the code so hopefully we don't forget it.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 14:06 ` Gavin Andresen
2011-09-15 14:21 ` Gregory Maxwell
@ 2011-09-15 16:21 ` Mike Hearn
2011-09-16 12:57 ` Joel Joonatan Kaartinen
2 siblings, 0 replies; 19+ messages in thread
From: Mike Hearn @ 2011-09-15 16:21 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
> 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 to the node owner. Not the sender, who may in a better
position to debug.
It's pretty common for protocols to return useful errors even in DoS
conditions. Eg, http servers will often return 503 Service Unavailable
in overload conditions. Google actually sends a redirect telling you
why you got blocked.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 16:04 ` kjj
@ 2011-09-15 16:41 ` solar
2011-09-15 17:29 ` Luke-Jr
1 sibling, 0 replies; 19+ messages in thread
From: solar @ 2011-09-15 16:41 UTC (permalink / raw)
To: kjj; +Cc: bitcoin-development
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 change in usage dictates allowing things that weren't allowed before. Essentially every new service, protocol (or creative use of an existing protocol) needs to be 'opened up' so it's a hassle to change it each time.
Perhaps there is a use for this in helping implement local policy but even something that's considered a 'liberal' filtering rule today will eventually be in the way of something legitimate and will need to be adjusted. It is not possible to just adjust this network wide when and adjustment needs to be created, so any type of built-in filtering is limiting to future innovation.
Maybe this type of thing would be better implemented in a separate bitcoin proxy - much like how a firewall can be placed between a router and network. All traffic is legitimate to a router (bitcoind) if it's formatted correctly and can be forwarded, but the firewall can implement local policy. The problem with providing this out-of-the-box is that even in the case of internet traffic, they are often misused and configured too restrictively so they end up causing service problems for the users behind them.
I think the idea is good, in that we need a way to filter out things we consider bad, but I don't think it is the job of the bitcoin client. There are tons of tunable things and people will want to tweak them - what is 'a lot' to me might be nothing to someone else. People's policies will differ greatly as you can see with everything else on the internet.
Laszlo Hanyecz
solar@heliacal•net
On Sep 15, 2011, at 4:04 PM, kjj wrote:
> 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 those with "insufficient" fees should not
>>>> be penalised. These are properly relay/miner policy decisions, not
>>>> protocol violations, and should be made more easily configurable, not
>>>> punished for configuration.
>>> A few non-standard transactions are probably legitimate. A whole bunch
>>> of them are probably not. I would think that assigning a point or two
>>> of badness to a peer sending one is pretty reasonable, with the
>>> understanding that we would need to adjust that as the network evolves.
>> No. There is no such thing as "non-standard transactions" really; it is simply
>> "transactions outside of the bounds that I as a user/miner will relay/accept".
>> It is perfectly legitimate for other users/miners to relay/accept transactions
>> more liberally. By penalising for transactions falling outside of your
>> *personal policies*, you would end up banning many legitimate nodes.
> It is certainly true that standardness is an artificial construct that
> only has meaning to this particular implementation of the software, but
> no meaning in the context of the protocol or the system as a whole.
>
> 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 dozens or hundreds, it is hardly unreasonable
> to disconnect them until you figure out what's going on.
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 16:04 ` kjj
2011-09-15 16:41 ` solar
@ 2011-09-15 17:29 ` Luke-Jr
1 sibling, 0 replies; 19+ messages in thread
From: Luke-Jr @ 2011-09-15 17:29 UTC (permalink / raw)
To: kjj; +Cc: bitcoin-development
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 dozens or hundreds, it is hardly unreasonable
> to disconnect them until you figure out what's going on.
That would make sense if you knew the node was originating them, MAYBE--
but not given the fact that they may merely be relaying transactions.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 16:19 ` Gavin Andresen
@ 2011-09-15 17:41 ` Douglas Huff
[not found] ` <CABsx9T3HCVAn5ECuPWfAyZ4zt3WCbyKPF-7DV1HY2j2TKjavrg@mail.gmail.com>
0 siblings, 1 reply; 19+ messages in thread
From: Douglas Huff @ 2011-09-15 17:41 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
On Sep 15, 2011 11:20 AM, "Gavin Andresen" <gavinandresen@gmail•com> 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 prevent
network flooding.
[-- Attachment #2: Type: text/html, Size: 446 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
[not found] ` <CABsx9T3HCVAn5ECuPWfAyZ4zt3WCbyKPF-7DV1HY2j2TKjavrg@mail.gmail.com>
@ 2011-09-15 18:36 ` Douglas Huff
2011-09-15 19:07 ` Gavin Andresen
0 siblings, 1 reply; 19+ messages in thread
From: Douglas Huff @ 2011-09-15 18:36 UTC (permalink / raw)
To: Bitcoin Dev Development
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On Sep 15, 2011, at 1:17 PM, Gavin Andresen wrote:
>> On Sep 15, 2011 11:20 AM, "Gavin Andresen" <gavinandresen@gmail•com> 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 prevent
>> network flooding.
>
> Have you submitted a patch to fix it?
No, it requires the entirety of the p2p network code be reworked and large patches aren't accepted.
No reason to take that off list, it's an issue that's been acknowledged on irc numerous times and is in the public channel logs.
--
Douglas Huff
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 18:36 ` Douglas Huff
@ 2011-09-15 19:07 ` Gavin Andresen
0 siblings, 0 replies; 19+ messages in thread
From: Gavin Andresen @ 2011-09-15 19:07 UTC (permalink / raw)
To: Douglas Huff; +Cc: Bitcoin Dev Development
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 phantomcircuit's "here's a
python script that will kill any bitcoin node on the network" 0-day
exploit), then please start a new topic.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] Request review: drop misbehaving peers
2011-09-15 14:06 ` Gavin Andresen
2011-09-15 14:21 ` Gregory Maxwell
2011-09-15 16:21 ` Mike Hearn
@ 2011-09-16 12:57 ` Joel Joonatan Kaartinen
2 siblings, 0 replies; 19+ messages in thread
From: Joel Joonatan Kaartinen @ 2011-09-16 12:57 UTC (permalink / raw)
To: bitcoin-development
> Darn good question. If the protection fails, would it be better for it
> to 'fail hard', leaving people complaining "bitcoin won't stay
> connected!"
>
> Or fail soft, so you at least have a couple of connections.
>
> I think fail hard is better-- we'll immediately know about the
> problem, and can fix it. Fail soft makes me nervous because I think
> that would make it more likely a bug splits the network (and,
> therefore, the blockchain).
My own preference would be to fail hard with detection of the problem
and notification of the user if there's a GUI connected and/or running.
- Joel
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2011-09-16 12:57 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-15 1:57 [Bitcoin-development] Request review: drop misbehaving peers Gavin Andresen
2011-09-15 2:06 ` Luke-Jr
2011-09-15 10:43 ` Christian Decker
2011-09-15 12:56 ` kjj
2011-09-15 15:36 ` Luke-Jr
2011-09-15 16:04 ` kjj
2011-09-15 16:41 ` solar
2011-09-15 17:29 ` Luke-Jr
2011-09-15 16:19 ` Gavin Andresen
2011-09-15 17:41 ` Douglas Huff
[not found] ` <CABsx9T3HCVAn5ECuPWfAyZ4zt3WCbyKPF-7DV1HY2j2TKjavrg@mail.gmail.com>
2011-09-15 18:36 ` Douglas Huff
2011-09-15 19:07 ` Gavin Andresen
2011-09-15 11:45 ` Mike Hearn
2011-09-15 12:25 ` Gavin Andresen
2011-09-15 13:00 ` Stefan Thomas
2011-09-15 14:06 ` Gavin Andresen
2011-09-15 14:21 ` Gregory Maxwell
2011-09-15 16:21 ` Mike Hearn
2011-09-16 12:57 ` Joel Joonatan Kaartinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox