Selfish behavior is great until it wrecks the environment.

Hmm, how big of a backlog does warrant attention?  Perhaps we should focus on confirmation times?

If Bitcoin fees climb high enough then other altcoins with lower fees will begin to see adoption.

With a backlog like that, shouldn't every block be full all the time until the backlog is processed?

Hmm, then maybe the right thing to do is boost it now, this time, to the maximum of 32MB (or whatever the maximum possible is).  Someday won't we need huge blocks to get the throughput?  If we don't *ever* boost the size then won't that constrain the adoption of Bitcoin?

Me too.  Let's try 1.1MB for a little while to see.  Depending on what we learn then we can fallback to 1MB or try the next increment of like 1.2MB or something.  Why do we feel compelled to jump to 2MB all at once?

Oh, good points; can we be more surgical and blacklist just blocks below some threshold in size from anyone?  Hmm, unless the mempool is low enough then small or empty blocks are ok.  Hmm, filling up a block with junk transactions isn't what we want.  Oh, maybe their mempool was low at the moment due to something, e.g. network issues.  Hey, this might not be an easy issue.

Me either.  I asked; you didn't answer; condoning avoided.  What can we do instead?

We don't.

How can we make it worse for an attacker?  Enlist the support of militaries to make them cut it out?

So, will Antpool die naturally or will it need help?

Is it possible to modify/enhance Bitcoin to reject/ignore blocks from Antpool?  If we don't forward their crap empty blocks then no one will build on top of them, right?

Er, nothing is stopping them but the risk of breaking confidence in Bitcoin and ruining it.

I do feel badly if they just looked like misbehaving peers when in fact they were ok.  Perhaps some other node can give them what they want/need.  Sorry.  Hopefully my node doesn't look like a misbehaving peer to anyone else.

I determine a peer is misbehaving based on mostly huge number of Bytes Sent, longest Ping Times, and low Starting Height (although this is least offensive to me).  An unknown Sync Height is not attractive.

I've unilaterally cut off another; 93.230.229.149.  Blocking these are saving me a ton of bandwidth.

Is there any harm in creating a firewall rule to block inbound attempts from what appear to be abusive peers, e.g. 85.214.11.209?

From the looks of things, my node sends about 10x as much as it receives; so, I figure at least I am not a drag on the network.  Valid thinking?

Neat; I feel better about my non-mining full node.  I'm not crystal clear how much difference it makes but just feeling like I am contributing is nice.  I would dearly like to be able to quantify my contribution but haven't a real clue how to start.

I'm confused (a not uncommon state); *if* mining (as we know it today) gives way to a PoW "transaction fee" then who is putting blocks together?  Apparently *only* those who want transactions to go through into the longest chain.  If I have one lonely transaction then I personally (well, my computer) have to compute a winning block; geesh.  Can't I just broadcast my transaction and let someone else block it into the chain for me?  I'll pay them; why do I have to pay with PoW?  So, for folks with modest/low transaction rates, they team up with each and pay someone with enough iron to get their transactions into the longest chain.  The faster this someone is, the more fee they can command.

I like it; I can choose which service I want.  If a service fails to satisfy then I can move on to another.  Competition for my transactions!

Bitcoin as it stands today, does not facilitate competition for transactions; oh wait, it does.  Hmm.

The real lesson to learn is the Bitcoin support function is vital.  A healthy prompt response makes all the difference.

*If* it's so unlikely then why in the world do we often/regularly get orphaned chains of more than 1 or 2 blocks?  Orphaning an individual block isn't too hard to see; it doesn't take too much bad luck.  Orphaning 2 blocks; well, some portion of the network was working on each side and we just got unlucky again despite the difficulty being >144,000,000,000 at the moment.  The difficulty is set just right so that on average the blocks will pop out every 10 minutes or so; despite that we do see them found in way less time, e.g. <1 minute, occasionally.

If a burst of blocks are found on different chains then it is just tough for all of those orphaned blocks.

Still convergence (with some amount of pain) comes eventually *if* (and this is crucial) the network isn't partitioned for too long.  A prolonged partitioning will lead directly to multiple Bitcoin chains being formed.  Anyone able to transact on both chains can wreck havoc.  Anyone wanting to avoid being ripped off would have to check both sides (one wonders how they overcame the partition).  If/when the partition is removed then the weaker side will lose out everything they did during the break.

*If* we believe the partition is only going to last for a little while then it is best for the weak side to stop producing blocks until we're back together.  How does one know which side of the partition they are on?  Measure the production of blocks, i.e. hashrate, and compare that to the total amount measured before the partition.  So, don't stop producing blocks, just know that they are going to be thrown away.

