Irrelevant agenda-serving, more like...
And responding to these doesn't really bring anything forward.
Since the existing Counterparty developer(s?) outright refuse to move forward, the only other practical option for Counterparty is someone else doing it.

He knows what he's saying here is wrong.
Satoshi himself added the IsStandard restriction concept.
I have long since been opposed to using such restrictions when unnecessary: notice how Eligius is the only pool which allows non-standard transactions, and it has allowed them since nearly when I started it.
The problem here, why whitelisting is needed for mining on Eligius, is because of Counterparty's unique position (I am ignoring Mastercoin in this thread) where it is currently indistinguishable from spam, which needs to be blacklisted due to abuse.
Every other miner and relay node would require whitelisting no matter how it's done (other than abusing multisig, which will soon not work either).

It is true that forcing miners to provide you with security will result in better security than giving them a choice, because it is inevitable that some miners will opt not to provide the service.
And yes, it is also true that blockchain-based decentralised systems are always at risk of 51% attacks by design.
However, it is pure FUD to try to scare everyone away from doing the right thing by implying it is a given they will be attacked.
If you're providing a service with your altchain, it's in miners' interest to support you, not attack you, unless you are doing something harmful.
Sure, there will perhaps always be exceptions, but as long as you have a majority of miners assisting you, you'll be fine.
This is also part of why Eligius goes out of the way to support legitimate altchains which support merged mining, even if they aren't necessarily useful to the pool (for example, we helped ChronoKings/HunterCoin test their blockchain-based game).

It doesn't solve anything, since fees don't cover transaction costs.

FWIW, if there are any developers interested in keeping Counterparty going once multisig abuse filters are in place, there is no reason the recommended plan cannot work with a fork of Counterparty instead of the original developers.

I shutdown CoiledCoin by myself. Eligius miners were not involved.

This is something wrong with your pool.

No need to slander me.
I killed one scamcoin before, simply by mining it.
Was pretty funny until the scammers got up in arms.

But I have no problem with legit altcoins.
It doesn't sound like these guys do either (but I only read the first post).
I don't see any extortion either, sounds like they're just a volunteer community service team.

I never said I didn't want the Bitcoin protocol to change.
On the contrary, I support extending it to do what Counterparty wants.
But such extensions are slow-moving right now, and take time to implement properly.
I also understand Counterparty wants a solution "today".
I agree the 80-byte OP_RETURN is a good short-term way to do this.
Deploying a whitelist to miners, to accept these Counterparty transactions can be done within a few weeks.
But deploying a default relay policy change requires months (releasing a new version of Bitcoin Core, and the slowest part: waiting for all the users to upgrade).
Thankfully, there is an immediately available workaround to not having the default relay policy "on your side":
Just have Counterparty participants relay their transactions to nodes running the updated relay policy.

So, recommended course of action:
Immediate-term:
1. Write Bitcoin Core patch to whitelist 80-byte OP_RETURN-based Counterparty transactions.
2. Deploy patch to major mining pools, and open merge request with mainline Bitcoin Core.
3. Begin using OP_RETURN Counterparty immediately; use addnode to get it relayed to miners.
Short-term:
4. After discussion, patch is merged to Bitcoin Core.
5. Bitcoin Core 0.10 is released with a default relay policy accepting Counterparty transactions, and addnode is no longer needed.
Long-term:
6. Counterparty developers discuss future plans with Freimarkets developers and others interested in this kind of functionality.
7. Interested developers figure out the best way to do everything, probably including using merged-mining, side-chains, and other things that are impractical today.
8. Interested developers implement new system, and write a BIP documenting it.
9. BIP gets reviewed.
10. Counterparty users upgrade to new version based on BIP.
11. Everyone gets a break.

Hopefully that clarifies my position.

This is nonsense. Nobody on the Bitcoin Core dev team wants Counterparty to abuse multisig.
"Enlisting ... mining pools" is the only alternative to forcing mining pools against their will by hiding it in multisig (although hopefully soon we'll have a filter to deal with that).

Eligius is over 10% of the network, so it's hardly a "small subset" anyway.
Besides, if you're so confident that the other pools won't freely service Counterparty, maybe you should really re-think whether forcing it on them is acceptable??

Bitcoin doesn't have Counterparty support. I'm asking them to use a temporary side-channel in addition to normal relaying-to-random-nodes until the Bitcoin network has upgraded to support Counterparty.

PhantomPhreak is one of the two listed, and has expressed that he is only willing to do things under certain Bitcoin-hostile terms.

Unfortunately, it sounds like the Counterparty team is not interested in being a teamplayer and working with Bitcoin development, and giving Bitcoin no choice but to activate self-defences.

BFGMiner uses the chip count only to determine how many chips will be returning submits, not to determine how much work is needed.
Although earlier Bi*fury firmwares were buggy, for which BFGMiner's driver has code to workaround until it receives the first needwork message, but I don't see how that could affect this.

No, it only sends these once on initialisation (device open)...
Flushing occurs when there is a work update too.

There is definitely room to improve this, but it wasn't necessary for bi*fury and incompatible with getwork pools.

BFGMiner uses diff 1 nonces to provide more reliable statistics.
Perhaps this can be made configurable if there's a need.

As for why it's performing worse, I'd be happy to look into it.
Are you planning to send a sample unit to developers?

It's never appropriate to use the blockchain as storage.
Even if you pay a fee*, there will almost certainly still be some Bitcoin user who doesn't want to provide you with the storage.
If you want to pay people to store data for you, there's Amazon.
If you need to timestamp the data, merge mine a timestamping service.

* the fee to compensate for storage in the blockchain would far exceed Amazon's storage costs, btw

For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

Then you give us no choice but to add better filters to keep out the abuse.

I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).

40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.

Nobody is forcing you to run the reference client.
Fork it. Please.

And no, the Counterparty writeup is not an "existing Bitcoin specification".
For that claim, the developers should collaborate with the existing Bitcoin development community to formally define a BIP.

Expect to have to change the protocol at some point.
No offence intended (this is expected in ordinary development), but the current one is at best a "first draft".

If you mean the predefined relays, yes, it is a bit hackish. As is the current protocol generally.
But it will work in the short-term, while a better protocol for upgrading to can be designed.

Forcing others to provide services is not justified by the "need" for it.

It's possible. Whether it's practical, is another more complicated issue

This seems fair.

I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

Originally. But the original concept was completely impractical (and still had the centralised trust issue).

The idea behind side-chains is that you will be able to simply move bitcoins across multiple blockchains, with different properties of their own, and back again.
This makes them real-world usable, and free to do almost any kind of innovation.

Try testing with a generation transaction of 100+ kB size.
Edit: Also, I would expect it to not affect high-end hosts. Probably just embedded and crappy miner-only hosts.