Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitstamped

bitstamped.io

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Bitstamped

#51

Post by asciimo »

maaku wrote: post #49

There are better ways to do this. You shouldn't be pushing this kind of data into an OP_RETURN output where you are burdening the entire network to store, retransmit, and validate that information from now until the heat death of the universe. No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. You can even work with your competitors on a common format and have…

Or use Namecoin, which was designed to store arbitrary information. http://en.wikipedia.org/wiki/Namecoin#Uses

Re: Bitstamped

#52

Post by kyledrake »

The Winklevoss example is lacking.

It's not important who thinks of an idea first, it's important who implements it and gets people to use it.

Re: Bitstamped

#53

Post by gwern »

JackC wrote: post #37

A version of this idea I really like is Crypto Stamp: http://cryptostamp.net/ What kills you with Bitcoin timestamping is transaction costs. It's fine for timestamping that one brilliant screenplay, but not timestamping every photo you ever take, every video created by your security system, every file pushed out to your distributed, decentralized backup network, etc. It doesn't open up any cool applications that aren…

> So with Crypto Stamp, they combine all the hashes for a given day into a single Merkle tree

Why can't you just hash your entire dataset once a week or something? Or better yet, do something like a Merkle tree of files.

Re: Bitstamped

#54

Post by gwern »

maaku wrote: post #49

There are better ways to do this. You shouldn't be pushing this kind of data into an OP_RETURN output where you are burdening the entire network to store, retransmit, and validate that information from now until the heat death of the universe. No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. You can even work with your competitors on a common format and have…

> There are better ways to do this.

No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions.

> No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to.

'Did you just tell me to go fuck myself?' 'I believe I did, Bob.'

Re: Bitstamped

#55

Post by maaku »

gwern wrote: post #54
maaku wrote: post #49

There are better ways to do this. You shouldn't be pushing this kind of data into an OP_RETURN output where you are burdening the entire network to store, retransmit, and validate that information from now until the heat death of the universe. No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. You can even work with your competitors on a common format and have…

> There are better ways to do this. No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. > No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. 'Did you just tell me t…

> No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions.

That has no relevance. You build a standard for these proofs, and they are passed around as blobs. It doesn't matter what their internal structure is.

Re: Bitstamped

#57

Post by gwern »

maaku wrote: post #55
gwern wrote: post #54

Earlier quoted context omitted.

> There are better ways to do this. No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. > No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. 'Did you just tell me t…

> No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. That has no relevance. You build a standard for these proofs, and they are passed around as blobs. It doesn't matter what their internal structure is.

Your reply makes no sense. It's like you didn't read anything I said in pointing out that sending to a Bitcoin address is simple, easy to understand, easy to use, and secure, while its main disadvantage is using a tiny amount of space which would require enormous increase in the use of timestamping to make any meaningful difference to full nodes.

Re: Bitstamped

#58

Post by maaku »

gwern wrote: post #57
maaku wrote: post #55

Earlier quoted context omitted.

> No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. That has no relevance. You build a standard for these proofs, and they are passed around as blobs. It doesn't matter what their internal structure is.

Your reply makes no sense. It's like you didn't read anything I said in pointing out that sending to a Bitcoin address is simple, easy to understand, easy to use, and secure, while its main disadvantage is using a tiny amount of space which would require enormous increase in the use of timestamping to make any meaningful difference to full nodes.

Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. Yes the energetic and capital cost of transmitting, validating, storing, and keeping on hand a few dozen bytes is a minor thing like a speck of dust. But it is something that must -- must!! -- be done by every full node from now until the end of the universe. How many full nodes do you think there will be in the next 100 billion years? That's a lot of specks of dust.

Regarding simplicity, the complexity of the underlying protocol has no bearing on that. You can just as easily write an application where you drag and drop a file, and then it does the magic of sending p2p messages to negotiate a position in the timestamp tree, and making a micropayment to pay for it. That tool could be just as easy to use.

Re: Bitstamped

#59

Post by verroq »

servowire wrote: post #31
verroq wrote: post #5

1. Make a SHA1 hash of your document 2. Convert the hash to a BTC address 3. Send 0.0001 BTC to the address you made 4. There you saved yourself $9.99

Wouldn't it be possible to forge the SHA1 or a document?

Hash extension attack yes, but only if you already have a valid hash and document and wish to add more to the end of your document. This however will change the hash.

I also meant to type SHA2, but it would make no difference since you can still do length extension with it. In fact, you can do length extension with anything that uses Merkle-Damgard.

Re: Bitstamped

#60

Post by maaku »

kordless wrote: post #48
servowire wrote: post #29

Earlier quoted context omitted.

Here's an idea: Put the files in encrypted containers on a Torrent network. Or use maidsafe.net or storj.io

I wish people would stop suggesting 'using' solutions that aren't yet launched.

But then how else do you socially signal yourself as an expert in a field you may or may not know anything about?
Post reply on HN