The ledger would still be a chain of blocks.
For real tree like blockchains there are a few examples such as IOTA, raiblocks and byteball.
Do you know if anyone is working to implement something like this?
https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb70...
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 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?
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 section on private blockchains
Can you write one program using a private blockchain(for eg use ibm's hyperledger) that can't be written using git? Private blockchains, premined coins, colored tokens, assets etc all of them.
3. Regarding smart contracts, can you show me one use of turing completeness in a blockchain? If yes, ethereum is not turing complete practically cause gas.
4. How does one determine the gas price of an opcode in a network? How does ethereum do it? (i think only people understanding need of proof-of-work will understand this)
5. W.r.t the layers of OSI model, the need for smart contract is trivial. Show me one smart contract you can do 'in' a blockchain and I will tell you how to do it 'on' bitcoin.
[0]https://ethereum.stackexchange.com/questions/9535/how-does-a...
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.
PoW is not required to have a blockchain. What you need is any consensus algorithm. For example you could use Proof of Stake.
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 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.
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 don't want some arbitrary rule that I need to mark 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".)
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.
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.
Why does it matter? If the address never moves the tokens... it's not really a lot of computation required.
No, Bob's misconduct would potentially be provable in court based on the trustless data ledgers in the blockchain.
Really, this example just shows one way how developers could use blockchain technology to develop applications that utilize trustless data.
Imagine this same technology applied to the transfer of human organs, rather than easily replaceable ice cream.
Challenge yourself to think of other scenarios in business where trustless data might make a difference.
Maybe you'll have a valuable idea in this wide open space.
Blockchain can’t stop a human from stealing an organ and replacing it with a different organ. Even tracking shipping containers, which was high profile a few years ago, only requires a human to make a mistake in loading a boat to throw off the database.
In tangible-world-to-information-storage scenarios, the hard part is not the information, but the guarantee that information matches the real world. In my view, the claim that blockchain solves for a trustless tangible world is naive.
That said, engineers live to solve problems in better, smarter ways.
I personally believe it is naive to bet against innovation in this sphere, but we both shall see if we are so fortunate.
Bitcoin had an actual five-hour rollback in its early days, when someone figured out an exploit and awarded themselves over a billion coins.
This is a case where imagination is needed.
Why do everybody needs to keep everything? The chain will be much smaller with just the id and the hash of the block. The payloads could be kept only by the interested parties and could be validated when needed with the chain.
Because every node in the network must be able to verify all transactions all the way from the genesis block. In order to ensure that this is possible, everyone who keeps the history must keep the full history.
[1] http://mimblewimble.cash/20160719-OriginalWhitePaper.txt
In any case it seems fairly useless to debate what the meaning of "rollback" should be.
If the existence of a record of the rolled-back transaction made a difference to whether an action is a rollback or not, then, by your argument, it would seem that the existence, or not, of a backup (or any other record) preserving the prior state of the system, would make the difference as to whether an SQL rollback was or was not actually a rollback. This, of course, is absurd, but its what you get from mistaking an implementation for a definition.
> In any case it seems fairly useless to debate what the meaning of "rollback" should be.
That was the point of my first post in this thread (with special reference to self-serving definitions.)