4 ms·

There's already a proposal floating around on the dev list to introduce a new address type, P2SH^2, which would allow the relevant data fields currently being u

by frisco 13y ago

There's already a proposal floating around on the dev list to introduce a new address type, P2SH^2, which would allow the relevant data fields currently being used to stuff the info discussed in the article to become hashes. This would have the effect that if you wanted to stuff arbitrary data, you'd be limited to finding hash collisions. See the thread here: http://sourceforge.net/mailarchive/message.php?msg_id=30705609 http://sourceforge.net/mailarchive/message.php?msg_id=307056... I've been lurking on the bitcoin-dev list for a while to observe how they handle issues just like this. I'm confident that these problems will be transient.

daveasdf 13y ago
While such a scheme might solve this particular method of storing data, it won't make the general problem go away. For instance, if I want to publish an 'n' byte message, I could generate 'n' wallets, each having as their final byte of their fingerprint the n'th byte of my message. Constructing 'n' such wallets will require on average "256*n/2" units of work---quite small, all things considered. I can then transfer a single bitcoin to each wallet in turn, forming a linked list of the bytes in my message. Even better, I also get my coin back at the end.
- Groxx 13y ago
  Minus transaction fees, yes.
gizmo686 13y ago
It doesn't seem like hashing the data fields reduces the problem to finding collisions. Say I hash 2 values. I can distribute these and say H1 corresponds to a '1', and H2 corresponds to '0'. Now, I can store 1 bit of arbitrary data per transaction. Of course, I can increase the amount of data per transaction by exponentially increasing my initial work (and the size of the lookup table). But given that transactions are cheep, I would not need to compute the complete rainbow table to make this practical, and you only need to do the hashing once.
sneak 13y ago
Entirely unnecessary. Transaction fees address the crapflooding issue, and the fact that you can embed only a very small amount of arbitrary data in each transaction means that you're unlikely to be able to harm someone else by forcing them to "possess" your various short byte sequences (which will, on disk, of course be interspersed with the rest of the transaction data). This is to say nothing about the fact that everyone else running bitcoin will also possess these bytes in their blockchains, making the possession of them rather unextraordinary. This whole article is just the latest in "Bitcoin doomed to fail, and here's why!" bullshit that's been going on for what feels like a decade but is really only 3 years or so.
- new299 13y ago
  This is actually a big issue for bitcoin, I don't think we should avoid it by saying it's the "standard bullshit". We also not really talking about small amounts of data (at least at the moment) a few megabytes is relatively significant... I think the fact that it's "unextraordinary" to possess this data is the interesting thing. That may force a legal distinction which in itself pushes us toward a different understanding of "illegal data" and that perhaps the legal system has to give up on that and move towards accessing or "distributing with intent" being the illegal rather than just possession.

by frisco 13y ago

daveasdf 13y ago

While such a scheme might solve this particular method of storing data, it won't make the general problem go away. For instance, if I want to publish an 'n' byte message, I could generate 'n' wallets, each having as their final byte of their fingerprint the n'th byte of my message. Constructing 'n' such wallets will require on average "256*n/2" units of work---quite small, all things considered. I can then transfer a single bitcoin to each wallet in turn, forming a linked list of the bytes in my message. Even better, I also get my coin back at the end.

Groxx 13y ago
Minus transaction fees, yes.

gizmo686 13y ago

It doesn't seem like hashing the data fields reduces the problem to finding collisions. Say I hash 2 values. I can distribute these and say H1 corresponds to a '1', and H2 corresponds to '0'. Now, I can store 1 bit of arbitrary data per transaction. Of course, I can increase the amount of data per transaction by exponentially increasing my initial work (and the size of the lookup table). But given that transactions are cheep, I would not need to compute the complete rainbow table to make this practical, and you only need to do the hashing once.

sneak 13y ago

Entirely unnecessary. Transaction fees address the crapflooding issue, and the fact that you can embed only a very small amount of arbitrary data in each transaction means that you're unlikely to be able to harm someone else by forcing them to "possess" your various short byte sequences (which will, on disk, of course be interspersed with the rest of the transaction data). This is to say nothing about the fact that everyone else running bitcoin will also possess these bytes in their blockchains, making the possession of them rather unextraordinary. This whole article is just the latest in "Bitcoin doomed to fail, and here's why!" bullshit that's been going on for what feels like a decade but is really only 3 years or so.

new299 13y ago
This is actually a big issue for bitcoin, I don't think we should avoid it by saying it's the "standard bullshit". We also not really talking about small amounts of data (at least at the moment) a few megabytes is relatively significant... I think the fact that it's "unextraordinary" to possess this data is the interesting thing. That may force a legal distinction which in itself pushes us toward a different understanding of "illegal data" and that perhaps the legal system has to give up on that and move towards accessing or "distributing with intent" being the illegal rather than just possession.