[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[Spekulatius]

I shudder at the horrible issues that using backup blockchains will create. Actually, I am having to do exactly this with my automated gateway and there are so many special cases, so many things that usually work but could go wrong. My gateway is just an application, a bug or exploit would be bad, but I am doing my best to contain any damages.

If XCP was spread across multiple blockchains, any problem could well be catastrophic. What happens if the other blockchain goes on a fork or even a blockchain rollback? Disaster.  Even having data in a different block in the same blockchain is a might big pain. It is all nice and tidy if everything needed to resolve the protocol is right there. This is why i suggested the compression approach. This is why the devs do not want to use any "pointers" to other blockchains regardless of how nice it sounds.

Im thinking more along the line of increasing redundancy with additional blockchains. Desaster would be the case if we relied on one blockchain only and something catastrophic happens to it, breaking XCP functionalities. Having copies of the same data in different places sounds like a good idea to me (Bonus points for added decentralization). On top of saving us from catastrophic failure, we also increase stability and reliability of the services XCP provides. After all its a tool for business and no business man wants to use something he cannot rely on. Otherwise risks would outweigh the benefits. We want to avoid that. Maybe I missunderstood your complaint, if so pls explain.

[1714178133]

1714178133

[1714178133]

1714178133

[jl777]

I shudder at the horrible issues that using backup blockchains will create. Actually, I am having to do exactly this with my automated gateway and there are so many special cases, so many things that usually work but could go wrong. My gateway is just an application, a bug or exploit would be bad, but I am doing my best to contain any damages.

If XCP was spread across multiple blockchains, any problem could well be catastrophic. What happens if the other blockchain goes on a fork or even a blockchain rollback? Disaster.  Even having data in a different block in the same blockchain is a might big pain. It is all nice and tidy if everything needed to resolve the protocol is right there. This is why i suggested the compression approach. This is why the devs do not want to use any "pointers" to other blockchains regardless of how nice it sounds.

Im thinking more along the line of increasing redundancy with additional blockchains. Desaster would be the case if we relied on one blockchain only and something catastrophic happens to it, breaking XCP functionalities. Having copies of the same data in different places sounds like a good idea to me (Bonus points for added decentralization). On top of saving us from catastrophic failure, we also increase stability and reliability of the services XCP provides. After all its a tool for business and no business man wants to use something he cannot rely on. Otherwise risks would outweigh the benefits. We want to avoid that. Maybe I missunderstood your complaint, if so pls explain.

XCP is already in the bitcoin blockchain, which is replicated thousands of times. It already has all the redundancy needed and is currently probably the most secure place to store data, short of some super secret defense dept archive system

The problem I see with having some of the XCP mission critical data in a different blockchain is that if something happened to that blockchain, then it will affect part of the trades, but not all of them. With XCP fully resident on the bitcoin blockchain, if anything strange happens, like a blockchain rewind, all the XCP transactions get rewound too!

If some of the transaction details are on the LTC chain and it gets rolled back, now we have some transactions that half happened and half didnt happen. The Poloniex XCP incident on a across the board scale.

Short of increasing confirmation times to the neighborhood of a day to be sure the other blockchain is stable, I see no way to avoid this risk. Clearly, a one day confirmation time will make Mr. Moneypack start having a lot more fits, so lets not go there. I doubt anybody would agree to a one day confirm time.

So, even though it sounds like we get more redundancy by utilizing a different blockchain, we actually get a LOT more risk and very little added redundancy. After all what is BTC redundancy vs (BTC+LTC) redundancy?

James

[sparta_cuss]

I would like to bring a topic for discussion to get clarity in my mind with your help:
...
CITYGLUT once answered me that XCP is required- but again I am asking: to what extent? can we try to quantify/forecast the use and demand just like we would for a for profit company?
...
NXT- people didnt see a problem - and they see NXT as a store of value backing up the system. I dont see it simply because this ISN'T a company and no stocks are sold. it is a decentralized ecosystem and only the unit of excahange count for real ECONOMIC value (investment wise). the store of value is the platform and code but it cant be quantified financially without real transactions with a currency as mentioned.
...

Thank you, freedomfighter, for asking this question. I saw that you asked at least twice in the NXT forum and did not get an adequate reply. The devil is in the details, but so is the value proposition.

A helpful answer would include examples or a particular use case. Let's use BTT, since they are a live proposition. How will XCPs gain value (how and why will people want to acquire and hold XCPs) if they want to participate in BTT's services? Let's go step-by-step here and see how many times and in what ways a client or BTT has to actually touch XCPs.

EDIT: In 1998, when people were wondering how dotcoms would be worth their extraordinary valuations, the reply was usually "web traffic," "clicks," or something like this. The assumption was that the value of the dotcom had to do with how many users or visitors a website could count. "Just give away some service and once you have your customers locked into your business, then you can figure out how to get money out of them." The business model could come later, they said. For most, alas, that model never did.

[jgarzik]

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

[BitcoinTangibleTrust]

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

Thanks for sharing your thoughts Jeff. So, will you help us start engaging with the existing bitcoin core-dev community? It's in Counterparty's interests to act as a responsible partner as we need the bitcoin blockchain if we are to survive. Will you let us know how we can start working together on these questions?

What would you recommend as some first steps we can take to start to engage and build a constructive relationship?

[jl777]

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...

[johnybyo]

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?

[Luke-Jr]

Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...

The miners are supposed to filter out abuses.
Human problems need human solutions.

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?

The problem isn't new layers, it's forcing things on people against their will.
New layers can be done on an opt-in basis, without polluting the blockchain and forcing non-participants to store the data.

[baddw]

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

"All volunteer"?  I think that's somewhat misleading.  It's not like Bitcoin is Folding@home or something where the nodes are running for a glorious altruistic purpose.  Bitcoin nodes are running because it is profitable to do so (in the case of mining) or they hold Bitcoin and have a vested interest in preserving its value.

Counterparty and Mastercoin play by the rules of Bitcoin.  XCP users pay transaction fees and, to my limited understanding, frequently create unspendable outputs which effectively deflate Bitcoin and so theoretically make every BTC worth a little more, given a set market cap.

Furthermore, XCP is basically extending the utility of Bitcoin.  I think of XCP/MSC as being the JavaScript to Bitcoin's HTML.  Yes, HTML was a revolution, but you essentially could only do one thing with it.  The truly interesting stuff started happening once we allowed little programs to run on top of it and modify it.  We now have fully dynamic, interactive programs running within a Web browser with no plugins needed.  As somebody who started in Web Development back when Netscape was dominant and the coolest thing you could do with JavaScript was change an image on mouseover, I am blown away at the orders of magnitude how much more useful basic HTML is today than it was 15 years ago.

There are some competitors such as BitShares or NXT that run on completely different networks but are trying to achieve the same thing.  Kinda like, say, Flash -- abandon HTML completely, start from scratch and build something that in some ways is more capable than HTML+JS but less compatible, requiring a separate software download and install.

We all know how that story played out.  But if Microsoft had never added a little thing which came to be called XMLHttpRequest to Internet Explorer 5, eventually birthing AJAX and the fully interactive JSON-loaded sites that we have today, the Web might have moved on past HTML.  Would HTML still be around today, or would everybody have moved on to something more fully-featured like Flash (God forbid)?  The duo of HTML+JS = "Web 2.0" has won, but there's no guarantees in this world.

I believe in the BitShares idea, and the NXT idea, and the Ripple idea.  All of these are starting from scratch and building their own networks.  I also believe in the Counterparty and Mastercoin ideas.  Mastercoin and XCP are preserving the Bitcoin blockchain and creating useful structures on top of that blockchain.  To my mind, that should be exciting as hell to someone invested in the Bitcoin community and (presumably) Bitcoins as a currency.  It's a value-add, pure and simple.  And while nobody can predict the future, IMO these features provide a much more compelling future for Bitcoin than the alternative, where so-called "Crypto-Currency 2.0" products simply leave Bitcoin in the dust and abandon PoW-mined blockchains altogether.

I think that I understand your point about unspent outputs being memory hogs for the Bitcoin network nodes.  But AFAIK, this is the one thing that Bitcoin CANNOT do away with.  It seems that Counterparty would be happy to use the 80-byte OP_RETURN space (which, AFAIK, only takes up space in the blockchain and does not remain resident in the active memory of nodes), but with only 40 bytes of space, they are forced to use unspent outputs for some transactions; and if OP_RETURN gets shortened further, unspent outputs will be used for all transactions..

Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end.  It would quickly turn into a cat and mouse game.  Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum.  I don't think that anybody wants that.

[BitcoinTangibleTrust]

Is there a way for the bitcoin protocol to prevent the way XCP is using it, without breaking anything else?
That seems like a very big potential issue if we dont get this resolved...

The miners are supposed to filter out abuses.
Human problems need human solutions.

Not sure i understand right but bitcoin core dev team dont want anyone make new layers over bitcoin blockchain?

The problem isn't new layers, it's forcing things on people against their will.
New layers can be done on an opt-in basis, without polluting the blockchain and forcing non-participants to store the data.

Thanks for engaging with us Luke-Jr. Will you be able to elaborate on how this opt-in basis would work and why reducing OP_RETURN from the proposed 80 bytes was better for bitcoin? It seems that the 40byte reduction might be the first step in a slippery slope to zero bytes in the future by the bitcoin core devs.

Will you help us understand the ways we can work together constructively?

[Luke-Jr]

Thanks for engaging with us Luke-Jr. Will you be able to elaborate on how this opt-in basis would work

Merged mining, and/or hopefully soon bitcoin side-chains.

and why reducing OP_RETURN from the proposed 80 bytes was better for bitcoin?

Because:

• Too many people were getting the impression that OP_RETURN was a feature, meant to be used. It was never intended as such, only a way to "leave the windows unlocked so we don't need to replace the glass when someone breaks in". That is, to reduce the damage caused by people abusing Bitcoin.
• 40 bytes is more than sufficient for all legitimate needs for tying data to a transaction: you get 32 bytes for a hash, plus 8 bytes for some kind of unique identifier (which really isn't necessary either!).
• The original 80 byte proposal was intended to be for 512-bit hashes, but this was determined to be unnecessary.

It seems that the 40byte reduction might be the first step in a slippery slope to zero bytes in the future by the bitcoin core devs.

Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.

[jl777]

Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.

In your opinion, which category do you feel XCP falls into?

[Luke-Jr]

Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.

In your opinion, which category do you feel XCP falls into?

I haven't looked at XCP in detail yet, so I'll have to defer to others who have.

[johnybyo]

Now, I am just a disinterested observer here (with investments in Bitcoin and all major 2.0 cryptos) so I don't speak for anybody but myself here; but it seems to me that Counterparty has Bitcoin over a barrel somewhat, especially with respect to the unspent outputs, which would be quite difficult to selectively block on the Bitcoin end.  It would quickly turn into a cat and mouse game.  Bitcoin could implement code to detect and block XCP transactions, but XCP changes a few parameters and re-launches a week later to get around it, which causes Bitcoin to respond, which causes a new change in XCP, etc. ad nauseum.  I don't think that anybody wants that.

If that go to this way then i think Bitcoin dev team shoot own leg in long run. New innovations choose sure other places like LTC if they make situation "development friendly" instead try kill all projects. And like XCP have make also good to Bitcoin when have burn btc:s and in theory make every bitcoin value higher and also pay miners fees so i dont see why here is not btc core team time talk about cooperation?

[BitcoinTangibleTrust]

Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.

Thanks Luke-Jr. Please bear with me. Although I am not the most technically bitcoin-competent, I'm trying to ask questions so we can continue to host a conversation and share further insights from bitcoin core-devs like yourself.

Maybe I'm wrong, but I am reading your words as follows: Miners will always decide their interests in what type of transactions they wish to mine. Currently, Counterparty uses multisig which are standard transactions. Although we do not wish to add to blockchain bloat, it would appear that as long as we are allowing miners to achieve their economic interests in mining all standard multisig transactions, then the system is working as it should.

Am I understanding your thoughts correctly?

[Spratan]

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

[ShroomsKit_Disgrace]

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

So lets everybody with a 2.0 point of view change to NXT and eventually to Etherium! BTC is no longer cool!  

[qtgwith]

+1 for Common Sense

When you really think about it in a global way, storing data in a second blockchain is even more wasteful.

Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty

Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.

Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors?  Why even have OP_RETURN?  Why even have script if we really want to save every bit of space?

Counterparty is just tiny writings in the margins of the Bitcoin book.  Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.

Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries.  It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.

Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.

It is called a free ride.  Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource.  The network replicates transaction data, so why not come along for a free ride?

Rather than engage the existing community, mastercoin and counterparty simply flipped an "on" switch and started using bitcoin P2P nodes as unwanted data stores.  An unspent transaction output was never meant to be used as arbitrary data storage.  The fact that it can be abused as such does not make it right, or remotely efficient, or the best solution.

The UTXO (unspent transaction output) database is the entire network's fast access database.  Every single node needs that database to be as small as possible, for best processing of network transactions.  Encoding arbitrary data into unspent outputs is network-wide abuse, plain and simple.  The entire network bears the cost.

Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

So lets everybody with a 2.0 point of view change to NXT and eventually to Etherium! BTC is no longer cool! 

NXT "BTS" and "Ethereum" have no robust ecosystem as BTC has.

[Fernandez]

Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

Thats how I see it too. The arrogance of these guys is amazing. MSC and XCP is extending the functionality of Bitcoin and may be something good have and compete with NXT, Bitshares and Ethereum.

XCP can move onto other chain, or I suggest get its on PoS chain. This will also prevent the archaic 10 minute wait.

[JahPowerBit]

40 bytes is more than sufficient for all legitimate needs for tying data to a transaction

To me the word "legitimate" is the main problem.
Who can claim the power to say: this data is legitimate and that another is not legitimate. This is called censorship!

The question can not be: What data is legitimate to be stored in the blockchain?
Because this is a subjective question, and that no one can claim to have the answer.

The only question is: Should we allow the storage of data in the blockchain?
And the answer is: there is no choice, because it is possible to do with multisig transaction.
So the question becomes: Should we let people store data in multisig transactions or provide a cleaner way to do it?

History has shown that it is much smarter to regulate than to ban something that is impossible to ban.