Quote from: baddw on March 31, 2014, 04:33:42 PM

Quote from: Peter Todd on March 31, 2014, 09:50:41 AM

Quote from: baddw on March 31, 2014, 09:00:15 AM

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 Grin

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.

Disclaimer: I have not looked into the details of how P2SH^2 or even P2SH works yet.

I also think it's not possible to prevent embedding data. In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.

Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions? Most of it could just be sending coins back and forth between your own "alphabit" addresses.

For the non-brute force solution, embed your bits into all the transaction values. ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.