With Cascasius' approach you'd still need to audit the code + trust that the people signing the file etc. are trustworthy and really who they claim to be. Yes, it might be an acceptable risk, but having the block chain yourself and doing the calculations and eventual pruning yourself is still what you need to be ultimately sure. For that you need to have all 200k blocks (pre-pruned or not).
D&T: Yes, you don't need 100% of all transactions, "only" 100% of all currently unspent transactions (something that's not always easy to find out) + block headers. Eventually it might also be nice to have then still stored/hashed in merkle trees, so you can hand at least pruned blocks to the P2P network. It can be estimated that in the future, clearly spent transactions will be pruned as fast as possible, things like this database though might start to bloat these unspent TX. On the other hand, store and delete operations would then be possible, leading to a write being a delete + a new store.
Topic: [IDEA] - Bitcoin-Powered Database (Read 2202 times)
They definitely DO need the whole block chain, otherwise they might include an invalid/double spent transaction and loose a block, because this block won't be accepted by anyone.
This "reliable" set of unspent transactions can only be produced by someone you trust (Bitcoin = 0 trust to others!) or yourself - and this person needs to have the whole block chain to be reliable in filtering out bad transactions.
This "reliable" set of unspent transactions can only be produced by someone you trust (Bitcoin = 0 trust to others!) or yourself - and this person needs to have the whole block chain to be reliable in filtering out bad transactions.
Not true. Due to the Merkle tree structure spent tx can be pruned away and without any trust a miner can reconstruct the entire blockchain back to the geneis block. The only missing parts are the spent tx and dead ends.
You do not need the full blockchain to be a miner. You DO need a full set of all unpsent outputs and all block headers. They aren't the same thing.
I geez I should have clicked the link in the OP before i wrote my reply down i was just in a hurry dont mind me, I'll just keep following closly anyways this is interesting subject
Publishing DB backups (minus sensitive information) is a step in the right direction but if we were to build a blockchain tx approach then it could provide a common protocol that could be used by different rating applications so that in the end users could pick and choose which specific ratings they care about (whilst also being certain that the data hasn't been altered after initial publication).
EDIT: Ooops I forgot which thread I was posting this in - the above is relevant to a rating system rather than a generalised DB.
EDIT: Ooops I forgot which thread I was posting this in - the above is relevant to a rating system rather than a generalised DB.
Aren't their SQL database tables that have a "write and read" option?
This is a good point your bringing up.... Having hashing power to verify SQL databases... Publicly?
This is a good point your bringing up.... Having hashing power to verify SQL databases... Publicly?
I'm not sure I follow. Can you rephrase your question/s?
Intermediate solution: publish nightlies and store just their hashes in the blockchain.
Seems like it solves the problems with both approaches to me.
Seems like it solves the problems with both approaches to me.
Almost. It still assumes all copies of the nightlies won't be destroyed by an attacker (meaning, that someone will actually download the nightlies for safe keeping). This is quite reasonable in practice.
Aren't their SQL database tables that have a "write and read" option?
This is a good point your bringing up.... Having hashing power to verify SQL databases... Publicly?
This is a good point your bringing up.... Having hashing power to verify SQL databases... Publicly?
How would this work fundamentally better, than, say, Bitcoinica publishing a nightly encrypted backup (a dump) that anybody can download (either via http or torrent), and also publishing a PGP signature to commit to its hash on a particular date?
This would be a whole lot simpler and less complicated and trivial for stakeholders to participate in the solution.
If there were a need to demonstrate that prior revisions aren't changing and that only thing happening is new records being added, the backups could simply be an archive file, where the backup of any night n contains identical copies of all the files that were present in the backup of night n-1, plus a new file representing that day's activity.
This would be a whole lot simpler and less complicated and trivial for stakeholders to participate in the solution.
If there were a need to demonstrate that prior revisions aren't changing and that only thing happening is new records being added, the backups could simply be an archive file, where the backup of any night n contains identical copies of all the files that were present in the backup of night n-1, plus a new file representing that day's activity.
Intermediate solution: publish nightlies and store just their hashes in the blockchain.
Seems like it solves the problems with both approaches to me.
How would your trust system be measured? Would you pin the trust system to USD?
I am only proposing trust tx's to be in a/the blockchain - the measurements of them would be entirely up to software apps that read the blockchain (and different apps could have very different ways of measuring it).
They definitely DO need the whole block chain, otherwise they might include an invalid/double spent transaction and loose a block, because this block won't be accepted by anyone.
This "reliable" set of unspent transactions can only be produced by someone you trust (Bitcoin = 0 trust to others!) or yourself - and this person needs to have the whole block chain to be reliable in filtering out bad transactions.
This "reliable" set of unspent transactions can only be produced by someone you trust (Bitcoin = 0 trust to others!) or yourself - and this person needs to have the whole block chain to be reliable in filtering out bad transactions.
They actually do not need the whole block chain. They merely need a reliable set of unspent tx outputs, and your challenge concerns the term "reliable", not the term "whole block chain". what you are saying is that the only way to know you have the accurate set of outputs is to download a large amount of extra data so your computer can say "yes this is it", and you are saying something different than what I am saying.
If I could download a digest of the first 200000 blocks - a digest that was produced by a published open source utility and there was a wide public consensus that the digest file with hash X is what the utility produces no matter who runs it therefore is a faithful record of all unspent txouts of blocks 1-200000, with lots of verifiable GPG signatures from respected people attesting to it, I would have no problem trusting that versus spending days downloading a huge file just to know I got the right one. And I definitely would be able to mine with it.
I am very much against the "web of trust" as it is only a continuation of elitism.
Am not quite sure why having public DB records of trust votes == elitism. The idea I had in mind was simply a system of publishing specific rating tx's but nothing to do with how they are interpreted (so different apps could take the raw data and draw very different conclusions depending on how they want to do that).
Am not quite sure why having public DB records of trust votes == elitism. The idea I had in mind was simply a system of publishing specific rating tx's but nothing to do with how they are interpreted (so different apps could take the raw data and draw very different conclusions depending on how they want to do that).
+1
I am very much against the "web of trust" as it is only a continuation of elitism.
Am not quite sure why having public DB records of trust votes == elitism. The idea I had in mind was simply a system of publishing specific rating tx's but nothing to do with how they are interpreted (so different apps could take the raw data and draw very different conclusions depending on how they want to do that).
I think that this idea is something that could be very useful for creating a web-of-trust system where all "rating" entries become a part of the "public" DB (I made a suggestion along these lines to https://bitcointalksearch.org/topic/website-for-all-lenders-and-borrowers-87012).
I am very much against the "web of trust" as it is only a continuation of elitism. There are other ways to apply trust to Bitcoin, but a universal database isn't one of them. A Ripple type system would provide the trust a lender might need. Ripple will work best in local economies, but still need a way to trade globally. Ripple/Bitcoin exchanges might do that.
I think that this idea is something that could be very useful for creating a web-of-trust system where all "rating" entries become a part of the "public" DB (I made a suggestion along these lines to https://bitcointalksearch.org/topic/website-for-all-lenders-and-borrowers-87012).
sounds like a job for namecoin
They definitely DO need the whole block chain, otherwise they might include an invalid/double spent transaction and loose a block, because this block won't be accepted by anyone.
This "reliable" set of unspent transactions can only be produced by someone you trust (Bitcoin = 0 trust to others!) or yourself - and this person needs to have the whole block chain to be reliable in filtering out bad transactions.
This "reliable" set of unspent transactions can only be produced by someone you trust (Bitcoin = 0 trust to others!) or yourself - and this person needs to have the whole block chain to be reliable in filtering out bad transactions.
Mining is not verifying the past chain. Miners need nothing more than the same data - a reliable set of unspent tx outputs - to do their work. They definitely do not need the full block chain.
Nor is anyone going to ever download the block chain - EVER - when it gets to, say 100GB+, other than self-appointed historians who want to make sure the original block chain never dies. Everyone else not using a hosted service will be downloading pruned or digested block chains. As the block chain size tends to infinity, the number of volunteer historians will tend to zero.
I know "normal users" won't download the blockchain - people will migrate to lightweight/thin clients anyway pretty soon. However, miners will still need to download the chain in order to verify it. As you know, miners are not volunteers, but have an incentive to mine and verify blocks. Miners could delete ancient history, but I'm not sure they will really choose to, as 100GB isn't really that much to keep around on modern hard drives. Moore's Law will help keep the cost of storing the ever-increasing blockchain small, compared to the mining rewards / tx fees.
If this "feature" of Bitcoin, the ability of its users to pay money in exchange for everybody to store their data forever, is a fundemental unsolvable property of the blockchain (in other words, if future-proof methods of encoding data in the chain exist), then you have no choice in the matter - to participate as a full client in the Bitcoin network, you'll have to store this data. I wonder if this is (yet another) Tragedy of the Commons situation ...
The minimal storage burden for being a full client in a fully optimized Bitcoin network is to store all unspent transactions (and only the unspent outputs thereof), which is a very small fraction of the total blockchain size, which grows only in proportion to coin ownership becoming "fragmented" (i.e. the total number of unique bitcoin addresses possessing coins). Any storage beyond that is consumed merely to cryptographically vouch for the integrity of that first data set.
The only reason to store the entire transaction history is to favor of some highly conservative security assumptions that are important for the proof of concept, but which are impractical to the point of ridicule. If 85% of the block chain file exists solely for the benefit of the client's ability to verify the block chain isn't tampered with, and I am able to download a block chain digest 15% of the size and there is some other way for me to establish the accuracy/veracity of the unspent transaction set it represents, and my user experience is all the same, I'm likely to opt for the latter.
Imagine if online banking had two options, http and https, and using https required you to wait 8 hours each time you wanted to use online banking. Nobody would use it. People would just bank offline, or take their chances on getting attacked.
Nor is anyone going to ever download the block chain - EVER - when it gets to, say 100GB+, other than self-appointed historians who want to make sure the original block chain never dies. Everyone else not using a hosted service will be downloading pruned or digested block chains. As the block chain size tends to infinity, the number of volunteer historians will tend to zero.
If only a dwindling number of historians will download the block chain when it gets so big, you're back to the same problem as square one: you're depending on volunteers to do your backups for you. You may as well let your volunteers back up your data directly via http, so they are only backing up data they have a stake in (something they might actually do out of prudence), rather than every gig of everybody's data who mistakenly thinks the block chain is their own personal closet, toilet, and dumping ground.
Jump to: