this is still my favorite https://anders.com/blockchain/
yup, I was able to implement a basic blockchain at once the moment I watched that demo.
Blockchains explained visually (part 1 of 2)
41–46 of 46 posts
Re: Blockchains explained visually (part 1 of 2)
#42I just would like to say thanks to the author for spending his time on this article. I found it very well written and I look forward to seeing part 2. I recommend this article to everyone who asks me about the blockchain technology.
Re: Blockchains explained visually (part 1 of 2)
#43Something I noticed, but didn't see in the article (unless I just missed it). In reference to the security part at the end, if the hash only included the previous block's data, and not its previous hash. If you could edit two consecutive blocks you could change, say, block 2's data and block 3's previous hash. Now everything looks fine because this doesn't change block 3's data so block 4's previous hash looks fine and everything looks legit. Seems like a greater concern than breaking the chain because it wouldn't be detected unless you compared two versions of the chain.
Re: Blockchains explained visually (part 1 of 2)
#44Nice and eloquent! Will read also other articles.
Re: Blockchains explained visually (part 1 of 2)
#45One thing that never clicked with me before is that the blockchain is really just a historical ledger, its not actually referenced in real time. When you send a transaction out on the network, nobody is actually validating it against the blockchain. Instead every node is expected to process the blockchain to produce a realtime database called the UXTO which provides a fast lookup to tell you if coins can be spent or…
And you really only need to track UXTO for your own address if you're not a full node, and that will be very small.
Re: Blockchains explained visually (part 1 of 2)
#46> See how the hash-chaining mechanism of a blockchain means that even a single corrupt or tampered-with block will invalidate the entire chain after it. Is that strictly required to understand that the entire chain is invalidated? Since blocks are in order, if block X's previous hash doesn't check out, can't we just assume that every block thereafter is also invalid? Effectively a fork has happened at X-1 block. I'm…
Someone can mine and broadcast blocks that reference an old block, nodes will store the block, in case more are published and it becomes the longest chain, but will otherwise ignore it.