Since writing this post I have researched blockchain and DLT systems a bit more extensively as I started a project in fintech. Because of this I would like to make a few minor, but potentially important, corrections to the post above.
I now think it's incorrect to call the datastructure I described a blockchain if there is no proof algorithm involved. We wouldn't call a git repository a blockchain, especially since git precedes the term blockchain. Instead I'd say blockchains are hash-based version management with expense-based spam prevention. That expense will generally be in kWh (proof-of-work) or some virtual currency (proof-of-stake and proof-of-work).
Then there is the point about trust. I wrote that blockchains ensure trust. That's not quite correct. There is no trust between parties in blockchain applications. Instead there is "trust", if you can call it that, that a certain set of assumptions will hold, and proof that under those assumptions certain properties hold (e.g. finality of blocks that are X old etc.). This is a relevant distinction because you can do things with trust (in parties) that you cannot do with proofs / certainty. This distinction corresponds to the age-old philosophical question "what is true?": while we don't know for certain that the world around is real, we tend not to worry about it in our daily lives and just trust our senses.
Third is about the section on unique pushes. This is somewhat nonsensical. Physical items cannot be double-spent, so preventing double spending (which is what a blockchains does) seems moot. Digital signatures are likely sufficient, and most blockchain applications tend to use them. The bigger issue is tying a physical item to a digital ID. I expect supply-chain management applications of blockchain will show this deficit sooner or later.
Finally, and probably the most important point, while many blockchain applications are created out of hype or promotional purposes (look how smart we are that we can make something with blockchain!), sometimes they are used to create a pseudo-pyramid scheme. Tying virtual currency into a technology essentially gives a company a money printing license, so long as they can keep the hype up. This may be why many explanations of blockchain tech are so convoluted: there is a vested interest in keeping the technology mythical. I've personally observed this in certain white papers where the product turned out to be complete bollocks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Since writing this post I have researched blockchain and DLT systems a bit more extensively as I started a project in fintech. Because of this I would like to make a few minor, but potentially important, corrections to the post above.
I now think it's incorrect to call the datastructure I described a blockchain if there is no proof algorithm involved. We wouldn't call a git repository a blockchain, especially since git precedes the term blockchain. Instead I'd say blockchains are hash-based version management with expense-based spam prevention. That expense will generally be in kWh (proof-of-work) or some virtual currency (proof-of-stake and proof-of-work).
Then there is the point about trust. I wrote that blockchains ensure trust. That's not quite correct. There is no trust between parties in blockchain applications. Instead there is "trust", if you can call it that, that a certain set of assumptions will hold, and proof that under those assumptions certain properties hold (e.g. finality of blocks that are X old etc.). This is a relevant distinction because you can do things with trust (in parties) that you cannot do with proofs / certainty. This distinction corresponds to the age-old philosophical question "what is true?": while we don't know for certain that the world around is real, we tend not to worry about it in our daily lives and just trust our senses.
Third is about the section on unique pushes. This is somewhat nonsensical. Physical items cannot be double-spent, so preventing double spending (which is what a blockchains does) seems moot. Digital signatures are likely sufficient, and most blockchain applications tend to use them. The bigger issue is tying a physical item to a digital ID. I expect supply-chain management applications of blockchain will show this deficit sooner or later.
Finally, and probably the most important point, while many blockchain applications are created out of hype or promotional purposes (look how smart we are that we can make something with blockchain!), sometimes they are used to create a pseudo-pyramid scheme. Tying virtual currency into a technology essentially gives a company a money printing license, so long as they can keep the hype up. This may be why many explanations of blockchain tech are so convoluted: there is a vested interest in keeping the technology mythical. I've personally observed this in certain white papers where the product turned out to be complete bollocks.