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.
Blockchains from a Distributed Computing Perspective [pdf]
51–60 of 73 posts
Re: Blockchains from a Distributed Computing Perspective [pdf]
#52This 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…
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]
#53You 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?
Re: Blockchains from a Distributed Computing Perspective [pdf]
#54Earlier 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.
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]
#55Earlier 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…
Re: Blockchains from a Distributed Computing Perspective [pdf]
#56Earlier 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.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#57This 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…
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]
#58Earlier 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!
This is a case where imagination is needed.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#59> 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.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#60This 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…
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.