Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
I don't know if this meets all of the requirements stated, but based on a quick skimming of P2SH^2 and your Proof-of-Publication paper, here's a rough idea of an "attack" to store arbitrary data. This would require a tiny amount of brute-forcing, and it is not dust/fee-efficient, but I think it would work. I was unable to find the "2.0" discussion.
You missed the part where I said "no-brute-forcing" - I'm talking about something quite different that takes advantage of what P2SH^2 does. However, the rest of your post would work and is actually pretty clever, so sent you a tip all the same.
Hey, thanks man! I like these games
Unfortunately I am not very well-read on a lot of this stuff, but I've been convinced for a long time that it's impossible to prevent hiding data in Bitcoin transactions, unless somehow every output address is pre-approved, which is of course impossible without completely wrecking Bitcoin. The P2SH^2 idea seems to be trying to add a bit of "verification" to output addresses, but even requiring 2 hashes doesn't really change anything. It makes it a bit harder, but as long as output addresses are essentially arbitrary, there's no way to prevent some attack along these lines from working.And I didn't "miss" the brute-forcing, I just kind of ignored it because the brute-forcing in this scheme would (unless I'm way off somehow) only require a few milliseconds of computation for a single-byte encoding, as you'd only need to come up with hashes starting with A-Z, a-z, 0-9.