Live data from Hacker News

Blockchains from a Distributed Computing Perspective [pdf]

cs.brown.edu

51–60 of 73 posts

Re: Blockchains from a Distributed Computing Perspective [pdf]

#51
post #49

Earlier quoted context omitted.

If you have trust in a court, you don't need a trustless system, by definition.

Slippery slope: I can trust the court if I don't have to trust the data. I can't trust the court if I have to subjectively prove my arguments.

But you can't trust the data if the systems providing - creating - that data are tampered with, by definition!

Re: Blockchains from a Distributed Computing Perspective [pdf]

#52
post #26

This seems an appropriate place to dump a thought I had while explaining the failures of all existing blockchains to a layman. 1) The problems with merkle trees & co. aren't the computational complexity, they are the space complexity. 1a) I can screw a current blockchain for all eternity by buying some token and then burning by keys. No one will ever know and they will have to keep track of those dead tokens until th…

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…

> 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

AFAIK, you can generate a paper wallet with any blockchain system. You're keys are rendered as a QR code and/or series of words (there is a name for this protocol that hopefully someone else can remember!), and you can then print and store it.

Hardware wallets are also a thing for some systems, such as Bitcoin.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#53

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?

Ethereum has something along these lines in production; it's how they get higher throughput and 15-second block times.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#54
post #29

Earlier quoted context omitted.

From [0] - "The transactions were not rolled back. The ETH amounts were just transferred automatically at 1,920,000 ." So a transaction did take place "between various parties", nothing previous to block 1920000 was changed, and the transfer is there for all to see.

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.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#55
post #52
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…

> 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 AFAIK, you can generate a paper wallet with any blockchain system. You're keys are rendered as a QR code and/or series of words (there is a name for this protocol that hopefully someone else can remember!), and you can then print and store it. Hardware wallets are also a thing for some systems, such…

Yeah, exactly. BIP39 is a common protocol for mnemonic keys also supporting subkeys. Hardware wallets like the Ledger Nano S have support for Bitcoin, Litecoin, and Ethereum, and they let you sign transactions without ever exposing your private keys to a general purpose computer. And yeah, you can always just keep your private key in any way you want—it's just an n-bit number.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#56
post #54

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.

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.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#57
post #26

This seems an appropriate place to dump a thought I had while explaining the failures of all existing blockchains to a layman. 1) The problems with merkle trees & co. aren't the computational complexity, they are the space complexity. 1a) I can screw a current blockchain for all eternity by buying some token and then burning by keys. No one will ever know and they will have to keep track of those dead tokens until th…

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 except send them early (and force you to open your safe "sometime within the next year".)

Re: Blockchains from a Distributed Computing Perspective [pdf]

#58
post #49

Earlier quoted context omitted.

Slippery slope: I can trust the court if I don't have to trust the data. I can't trust the court if I have to subjectively prove my arguments.

But you can't trust the data if the systems providing - creating - that data are tampered with, by definition!

You are very interested in defining things.

This is a case where imagination is needed.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#59
post #17

> a ledger is just an indelible, append-only log of transactions that take place between various parties. Readers should decide either the above statement is true and ethereum is not a blockchain by that definition[0] or blockchain is just an abstract buzzword. Technology wise, git is as powerful as a blockchain at being an append-only log without the most important ingredient - proof-of work. 2. There is a whole sec…

> Technology wise, git is as powerful as a blockchain at being an append-only log without the most important ingredient - proof-of work. PoW is not required to have a blockchain. What you need is any consensus algorithm. For example you could use Proof of Stake.

The impression I got last time I studies about proof of stake is that it is still an open problem. You need to find ways to stop people from gaming the system by computing multiple parallel histories (which would devolve the system into proof-of-work) and the only ways to do this that I am aware of are at least partially reliant on agreeing on a central authority.

Re: Blockchains from a Distributed Computing Perspective [pdf]

#60
post #26

This seems an appropriate place to dump a thought I had while explaining the failures of all existing blockchains to a layman. 1) The problems with merkle trees & co. aren't the computational complexity, they are the space complexity. 1a) I can screw a current blockchain for all eternity by buying some token and then burning by keys. No one will ever know and they will have to keep track of those dead tokens until th…

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.

Post reply on HN