Live data from Hacker News

AWS and Blockchain

tbray.org

241–250 of 724 posts

Re: AWS and Blockchain

#241

Earlier quoted context omitted.

Although I take slight issue with how you've worded it, I think I'm in agreement. I'll attempt to add clarification to the parts I find difficult to parse. Blockchains only ensure that coins are never spent twice. They make no attempts to ensure that coins are sent to the correct recipients. At the end of the block, they only care that debits are equal to credits. This can be confusing because the term "double spend"…

> Blockchains only ensure that coins are never spent twice. They make no attempts to ensure that coins are sent to the correct recipients. At the end of the block, they only care that debits are equal to credits. I know the origin is tightly linked to bitcoin, but I feel like even this muddies the definition. Blockchains are not implicitly related to "coins", more facts? contracts? Maybe that's a useless nit to pick,…

The novelty of Blockchain is that it's a way for everyone to agree about which blocks are in the chain, such that we're confident everyone won't change their minds later. The content of the blocks is irrelevant to the consensus, in which every participant will independently pick the longest valid chain it can see.

(In other words: yes, you've got it exactly right, but there are some details around incentives that tie creation of blocks to receiving some kind of benefit which mean that in practice someone will reduce things to money at some point)

Re: AWS and Blockchain

#242
post #167

Blockchain was invented to solve one particular problem: distributed consensus on a sequence of transactions, where the choice of which transaction to include from a set of conflicting transactions is irrelevant. The latter property here is key to understanding where blockchain is useful. It was created to solve the "double spend problem", ie. two transitions that spend the same coin but send it to different recipien…

I am sorry, but I think I am missing something here: isn't the "double spend problem" actually needing to be resolved by the choice of including one specific transaction (and no others), from a set of conflicting ones, truly relevant (vs. irrelevant)?

Re: AWS and Blockchain

#243
In Italy a famous news website is using blockchain since 2020 to, I quote literally: "help readers check source of news", "strengthen bonds of trust between its organization and its readers and customers", "trace the history and source of each news item."

News (EN): https://www.ansa.it/english/news/science_tecnology/2020/04/0...

Example of news in the blockchain: https://blockchain.check.ansa.it/landing/b150aff9f028f7339f0...

The first time I saw it I was quite surprised. I'd like to hear opinions about it here. Eg: it's blockchain stricly necessary here?

Re: AWS and Blockchain

#244
post #167

Blockchain was invented to solve one particular problem: distributed consensus on a sequence of transactions, where the choice of which transaction to include from a set of conflicting transactions is irrelevant. The latter property here is key to understanding where blockchain is useful. It was created to solve the "double spend problem", ie. two transitions that spend the same coin but send it to different recipien…

the original purpose of an invention does not limit the scope of its application

Re: AWS and Blockchain

#245
post #195

Earlier quoted context omitted.

>>It turns out that append-only databases are well-suited for HR records It may seem so, bu then You find out what are Your governments limit's for storing workers data, and Your company lawyers forces You to make it possible to delete everything that past that limit to limit legal risk and be gdpr compliant. And at this moment You find out that world is not constant and far from Your ideal model of spherical cow.

Can we design an append-only database that also allows for deletions if you replace those deletions with a direct reference to the hash that was once computed at that point in the chain? Yes, I know this isn’t strictly “append only”, but it still gives the ability to prevent silent updates and silent deletes. Any record that’s deleted must be replaced with something that indicates that it was deleted.

If the database is distributed you have no way of enforcing that the other peers don't keep shadow copies of the data that is supposed to be deleted.

If you know you can trust all your peers to act in good faith, then you might as well just use a regular database as none of your peers will edit old records due to being good actors.

Re: AWS and Blockchain

#246

In Italy a famous news website is using blockchain since 2020 to, I quote literally: "help readers check source of news", "strengthen bonds of trust between its organization and its readers and customers", "trace the history and source of each news item." News (EN): https://www.ansa.it/english/news/science_tecnology/2020/04/0... Example of news in the blockchain: https://blockchain.check.ansa.it/landing/b150aff9f028f…

If they add every revision on it, it could be interesting, but i doubt they do that.

One interesting thing I have been seeing recently is newspapers quickly changing news a few hours after they posted it, in reaction to public opinion of said news (or maybe some editorial "request").

In th BBC its quite egregious, they have been posting some news, and a few hours later changing the headline and the photo, to either something meaner and an uglier photo of the same person, or the opposite, a much more neutral/flaterring headline and a PR photo of the person.

If those changes were on the blockchain, UK citizens could demand their money back for what they pay for the BBC as it is a ridiculous practice that should not be paid by taxes. But again, I doubt the Italian newspapers saves their own slanted coverage for their own users to see.

Re: AWS and Blockchain

#247
post #86

Earlier quoted context omitted.

Do you have a link to more information about this? EDIT: So doing some googling finds that Telecom Regulatory Authority of India implemented “Distributed Ledger Technology” for fighting spam, but roll-out seems to have lasted not long (a week? A month?) because it didn’t work (didn’t scale?) and every so often tech vendors suggest they’re going to re-do it? Honestly there’s a lot of promo articles and conflicting inf…

crickets

https://www.fast2sms.com/help/dlt-sms-faq/

Distributed Ledger Technology (DLT) is a blockchain based online panel where the record of entities, sender ID and message templates will be maintained in a safe and secure manner. The whole panel entities will be interlinked with each other thereby regulating the fraudulent practices and creating a transparent SMS sending mechanism.

Re: AWS and Blockchain

#248
post #167

Blockchain was invented to solve one particular problem: distributed consensus on a sequence of transactions, where the choice of which transaction to include from a set of conflicting transactions is irrelevant. The latter property here is key to understanding where blockchain is useful. It was created to solve the "double spend problem", ie. two transitions that spend the same coin but send it to different recipien…

I am sorry, but I think I am missing something here: isn't the "double spend problem" actually needing to be resolved by the choice of including one specific transaction (and no others), from a set of conflicting ones, truly relevant (vs. irrelevant)?

The point is that it does not matter which one is included, only that it's only one of the choices that all agree on. Which one that is is not relevant, there is no part of the algorithm that determines one transaction to be "more valid" than another one. There is no ranking of transactions, one of them has to be picked but which one it is can be random, as long as there is agreement.

Also see the response from and sub-thread from uncletammy.

Re: AWS and Blockchain

#249

Earlier quoted context omitted.

> Ledgers are quite easy to build. Git is a ledger. It doesn't use a block chain but it does link commits via their hashes; which makes it an audit proof ledger. Unless you can break the hashes, you can't modify its history. Easy as an arm chair theory, impossible in practice without a complete rewrite of git from scratch. You are also disregarding the immutability of the data and the append-only property of stored d…

> Git is absolutely the wrong tool for the job as hashes in git are used as identifiers to identify a specific change, but not to cyrptographically checksum the document/the change to the data. Git commits can also merged, rewritten, squashed or deleted – something is absolutely unacceptable in the compliance space. Read up on git internals, it's a very elegant and simple design and you seem to assume a few things ab…

> Read up on git internals, it's a very elegant and simple design and you seem to assume a few things about it that are flat out wrong.

I am well acquainted with git internals and object types, which include blobs, trees, commits, and tags. But I do acknowledge that I was wrong about git not hashing the object's contents – it does.

> A git repository is in fact a Merkle tree. Every commit is chained to the previous commit via a hash that includes the commit content and the hash of the previous commit.

Commits in git are grouped into commit trees that form a single atomic commit, and git allow manipulations of the commit trees, which is fundamentally unacceptable for an immutable, verifiable ledger. That is why I am asserting that git is not an acceptable technology for a ledger.

> You can of course modify your local copy of a git repository and rewrite history (i.e. change all the hashes). But that makes it incompatible with upstream history.

I have personally squashed commits in my local project copy and force pushed such a squashed commit into a upstream repository thereby completely decimating the commit history in the upstream repository. Previous commit history was completely gone every single time. It is an occasionally useful feature (i.e. fixing mistakes of young developers), but the commit history rewrite is absolutely unacceptable in the compliance world. Just the fact that there is direct, unabridged write access to the history or to the storage where the history is recorded makes such a solution untenable as a ledger database.

I do concede that there are some conceptual similarities between git and ledger databases at the architectural level; I do, however, vociferously dispute the suitability of git as a foundation for building a ledger database without a substantial rewrite of the git foundation.

Re: AWS and Blockchain

#250
post #167

Blockchain was invented to solve one particular problem: distributed consensus on a sequence of transactions, where the choice of which transaction to include from a set of conflicting transactions is irrelevant. The latter property here is key to understanding where blockchain is useful. It was created to solve the "double spend problem", ie. two transitions that spend the same coin but send it to different recipien…

I am sorry, but I think I am missing something here: isn't the "double spend problem" actually needing to be resolved by the choice of including one specific transaction (and no others), from a set of conflicting ones, truly relevant (vs. irrelevant)?

Yes, a specific transaction needs to be chosen as the consensus transaction. But if there are multiple to choose from (e.g. in the case of an attempted double spend), the miner can choose either one.

The blockchain doesn’t guarantee, for example, that the transaction which appeared earlier will always be chosen (in practice, it’s likely the one with the highest transaction fee)

Post reply on HN