5 ms·

Oh in this instance it's not about having a public record. It's about every transaction having a hash of the previous. Then it gets hard to forge old data with

by xupybd 5y ago

Oh in this instance it's not about having a public record. It's about every transaction having a hash of the previous. Then it gets hard to forge old data without altering all records after the forgery. It's still possible but takes more work and can make the tampering easier to discover. And for data loggers not connected to the internet this helps. It would be just as good to put it in a central repo if there was an internet connection available. But if you're logging a refrigerator temp on a container traveling between countries there isn't going to be a cheap option for internet.

FabHK 5y ago
> It's about every transaction having a hash of the previous. We understand that... GP even said: >> I get the value of having a chain of "blocks" of data
gravitycorn 5y ago
Wait, you never did a git rebase? How does a consensus algorithm help when the nodes are not connected to the p2p network?
- blablabla123 5y ago
  It's transactional anyway so it's possible to make the file/dir structure as merge friendly as possible. In the simplest case just 1 file per operation with unique filenames. Speaking of trusted parties, (multiple) of those could be set up using a chain of trust in every network segment that do as much cross-signing/-verification as deemed necessary. Once it goes online again, the performed operations could go on-chain.
elsjaako 5y ago
That's why I mentioned git, not just putting it in a text file. Every git commit contains a hash of all the previous commits, and is itself referred to by a hash. So if you change an old commit, all commits descending from that get a new hash, and so a new identity. If you publish the latest hash in the newspaper, you've locked down all the previous commits also.
- xupybd 5y ago
  Sorry my mistake. I missed that. I was only thinking of the utility of publishing to an external source as a means of verifying history. You are correct.

by xupybd 5y ago

FabHK 5y ago

> It's about every transaction having a hash of the previous. We understand that... GP even said: >> I get the value of having a chain of "blocks" of data

gravitycorn 5y ago

Wait, you never did a git rebase? How does a consensus algorithm help when the nodes are not connected to the p2p network?

blablabla123 5y ago
It's transactional anyway so it's possible to make the file/dir structure as merge friendly as possible. In the simplest case just 1 file per operation with unique filenames. Speaking of trusted parties, (multiple) of those could be set up using a chain of trust in every network segment that do as much cross-signing/-verification as deemed necessary. Once it goes online again, the performed operations could go on-chain.

elsjaako 5y ago

That's why I mentioned git, not just putting it in a text file. Every git commit contains a hash of all the previous commits, and is itself referred to by a hash. So if you change an old commit, all commits descending from that get a new hash, and so a new identity. If you publish the latest hash in the newspaper, you've locked down all the previous commits also.

xupybd 5y ago
Sorry my mistake. I missed that. I was only thinking of the utility of publishing to an external source as a means of verifying history. You are correct.