[Bitcoin-development] Request review: drop misbehaving peers

[Bitcoin-development] Request review: drop misbehaving peers

[Gavin Andresen]

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

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Luke-Jr]

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.

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Christian Decker]

[-- 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 --]

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Gavin Andresen]

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

Re: [Bitcoin-development] Request review: drop misbehaving peers

[kjj]

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.

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Stefan Thomas]

[-- 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 --]

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Gavin Andresen]

> 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

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Gregory Maxwell]

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)

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Luke-Jr]

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.

Re: [Bitcoin-development] Request review: drop misbehaving peers

[kjj]

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.

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Gavin Andresen]

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

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Mike Hearn]

> 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.

Re: [Bitcoin-development] Request review: drop misbehaving peers

[solar]

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

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Luke-Jr]

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.

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Douglas Huff]

[-- 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 --]

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Douglas Huff]

[-- 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 --]

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Gavin Andresen]

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

Re: [Bitcoin-development] Request review: drop misbehaving peers

[Joel Joonatan Kaartinen]

> 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