What's the point of using a blockchain in this way?<p>Bitcoin's blockchain is necessary because newer blocks need to inherit the proof-of-work done on previous blocks, since the correct chain will be the one with the most cumulative work in it (presuming it's also valid). So it needs to be a sequential list of blocks, where each new block references the previous one.<p>But I can't see why this is useful when a) proof-of-work isn't used and b) blocks are separate databases. Why not just have one, big database and accept commits into this if they're signed with the expected private keys?
From what I read, any holder of a private key that is accepted as authoritative can add data to the chain at will and without restriction. The consensus algorithm would then allow that user to rewrite the entirety of the blockchain at will from the point their key was trusted forward by simply creating a longer chain at no cost. What am I missing?
Government employ working on publishing government documents here. This looks very interesting. What if a private key is leaked (by accident or on purpose)? It would be good to have multiple branches of government sign the published documents.<p>Is there a small tutorial on how to quickly set this up for demo and evaluation?
There is something I don't get about the databases distributed : they are read/write, and their data is not part of what is distributed in p2p, is that right? It seems to be what means "Block payloads are SQLite database files. Except for special metadata tables, their content is not enforced".<p>If that's so, what is the purpose of distributing blank sqlite databases (with exception of blockchain keys metadata)? Also, how is it p2p distributed if several users may have the sqlite databases in different state (and thus, different sqlite files)?
This looks interesting, but I feel like it's conflating two equally interesting ideas, "what if only certain nodes could make new blocks" and "what if the blocks had some kind of structured data".<p>I think moving those into two separate but compatible projects might help both of them take off.
Thinking twice about it, there is something exciting here about the concept.<p>Of all databases, sqlite has this special interest : it's the perfect tool to be embedded as local database in clients.<p>Now, if we consider that blockchain is a new p2p effort to build decentralized softwares, putting sqlite on a blockchain makes a lot of sense : this is a mean to distribute data for decentralized apps.<p>It also makes sense in an era where data mining becomes a thing on its own, and not just as part of a software stack.<p>Now, this is clearly not a drop in for our usual database on our server (where latency and concurrent writing is the topmost concern, two points which are blockchains weak points - and sqlite weakpoints), but there is certainly something to explore there.
Why store a database file in each block when you could also store transactions? This is what Catena does: <a href="https://news.ycombinator.com/item?id=14548174" rel="nofollow">https://news.ycombinator.com/item?id=14548174</a>. Also allows for some interesting things you can do with privileges, for instance.
I don't understand. The added value of a blockchain compared to a simple distributed store is that peers who don't want to trust each other need to get to an agreement. All the examples look like they can be solved with a standard distributed store like a set of couchDB instances where no deletion can happen.
What's the difference/benefits from, for example, having a feed to stream pgp signed data where signature is for the current and previous message for example?