[riskable]

I know I already replied but I forgot to mention another great usage of a blockchain: Logging. Not general-purpose logging, no. I'm talking about SOX-like "must be tamper-proof" transaction logging.

So say you've got central logging setup at your organization. You're smart and are using rsyslog with SSL/TLS and your own CA. For the most part you can reasonably claim that your log messages are secure from the server that emitted them to the destination in your central logging system but can you guarantee they're not modified after that? No. You can't.

From this perspective using a blockchain for logging security-critical events would be extremely useful. It would be impossible for an attacker to modify the logs after-the-fact so that you could no longer determine which account they used to login.

You wouldn't want to use it for general logging because of the overhead but for things like login events, reboots, etc it would be fantastic.

[lurker456]

A blockchain does not offer that guarantee either. The shared consensus it achieves comes at the cost of occasionally discarding stuff.

The few protections it does offer against tampering can be achieved in a much simpler way for your scenario (signing)

[aryehof]

Logging requires high speed transactions. Blockchain is very slow. That is by design, so that any changes incur too high a price for anyone considering tampering with it. Every block header write involves solving a hash puzzle (i.e. mining), that in the case of Bitcoin takes on average about 10 minutes to solve.

[solatic]

A blockchain isn't as much of a guarantee as you think it is. Maintaining an offline, physical-access-restricted backup of critical logs is arguably more secure than a blockchain which can be altered by an attacker controlling the majority of the blockchain's computational power.

[floatrock]

And even better than that: having your regulator run a few of the private miner nodes in your reportable business logic blockchain.

Who cares about proving how physically access-restricted your server room is, any funny business will be noticed right away.

[solatic]

Will it? Half the point about how blockchains work is that dropping blockchains which are shorter than mainline is standard operating procedure and completely ordinary.

People holding cryptocurrency would notice an illegitimate takeover of the blockchain right away because they'd be trying to spend cryptocoin which, all of a sudden, they no longer have. But regulators aren't trying to tally up business inventory on their own ledger so that they can send it off to other parts of the business and all of a sudden that kind of logistics fails for the regulator because of what you called "funny business". A regulator is a passive observer, and a passive observer can't detect funny business without actively auditing the blockchain against their perceived notion of whether the current state of the blockchain is normative... which is a very difficult problem indeed to do at scale, one which regulators today haven't yet been able to really automate, even with the relative certainty of a database (which a regulator could order regular dumps of, for analysis, if it wanted to).

[MatthewKernerMS]

Caesar consensus, which is referenced in the Coco technical whitepaper, seeks to address the problem you mention.

[pasxizeis]

I'm curious, has this ever been a problem in real life?

[corysama]

Googling for enterprise blockchain scenarios, I find https://www.hyperledger.org/projects/sawtooth/seafood-case-s... I guess in this case the goal is to ensure customers trust in the enterprise beyond just reputation. These records are currently being stored in traditional databases and the customers trust that the records aren't being tampered with out of the expectation of consequences if the enterprise was caught cheating. But, with a blockchain record, cheating becomes extraordinarily harder. The customers do not need to trust. They can verify.

[stefano]

Do the customers have to run their own mining network to ensure the producer can't pull a 51% attack?

[lurker456]

While a 51% attack is a real concern, an even more likely scenario is the network going down. During a network split the local node(s) will happily continue to ingest logs which once the network is healed will all be rejected.

[ryanschneider]

While I haven't had any real life interactions with these, I can think of a couple scenarios where it might make sense:

- Your company handles dangerous or highly regulated materials (prescription drugs, hazardous materials, etc.) and you are required to have controls in place to monitor your supply chain. - You deal with lots of vendors of questionable reputation, or have a history of graft, embezzlement, or other loss in your supply chain. For example, easily "misplaced" goods like cigarettes that need to be distributed to lots of retail locations.