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

Blockchains from a Distributed Computing Perspective [pdf]

cs.brown.edu

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Blockchains from a Distributed Computing Perspective [pdf]

#61

Post by hyperion2010 »

drdrey wrote: post #47
hyperion2010 wrote: post #38

Earlier quoted context omitted.

Ya sorry, a bit of an exaggeration there. I was recalling the size of the hard disks that some folks routinely kept around just for storing crypto blockchains. That said, the actual numbers are already out of the rang for storage on the vast majority of commercially available mobile devices which basically relegates cryptos to enthusiasts. If we could fit a year worth of transactions in to on the order of 10 gigs, or…

The blockchain grows at a constant linear rate, 1MB every 10 min or 144MB per day. Isn't that what you mean by "constant size estimate per unit time"?

The number you describe is a constant "change in size." What I describe is a constant maximum worst case "size." Yours would be velocity, mine would be position, function, derivative, etc.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#62

Post by [deleted] »

matuszeg wrote: post #11
jasonzemos wrote: post #10

You may be interested in another paper[1] by Sompolinsky and Zohar describing block-trees rather than block-chains as a better structural approach. 1: https://eprint.iacr.org/2013/881.pdf

Thank you so much for this. I work in this field and have been telling my coworkers that a tree or graph would make more sense. This is what i needed. Thank you Do you know if anyone is working to implement something like this?

[deleted]

Re: Blockchains from a Distributed Computing Perspective [pdf]

#63

Post by fjni »

matuszeg wrote: post #11
jasonzemos wrote: post #10

You may be interested in another paper[1] by Sompolinsky and Zohar describing block-trees rather than block-chains as a better structural approach. 1: https://eprint.iacr.org/2013/881.pdf

Thank you so much for this. I work in this field and have been telling my coworkers that a tree or graph would make more sense. This is what i needed. Thank you Do you know if anyone is working to implement something like this?

Spectre is super interesting, same author, they started https://www.daglabs.com to implement this

https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb70...

https://eprint.iacr.org/2016/1159.pdf

Re: Blockchains from a Distributed Computing Perspective [pdf]

#64

Post by mbrock »

BraveNewCurency wrote: post #57
mbrock wrote: post #26

Earlier quoted context omitted.

It seems that in any real world blockchain, the space growth from actual transactions will be much larger than the space wasted on inactive wallets. And the notion of a secure financial system where if you don't move your money for a year your whole account is confiscated seems rather unappealing! One thing I really want to be able to do with a blockchain system is to put my wallet in cold storage—like, in a safe. I…

> my calendar every year to retrieve all my keys from cold storage and do a meaningless transaction No, you don't need to retrieve your keys each year. Before storage, create N transactions moving all your coins to the next derived address. Sign all your transactions at once. Then put it in the safe. Store the transactions unencrypted on your computer. Send one each year. An attacker can't do anything with them excep…

That's a good point, I didn't think about that. It does add some extra complexity though—like, if I do want to make a real transaction, I have to re-make the subsequent "keep-alive" transactions.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#65

Post by mbrock »

gwbas1c wrote: post #60
mbrock wrote: post #26

Earlier quoted context omitted.

It seems that in any real world blockchain, the space growth from actual transactions will be much larger than the space wasted on inactive wallets. And the notion of a secure financial system where if you don't move your money for a year your whole account is confiscated seems rather unappealing! One thing I really want to be able to do with a blockchain system is to put my wallet in cold storage—like, in a safe. I…

> And the notion of a secure financial system where if you don't move your money for a year your whole account is confiscated seems rather unappealing! This is why conventional money has a low amount of inflation. It incentives you to invest your money instead of putting it under a mattress.

That is indeed a more conventionally appealing way to encourage circulation—a gradual inflation in prices rather than sudden account confiscation!

Re: Blockchains from a Distributed Computing Perspective [pdf]

#66

Post by DennisP »

mannykannot wrote: post #56
DennisP wrote: post #54

Earlier quoted context omitted.

There's a fundamental difference: a rollback reverses everybody's transactions, the DAO fork left unrelated transactions alone. Bitcoin had an actual five-hour rollback in its early days, when someone figured out an exploit and awarded themselves over a billion coins.

A rollback followed by a replay of desired transactions is still a rollback. This is how you can tell if an attempt to refute-by-redefinition is denial: first determine why it would be unfortunate if the predicate being refuted were true, and then ask if the redefinition actually fixes the problem.

Ethereum didn't have to replay transactions, because there was no rollback at all; it was an isolated change to the data in one contract. Ethereum doesn't work the way Bitcoin does.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#67

Post by mannykannot »

DennisP wrote: post #66
mannykannot wrote: post #56

Earlier quoted context omitted.

A rollback followed by a replay of desired transactions is still a rollback. This is how you can tell if an attempt to refute-by-redefinition is denial: first determine why it would be unfortunate if the predicate being refuted were true, and then ask if the redefinition actually fixes the problem.

Ethereum didn't have to replay transactions, because there was no rollback at all; it was an isolated change to the data in one contract. Ethereum doesn't work the way Bitcoin does.

Here we have another distinction without a relevant difference. A rollback is defined by its consequences, not the details of its process.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#68

Post by DennisP »

mannykannot wrote: post #67
DennisP wrote: post #66

Earlier quoted context omitted.

Ethereum didn't have to replay transactions, because there was no rollback at all; it was an isolated change to the data in one contract. Ethereum doesn't work the way Bitcoin does.

Here we have another distinction without a relevant difference. A rollback is defined by its consequences, not the details of its process.

If you want to redefine "rollback" as "any fork that changes a blockchain's data" then ok, but that seems like a misleading definition to me. Normally a rollback means "all transactions are rolled back," which has entirely different consequences. In Ethereum's case, the data afterwards is different even from a rollback/reapply, since the theft is still in the transaction history.

In any case it seems fairly useless to debate what the meaning of "rollback" should be.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#69

Post by codehalo »

DennisP wrote: post #54
mannykannot wrote: post #43

Earlier quoted context omitted.

No amount of wordplay and denial will alter the fact that the DAO fork was a de-facto rollback.

There's a fundamental difference: a rollback reverses everybody's transactions, the DAO fork left unrelated transactions alone. Bitcoin had an actual five-hour rollback in its early days, when someone figured out an exploit and awarded themselves over a billion coins.

That’s incorrect. There was never a rollback in Bitcoin. You may be referring to the leveldb bug that caused a fork, or Gavin and Satoshi’s discovery of the billion coins bug, which was fixed by a software update, but none of these involved a rollback.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#70

Post by mannykannot »

DennisP wrote: post #68
mannykannot wrote: post #67

Earlier quoted context omitted.

Here we have another distinction without a relevant difference. A rollback is defined by its consequences, not the details of its process.

If you want to redefine "rollback" as "any fork that changes a blockchain's data" then ok, but that seems like a misleading definition to me. Normally a rollback means "all transactions are rolled back," which has entirely different consequences. In Ethereum's case, the data afterwards is different even from a rollback/reapply, since the theft is still in the transaction history. In any case it seems fairly useless t…

The meaning of rollback transcends and precedes blockchains, and it use here is in that sense.
Post reply on HN