I'm replying to myself since no one is taking up a positive nor negative sentiment to my last post. It is included below.
I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.
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.
If the issue is spam control, then wouldn't that be negated a variable fee based upon based upon the level of risk that spam may be contained within the transaction? Such a variable fee in this case is non-linear to the amount of 'risky' data attached. It would remove the arbitrary nature of 40 or 80 bytes.
It is difficult to predict what is necessary or unnecessary in the future. What if I wish to publish into the ledger the the daily fixings of the history of a 500 million dollar notional interest rate swap. Perhaps at that juncture in the future we would decide it was inappropriate to be stored in the blockchain. However, if it was appropriate I would certainly be willing to pay a larger premium to place it into the ledger.
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
I agree that the blockchain isn't for general storage. I think there are use cases where the data is a) relevant and tied to the utility of Bitcoin and b) financial transactions. The 'cost' of storing such information should be structured in a way which is prohibitive to spam, encourages efficient usage of the blockchain and isn't arbitrary.
I've described in prior posts what I consider to be relevant business cases why Counterparty is relevant to Bitcoin.
I am asking the people present in the thread to enable the continued development of Counterparty in a way which doesn't hobble the usability of Counterparty. As others and myself point out, it is our opinion and the opinion of the users of Counterparty and Bitcoin that it is worth the short term inconvenience for the upside potential to Bitcoin.
Luke, there are some points we have come to agreement upon. Can't we take these points in good faith and come up with a smart solution that allows Counterparty to operate
Peter, I appreciate that you had volunteered to create a pull-request that will help Counterparty out in the short term. Agreed that I think Counterparty will need to and will have to prove it's utility and evolve to stay within the blockchain. If Counterparty fails, prune it out. Do you see other ways in which we can build a solution based upon the common ground we have found so far?