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

61–69 of 69 posts

Re: Bitstamped

#61

Post by zaroth »

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…

The OP_RETURN is provably unspendable, so it's technically superior to dumping data in unspent outputs. UTXO actually does have to be kept around forever, unlike OP_RETURN which can be pruned.

Re: Bitstamped

#62

Post by kordless »

maaku wrote: post #60
kordless wrote: post #48

Earlier quoted context omitted.

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?

"I've heard good things about the team at X.", if you've actually heard good things about them. "Those guys at X claim they can do Y.", if you have the folks at X on record actually claiming Y. Otherwise, you're just repeating something you heard, or wish you had heard.

Re: Bitstamped

#63

Post by maaku »

zaroth wrote: post #61
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…

The OP_RETURN is provably unspendable, so it's technically superior to dumping data in unspent outputs. UTXO actually does have to be kept around forever, unlike OP_RETURN which can be pruned.

The issue isn't OP_RETURN, it's one vs many OP_RETURN outputs per block, and stuffing data in the block chain vs compressing it via hash functions to 32-bytes per block.

Re: Bitstamped

#64

Post by gwern »

maaku wrote: post #58
gwern wrote: post #57

Earlier quoted context omitted.

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 th…

> Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures.

One of the other things I learned there was not letting the perfect be the enemy of the better.

> But it is something that must -- must!! -- be done by every full node from now until the end of the universe.

Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe.

> How many full nodes do you think there will be in the next 100 billion years?

A relatively small multiple of the number there have been. You seriously think humanity is going to exist for 100 billion years?

> That tool could be just as easy to use.

Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write.

Re: Bitstamped

#65

Post by danoprey »

inkfactory wrote: post #8
chuckup wrote: post #4

Earlier quoted context omitted.

What's with the terrible names in Bitcoin land? When deciding what to name your Bitcoin site, anything with the word "bit" or "coin" in it should be avoided. Please! Otherwise, you just join the list of other unmemorable bit/coin sites. And, this goes without saying, pick something that, when you google it, google does not say "Showing results for Bitstamp".

Point taken. "Showing results for Bitstamp" is irritating, but we only launched yesterday, hopefully Google will figure out that Bitstamped is a thing!

I have to admit, when I first read it I thought it was a new euphemism for being screwed over by Bitstamp, a la "Goxed".

Re: Bitstamped

#66

Post by zaroth »

maaku wrote: post #63
zaroth wrote: post #61

Earlier quoted context omitted.

The OP_RETURN is provably unspendable, so it's technically superior to dumping data in unspent outputs. UTXO actually does have to be kept around forever, unlike OP_RETURN which can be pruned.

The issue isn't OP_RETURN, it's one vs many OP_RETURN outputs per block, and stuffing data in the block chain vs compressing it via hash functions to 32-bytes per block.

If everyone is supposed to share one OP_RETURN, either you're building the tree by consensus or centralized control?

It would be an interesting feature to collect the OP_RETURN's into a merkle tree as part of a consensus protocol. But one question immediately comes to mind...

Publishing the root node is useless, unless you know where your node is located in the tree, and all the sibling nodes all the way up to the root. You know, so that you can actually prove your node was part of the tree. Just having the root is not enough.

Where is the full tree being built, stored, how is it shared, how do I get a copy of it, so that I can find my node in it? If the tree is built from collective inputs, what are the anti-DDoS mechanisms? Etc...

Peers would need to share this data structure for some amount of time after the block is published (not indefinitely). Anyone who thinks their hash is part of certain block's tree would need to retrieve the full tree for that block, and if they find their node in the tree, keep their own record of the log(n) hashes required to get from their node to root. It's a big trade-off to impose this external data storage requirement!

All these questions / complexity, and what is the actual benefit? Again, these are prune-able OP_RETURN outputs so they don't pollute UTXO in the first place. The relay fee is more than enough to cover the cost of < 100 bytes that never hit UTXO.

Re: Bitstamped

#67

Post by maaku »

zaroth wrote: post #66
maaku wrote: post #63

Earlier quoted context omitted.

The issue isn't OP_RETURN, it's one vs many OP_RETURN outputs per block, and stuffing data in the block chain vs compressing it via hash functions to 32-bytes per block.

If everyone is supposed to share one OP_RETURN, either you're building the tree by consensus or centralized control? It would be an interesting feature to collect the OP_RETURN's into a merkle tree as part of a consensus protocol. But one question immediately comes to mind... Publishing the root node is useless, unless you know where your node is located in the tree, and all the sibling nodes all the way up to the ro…

The relay fee doesn't go to the people who are actually burdened with maintaining the historical block stream. It is a fully externalized cost.

Re: Bitstamped

#68

Post by maaku »

gwern wrote: post #64
maaku wrote: post #58

Earlier quoted context omitted.

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 th…

> Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. One of the other things I learned there was not letting the perfect be the enemy of the better. > But it is something that must -- must!! -- be done by every full node from now until the end of the universe. Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. > How many fu…

> One of the other things I learned there was not letting the perfect be the enemy of the better.

Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing.

> Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe.

In a certain form I very much believe it will be, but this is probably not the right venue for that debate.

> You seriously think humanity is going to exist for 100 billion years?

I plan on being around (at least) that long, though that was not the question asked.

> Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write.

Actually I am and have:

https://www.mail-archive.com/bitcoin-development@lists.sourc...

Re: Bitstamped

#69

Post by gwern »

maaku wrote: post #68
gwern wrote: post #64

Earlier quoted context omitted.

> Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. One of the other things I learned there was not letting the perfect be the enemy of the better. > But it is something that must -- must!! -- be done by every full node from now until the end of the universe. Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. > How many fu…

> One of the other things I learned there was not letting the perfect be the enemy of the better. Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing. > Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. In a certain form I very much believe it will be, but this is probably not the right venue for that debate. > You seriously think h…

> Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing.

No, it's not significantly better, and I'm not sure if it's better at all. Timestamping in the Bitcoin block chain is easy to use, cheap, convenient, highly secure, and relatively easy to explain to others. Your solution does not exist yet, and from the sound of it, even when it exists will have only one of those properties (highly secure), optimistically.

> though that was not the question asked.

Indeed. I don't expect humanity to be around in 100b years. I don't expect money to be around in 100b years. And I certainly don't expect SHA-256 or the elliptic curves used in Bitcoin to all remain intact over 100 billion years. (What's the longest a cryptographic hash in wide use has ever survived so far? 30 years? What about public key systems? 40 years maybe?)

> Actually I am and have:

I see. I upgrade my assessment of you from 'preachy asshole' to simply 'clueless person who doesn't understand people and their needs and builds castles in the air'.

Post reply on HN