Great instead of developers responsibly engaged towards finding a solution - you're promoting cat and mouse.

You realize you're also saying fuck it to net-neutrality? And trying to take into private hands what kind of transactions people should and shouldn't make on the Blockchain.

Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.

Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.

I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.

Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.

We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.

But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.

Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.

[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.

@suppow: Hi, it was good to meet you at CoinSummit!

Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.

Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.

I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.

Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.

We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.

But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.

Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.

[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.

@Matt: Hi, it was good to meet you at CoinSummit!

how much does it actually cost to run some full nodes?

I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin  

I'm serious...

Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

Intriguing dexX7! Go on... What are you thinking?

OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.

Long before the network gets anywhere near as large as that, it would be safe
for users to use Simplified Payment Verification (section '8') to check for
double spending, which only requires having the chain of block headers, or
about 12KB per day.  Only people trying to create new coins would need to run
network nodes.  At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware.  A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.

Instead of pumping resources into getting 40 additional bytes, why don't we actually start to build an overnet instead? I'm extremely thrilled by the idea and I somehow hope this all gets pushed even further in that direction.

That's missing the point, then you're back to the question of how do we securely store data in an accessible, decentralized way, and it's onto side-chains, which come with their own problems and which no one has coded working functionality for - that Counterparty has here and now, and this is for 40 bytes of economy with only pseudo-speculative importance, when as Canton said gambling transactions are taking up 5gb to Counterparty's 5 mb.
I do agree the status of these things may change, but as I wrote, I don't see why speculations about the future should regulate implementation that a freemarket is capable of doing on it's own.