Question for those in the know (or the author, if you're lurking about):
> At this point, the idea of a chain should be apparent—each new block contains within itself, the hash of the previous Block. This is crucial because it’s what gives blockchains immutability: If an attacker corrupted an earlier Block in the chain then all subsequent blocks will contain incorrect hashes.
Grokking the idea of a chain is certainly apparent. However, it's a bit less clear in what specific way referencing blockchain immutability with this statement should be taken. If an attacker corrupted an earlier block in the chain, is that being mentioned as something that occurs after all subsequent blocks have already been created, thus proving the corrupted block is, indeed, corrupted by way of identifying it via verifying hashes and seeing a corrupted one?
If a bad actor corrupted block N, then all blocks after block N would themselves be corrupt (and presumably invalid and a waste of mining effort), correct? At this point, it seems to me that protecting the integrity of the chain requires dismissing the corrupted block & all its children, right? Doesn't that kind of indicate mutability of the chain? Or is immutability maintained by allowing corrupted blocks to remain in the chain, but some other process stepping in to essentially invalidate blocks?
I think there's something I'm missing here. No doubt it's obvious, and I'm just looking past it.
edit: I'm also just starting the consensus section, so perhaps that will resolve my confusion.
edit2: After finishing consensus, I think I get it.
So at N + M block, changing the Nth block means all M blocks will become corrupted and needs to be changed or recalculated. The consensus or the p2p will come in the way of re-doing the blocks as everyone except the attacker will be at N+M. So unless everyone agrees there will be no way to change those blocks ie forced immutability.
Though the part people have hard time getting their head that there is never a single blockchain in existence. At a given point there are multiple blockchains existing but only the block with "most work" or the most difficult to calculate hash is added to the main chain. That is why the "confirmations" are required for a payment. The older a block gets, the probability of it getting added to the chain is higher. In bitcoin depending on the site, some take 6 confirmations or 6 blocks before being sure that the coin cannot be double spent.
Which is kind of where I wonder how overrides can be put in place. How can one return that money? How does one force a bad actor to hand over the private key for the newly flush wallet ?
1. Transactions can be secured using public-key encryption. This way Bob can't spend Alice's coins (unless he has her key pair).
2. Wallets are typically a collection of public/private key pairs, where each pair is a ledger address/password combo.
Also, I could be wrong, but it looks like the example code will accept longer peer chains even if they're completely different.
I think there is a problem with his proof-of-work algorithm in that his proof of work is not tied to the transactions in the blockchain. Should't it include the hash of the previous block or something, in order to prevent people from simply building a new blockchain while re-using the proofs of work?
Bonus: There is a pretty good Coursera course on the same - Bitcoin and Cryptocurrency Technologies  and it also has a really good companion book - Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction 
 - https://jeiwan.cc/posts/building-blockchain-in-go-part-1/
 - https://www.coursera.org/learn/cryptocurrency
 - https://www.amazon.com/dp/B01GGQJ2XW
Everybody learns different, but I'm wondering how many HN readers are "code-first" sorts of learners?
When they receive transactions (from a client, or a peer), they simply forward them to all other peers (if it's the first time they've seen them.)
That's basically it. :-)
I've thought a little about it, and I wonder what could be achieved. Storing the data on peers, redundancy, private or public access... I think it's possible, but I'm not really sure. Does anyone have already studied the idea?
> I've thought a little about it, and I wonder what could be achieved.
You should have put less thought and more learning in the topic,
especially history of cryptosystems. Blockchain is not the first idea of
cryptographic money, and in fact, from cryptographic perspective it's not
money at all, it's document timestamping service.
> Does anyone have already studied the idea?
Yes, cryptographers, for a long time.
Right: Bitcoin is just the first decentralized cryptographic money. The decentralized part is where blockchains shine; if you can have a trusted authority, then almost literally any other solution is much more efficient. I groan whenever I see blockchains suggested as a solution for something where trustlessness is not a priority.
>and in fact, from cryptographic perspective it's not money at all, it's document timestamping service.
I'm not sure that's mutually exclusive or that that's a useful distinction, unless the point is that Bitcoin/blockchains can also be easily used for timestamping.
> I'm not sure that's mutually exclusive or that that's a useful distinction, unless the point is that Bitcoin/blockchains can also be easily used for timestamping.
Money is a token that can only be spent once by its current owner, and for
verification it doesn't need knowledge about all the other tokens.
There were attempts at designing cyrptographic protocol for money, and they
had this property baked in at the cryptography level. Bitcoin's spending
verification is placed not in the cryptographic protocol, but higher, in the
protocol protected by the cryptographic protocol. Thus, Bitcoin is not
money, but document timestamping.
Money has different cryptographic properties, and Bitcoin implements money on
top of document timestamping. People untrained in cryptography (and thus the
ones unqualified to touching the protocol part) usually mistake one for the
other, and are usually heavily surprised that you can do document timestamping
with Bitcoin, which was designed specifically for that.
Because if they're not, what's stopping an attacker adding random transactions to exising blocks, thus enabling double spending?
If they are, how is it possible to validate a bitcoin transaction in less than 10 minutes?(the average target time to mine a btc block)