*If* we believe the partition is going to last for a long enough time but not forever then pausing the weak side ain't great.  I suppose some sort of conversion to a new coin would have to happen.  Good luck convincing people on your side that you won't be transacting on the other side.  Yuk.

*If* we believe the partition is never going to be undone then the weak side can just keep going.  We would probably want to quickly implement some header version change or something just in case the partition were to be breached.

*If* you don't think a major partitioning event is possible or won't happen then please pass whatever you are altering your mind with over; it must be really good shit.

I suppose if you are all by yourself then you should converge instantly all the time unless you are flawed, e.g. schizophrenic.  With two or more independent parties involved, the whole trick is keeping the rift-raft out of your way.  Unless you know/trust each and every other party via a secure/reliable channel convergence might always be questionable.  The real question is, "Can we do business for now with a system that might fail us someday?"  The apparent answer is yes.  On the other hand, this is no reason to stop trying to improve the system.

Weighting the risks of two systems against each other is well worth the effort.  Compare today's modern cash transaction verses a Bitcoin transaction.  Um, hmm, we agree to exchange cash for something.  The provider of the something and the payer agree to the details of transaction, e.g. the something and an amount of cash are exchanged in a public location (for safety).  During the exchange (or even shortly there after; before we part company), an announcement is made that the value of the cash has changed (rare but not unheard of and usually announced in advance but you get the idea); is it just too bad for the provider or payer (depending on the direction of the value change)?  The things that can go wrong vary.  The cash might be flawed.  Etc.  If we want to transact remotely then things get more complicated.  Convergence (or Durability, the "D" in the ACID https://en.wikipedia.org/wiki/ACID properties, is tricky to guarantee.  In Bitcoin, effectively today there are a few levels of durability recognized; when the transaction first is broadcast around the network (is this a little like pulling one's wallet and showing sufficient funds?  no, it's more than that but it's not quite like handing it over either ... weird).  A little later it might show up in a proposed block (which is a lot better but not quite 100% durable yet) -- (is this a little like handing over the cash but it being dropped on the floor or something while being examined for counterfeit?)  If the proposed block is orphaned by another longer chain then we got to see if our transaction is in the usurper and if not then wait -- (is this like someone watching the transaction saying it looks good to me but someone else bombing in and saying wait a minute there's more to the story?)  The provider and payer stand around looking at each other wondering, "Are we ok?  Is anyone else going to come along and wreck our deal with some other news?  When is it safe for them to walk away?  After awhile enough "news"/blocks pile on that it seems pretty unlikely anyone is going to undo the chain and we walk away.  If we're wrong and it is undone even years later then the provider of the something takes the loss.  The payer got the something and paid in good faith.  The onus is on the provider to further secure the value they received, e.g. deposit the cash into a bank for safe keeping (ha!) or exchange it into something else, e.g. other goods/services.  Go buy a piece of land or some precious metal but know that those things aren't necessarily durable forever either.

When aliens arrive with computing power beyond our imagining, they could calculate a replacement chain and wreck everything.  Even without that, someone could be calculating a shadow chain and pop it out to give Bitcoin a very bad day; I know, I know, they can't keep up with the rest of the miners unless they have more hashing power.  Restarting the calculation of a shadow chain each time the shadow gets too far behind and then waiting until you get "lucky" and then popping it out is a problem.  When a transaction leaves the mempool because it appeared in the chain is the moment it becomes vulnerable to durability failing.  The client has to watch forever and retransmit *any* time later if the shadow chain appears and takes over.

Despite all the noise about 6 blocks being somehow enough, there's nothing special in the code for it; https://blockchain.info/charts/n-orphaned-blocks shows a spike of 7 blocks being orphaned.  Even longer chains can be orphaned; what's to stop it?

If a shadow chain pops up that is really long, e.g. 20 blocks, then how will the community respond?  Better hurry, the code took it at face value and is plowing forward.  Change the code to set the maximum length of a orphaned chain at 6 blocks?  When the network is partitioned due to something bad; each side of the partition will be calculating chains and only when the links (hours, days, weeks later) are reestablished can the longest chain be detected.  E.g. China cracks down and physically partitions the network (perhaps due to rising military tensions); if/when they reconnect then one side or the other is going to have the longest chain.  It doesn't even take a big network partition; all it takes is a burst of bad luck; two miners just happen to find long chains independently at the same time.  It does *not* take 10 minutes to find a block.  It can happen in a split second.  Yes, the odds are long of finding six (or any arbitrary number) or more blocks in a chain in a very short amount time but if/when it happens then it will be ugly.

Please explain how Bitcoin avoids this nightmare (besides just hoping to avoid a run of bad luck).

None of this really addresses the possibility of someone exploiting the system maliciously per se.  Does an exploitable hole really exist right now or not?  If so then is anyone actively attempting to exploit it?