Post
Topic
Board Development & Technical Discussion
Re: Error code -22 on OP_RETURN tx
by
Peter Todd
on 25/02/2014, 02:18:28 UTC
If anything, not being forced to curate the "garbage dump" in addition to the Bitcoin blockchain would enable more people to run Bitcoin full nodes.  I understand that a lot of participants are unwilling/unable to fully verify, but hijacking the Bitcoin blockchain for a zillion other often unrelated and often unwelcome applications just makes the problem worse.

But again, in the merge-mining for proof-of-publication case, unless mining hashing power is more decentralized the merge-mining is not proof of anything, resulting in insecure applications.

I get your point though about parasitic users being incentivised to be, well, parasitic.

Also, even if there is ultimately no technical means to prevent blockchain hijacking, this doesn't mean social pressures can't work to some useful degree.  Well-respected developers being vocal about it at the very least this gives less abusive alternatives a PR advantage, or can correct the most egregious abuses - like e.g. mastercoin's initial use of non-prunable outputs.

You realize that the dev's involved appear to have managed to lose that social respect overnight by making an about-face on the idea of OP_RETURN? You may not think that within this small community, but within the community of people making use of data and metadata-using transactions they have. Just a week or two ago I was arguing with someone - a paying client - that the OP_RETURN thing was certainly going to be released and they should go to the effort of using it for their application. Well, looks like I was wrong, and when I talked to them again earlier today their plan is to stick with what they had written initially and use UTXO-bloating outputs.

TXO commitments are just a small part of solving scalability - they only help with long-term storage and actually make bandwidth scalability significantly worse. They do appear to be a good approach to blockchain sharding - tree-chains makes use of them - but the people who have been claiming they represent some scaling breakthrough misunderstand the technology.
Right, I calculated a little while back something like a ~7 fold increase in bandwidth (for authenticated prefix trees), but my understanding was that they are useful because they enable partial verification/fraud discovery and distributed block construction, which spreads the increased bandwidth load over a much larger number of participants.  Is this a misunderstanding?  Or just an overestimation of the number of extra participants?

Yup - they don't make distributed block construction possible by themselves. Which is a really serious problem actually as what could happen is they just act to paper over the scalability problem and leave us in a situation where it lets a larger block size or similar look scalable, which further centralizing control of mining. I gotta admit, I was a bit reluctant to publish the idea for that reason initially, but decided it was a strict improvement on UTXO commitments so went ahead.