Blockchains from a Distributed Computing Perspective [pdf]
1–10 of 73 posts
Re: Blockchains from a Distributed Computing Perspective [pdf]
#2Re: Blockchains from a Distributed Computing Perspective [pdf]
#3Here's an example:
> Alice decides it is time to blockchain her supply chain. She rents some cloud storage to hold the ledger, and installs internet-enabled temperature sensors in each frozen yogurt container. She is concerned that sensors are not always reliable (and that Bob may have tampered with some), so she wires the sensors to conduct a Byzantine fault-tolerant consensus protocol, which uses several rounds of voting to ensure that temperature readings cannot be distorted by a small number of of faulty or corrupted sensors.
Now, since all frozen yogurt containers pass from Carol to Bob to Alice, doesn't Bob at some point in time have access to all the frozen yogurt containers and their temperature sensors? Then Bob can easily corrupt all of them, rendering this scheme useless. He can, for example, replace all of the sensors by malicious sensors that report wrong temperatures when they are in Bob's truck.
Is there something I'm missing?
Re: Blockchains from a Distributed Computing Perspective [pdf]
#4I appreciate the effort in writing this readable paper, but I do find the analogies in the first few sections to be quite strained. Here's an example: > Alice decides it is time to blockchain her supply chain. She rents some cloud storage to hold the ledger, and installs internet-enabled temperature sensors in each frozen yogurt container. She is concerned that sensors are not always reliable (and that Bob may have t…
Re: Blockchains from a Distributed Computing Perspective [pdf]
#51) 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 the heat death of the universe. 2) To solve space complexity you need a time tax. I propose 1 year, because it is convenient. 3) Any tokens (or fractions of a token) [0] that have not moved for more than a year (rolling) are returned to the common pot. (sort of a non-usage tax)
This means that you can limit the space complexity of the whole chain as a function of the number of transactions per 'tax interval.' This, or maybe a similar approach could make the space complexity problem tractable for normal users. (The blithe acceptance of a 1-2Tb (or is it 3 now?) space requirement for the full blockchain by members of the community is so wildly out of touch with reality it is laughable)
0. There are a number of other 'units' that could be considered for tax-interval retirement, such as the wallet. The nice thing about taxing fractions of tokens is that the network can set the rate of the tax for investing over the long term based on the cost of a single transaction fee. The day before a fraction of a token would be dumped back into the pool the owner would just have to send the token to another wallet they control and pay the relevant transaction fee.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#6This 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…
Why does it matter? If the address never moves the tokens... it's not really a lot of computation required.
Re: Blockchains from a Distributed Computing Perspective [pdf]
#7This 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…
Re: Blockchains from a Distributed Computing Perspective [pdf]
#8This 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…
Re: Blockchains from a Distributed Computing Perspective [pdf]
#9I appreciate the effort in writing this readable paper, but I do find the analogies in the first few sections to be quite strained. Here's an example: > Alice decides it is time to blockchain her supply chain. She rents some cloud storage to hold the ledger, and installs internet-enabled temperature sensors in each frozen yogurt container. She is concerned that sensors are not always reliable (and that Bob may have t…
All of the censors vote on if they have been tampered with. They will leave a record of their votes on the blockchain as Bob tampers with them in real time.