Quote from: d'aniel on February 24, 2014, 01:58:33 AM

Quote from: Peter Todd on February 23, 2014, 09:18:17 AM

You don't need OP_RETURN to store data, particularly hashes. The idea being it was to encourage people to store data in the least harmful way possible in outputs that can be obviously pruned; like it or not putting data in the blockchain is useful so people will do it, and there's no good way to stop people from doing so.

As you pointed out in a recent post*, P2SH^2 on the scriptPubKey side and MASTs on the scriptSig side would work to keep the blockchain from becoming a garbage dump. Since both of these changes would be very good for both scalability and privacy, I don't understand why you were so quick to write them off as unlikely.

"Garbage dumbp"

Please, don't write off useful applications for proof-of-publication so quickly. Heck, just the other day I realized how it could be used to create decentralized digital asset exchanges with cryptographically verifiable pricing that was inherently resistant to market manipulation: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03892.html

Quote from: d'aniel on February 24, 2014, 01:58:33 AM

Quote

Of course, once data is prunable, it's no different than any other transaction in terms of impact on the system - you're still paying fees on the exact same basis as doing any other transaction.

The problem is that non-Bitcoin applications compete for scarce block space, driving up the cost of transactions for Bitcoin users. As you know, this cost is either felt in the form of fees, or increased centralization if the block size is simply raised to accommodate. I don't think it's unreasonable to say that Bitcoin users ought not be burdened by arbitrary demands of its blockchain.

What is or isn't a "Bitcoin application" is open to debate. I certainly think decentralized finance has the potential to be valuable, and it will be quite concretely based on Bitcoin as a medium of exchange in actual applications. More to the point, if I wish to, say, use a multisignature protected wallet, I'm creating transactions that take up significantly more blockchain space than those that don't. Of course, I pay for that space in fees, driving up costs for all Bitcoin users... So am I wrong for doing that?

Quote from: d'aniel on February 24, 2014, 01:58:33 AM

You mentioned it being better to just focus on the root of the problem - fundamental scalability - but the potential solutions I've seen proposed by you seem like very radical changes (far more so than P2SH^2 or MASTs), and the conservative approach appears to be to protect the blockchain from abuse to the greatest extent possible at least until a particular scalability upgrade has been 1) implemented, 2) well-tested, and 3) widely agreed upon.

Regarding OP_RETURN though, I agree that it's the proper way of doing damage control (though I worry that it sends the wrong signal to users that this usage is acceptable, and not abusive, and will encourage more of it), but only while P2SH^2 and MASTs are not yet implemented.

My worry is if we don't stick to a strict market-based allocation of proof-of-publication security we're going to see an acceptance in this community of rationing it based on perceived value. Frankly, this is much like net neutrality debates - I believe in applying freedom of choice and non-judgemental market principles rather than having a small group of devs and pool operators decide what is or isn't the valid use of the Bitcoin blockchain.

As for my advice, again, I know that P2SH^2 and MAST's are quite hard to deploy, which is why my advice to users who think they have a use-case for data-in-the-blockchain is to go ahead and do so now. They'll have a few years to show that their applications are in fact valuable, at which time a majority of hashing power may decide that implementing anti-data-in-chain techniques would be a mistake. Also, it increasingly looks like the scalability stuff I'm working on can be done transparently in a backwards compatible manner - actually implementing that stuff may prove to be less of a disruption than forcing all Bitcoin software to use new address types.