3 ms·

> If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why u

> If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? Even if I ultimately have to kotow to the central authority, I still want to be able to audit what they're doing. Similarly, there is no such thing in the real world as a trusted central authority: the central authorities themselves are groups of people who don't fully trust each other, and thus want to be able to do effective internal auditing. You're line of argument could also be used to argue that we don't need to audit banks at all. > It's just a very slow, complicated, expensive append-only log file. The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Distributed databases already make use of complicated log files to achieve consensus between nodes and for auditing; adding hashes to the entries in those log files is relatively easy, and as cryptographic hashing is quite fast, doing that doesn't incur much of a performance hit. Most importantly, in a centralized environment, you can fairly easily use standard sharding techniques to make all of this scale well - which is the same way very large databases scale anyway.

hartator 8y ago
> You're line of argument could also be used to argue that we don't need to audit banks at all. That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain. > The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive.
- petertodd 8y ago
  > That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain. That's the point of cryptocurrencies; that doesn't mean centralized systems can't use the same technology to achieve their own goals. > Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive. Depends on how the database is used - lots of databases have usage patterns that are mostly append-only, in which case you're saving the full history anyway. As for the non-append-only parts, such as indexes and running balances, you can always use an architecture where their is either not committed at all in the block headers, or if it is, you just accept that auditors might need to do a bunch of re-computation to precisely check every interm state by replaying the transaction history logs. Now don't get me wrong: this will incure some performance hit. But with good engineering we're talking about things that are maybe half or a quarter as fast, not fundamental scaling problems. That's the kind of performance hit where just buying more hardware isn't a big deal.
Klathmon 8y ago
That's not my argument, my argument is that using a blockchain as your underlying data structure is entirely pointless if you have a way to selectively remove blocks. I'm saying nothing about how we should audit other things, just that a blockchain's "audit method" is the ability to follow the chain from the genesis block to current without any trusted 3rd party or outside information. You remove that ability, you've removed the point of using a blockchain in general. I don't care how other central authorities audit themselves, that's completely off topic, I care that a blockchain is by definition a chain of blocks. A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with. >The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file.
- petertodd 8y ago
  > I don't care how other central authorities audit themselves, that's completely off topic We're talking about GDPR here, which is most important in the context of centralized systems whose operators have to worry about compliance with European law; really, it's easier to argue that the fully trustless systems you're imagining - what Bitcoin attempts to be - are what are off topic here. > A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with. If you implement this in a real system, you'll need to rehash all the data any time any of the data is changed. The obvious optimization there is to only hash new data plus a commitment (hash digest) of the old data, at which point you have a blockchain. > I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file. How do you know the append-only log file was actually append-only? You'll want redundancy, which means multiple systems must have their own copies of that log file. Next you'll want auditors to be able to challenge those systems, which is often easiest if you have those systems sign cryptographic statements about what should be in that log file. Real-world systems have log files whose state changes over time, thus you'll want to the chain of blocks optimization so you don't have to re-download and re-hash everything every time the state changes to verify the latest set of signatures for the log file. And at that point, you have a blockchain whose consensus is defined by a centralized quorum of trusted but auditable entities.

hartator 8y ago

> You're line of argument could also be used to argue that we don't need to audit banks at all. That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain. > The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive.

petertodd 8y ago
> That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain. That's the point of cryptocurrencies; that doesn't mean centralized systems can't use the same technology to achieve their own goals. > Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive. Depends on how the database is used - lots of databases have usage patterns that are mostly append-only, in which case you're saving the full history anyway. As for the non-append-only parts, such as indexes and running balances, you can always use an architecture where their is either not committed at all in the block headers, or if it is, you just accept that auditors might need to do a bunch of re-computation to precisely check every interm state by replaying the transaction history logs. Now don't get me wrong: this will incure some performance hit. But with good engineering we're talking about things that are maybe half or a quarter as fast, not fundamental scaling problems. That's the kind of performance hit where just buying more hardware isn't a big deal.

Klathmon 8y ago

That's not my argument, my argument is that using a blockchain as your underlying data structure is entirely pointless if you have a way to selectively remove blocks. I'm saying nothing about how we should audit other things, just that a blockchain's "audit method" is the ability to follow the chain from the genesis block to current without any trusted 3rd party or outside information. You remove that ability, you've removed the point of using a blockchain in general. I don't care how other central authorities audit themselves, that's completely off topic, I care that a blockchain is by definition a chain of blocks. A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with. >The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file.

petertodd 8y ago
> I don't care how other central authorities audit themselves, that's completely off topic We're talking about GDPR here, which is most important in the context of centralized systems whose operators have to worry about compliance with European law; really, it's easier to argue that the fully trustless systems you're imagining - what Bitcoin attempts to be - are what are off topic here. > A simple list of "data", it's hash, and a counter would be better for what you want in just about every way. You'd still be able to see that data was modified or removed, and it would be faster, simpler, and easier to work with. If you implement this in a real system, you'll need to rehash all the data any time any of the data is changed. The obvious optimization there is to only hash new data plus a commitment (hash digest) of the old data, at which point you have a blockchain. > I never said anything about Bitcoin. I'm saying that using a blockchain while throwing out the "chain" part is more complicated, slower, and more expensive than using a simple append-only log file. How do you know the append-only log file was actually append-only? You'll want redundancy, which means multiple systems must have their own copies of that log file. Next you'll want auditors to be able to challenge those systems, which is often easiest if you have those systems sign cryptographic statements about what should be in that log file. Real-world systems have log files whose state changes over time, thus you'll want to the chain of blocks optimization so you don't have to re-download and re-hash everything every time the state changes to verify the latest set of signatures for the log file. And at that point, you have a blockchain whose consensus is defined by a centralized quorum of trusted but auditable entities.