FYI: You might also be interested in Awesome Blockchains [1] includes blockchain samples (from scratch) with proof of work, transactions, etc. in Ruby, Python, and JavaScript. PS: I've also bundled up the samples for easy (re)use into libraries, see the blockchain-lite ruby gem or node package module (npm), for example. Happy blockchaining. Cheers.
[1]: https://github.com/openblockchains/awesome-blockchains
I know all discussions about blockchains must include the obligatory mention of mankinds utopian future as a result of it, but damn did it feel jarring here. The article was such a rare and excellent technical explanation behind the concept of blockchains. It was all meat and no hype. And then it ends with "Blockchains will rapidly change the way we think about economies, governments and record-keeping.". Seems like a pretty amazing linked list, would love just a bit more explanation why you were lead to that conclusion.
FYI: For more blockchain samples from scratch (in JavaScript) see the notes from last week's Vienna.js talk titled "Build Your Own Blockchain in 20 Lines of JavaScript - Blockchain! Blockchain! Blockchain! For Fun (and Profit)" - https://github.com/geraldb/talks/blob/master/blockchain.md Cheers.
Damn, this is a great post. It really demystified a lot for me.
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.
A block is connected or chained to the previous block by using the previous block's hash and connected to the next block by providing it's hash. So the immutability comes after the fact ie once the block is created.
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.
As I understand it, there are no bad actors post-ante. Either your transaction is accepted or not. If, for example, someone steals your private key and moves money from your wallet to theirs, it is, according to the block chain, their money, even if that's not true according to any jurisdiction on the planet.
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 ?
Yeah, I’m not quite sure I perfectly grasp where wallets come in. It’s not covered in the article, since it’s focused on how the blockchain works at a pretty basic level. Protecting transactions is still a mystery, since it seems one could with the implementation shown, with access to the chain and all transactions, just craft a block that transfers everything to themselves.
> 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?
If you are interested in building one in Golang, here is a good article I read recently - Building Blockchain in Go [0]
Bonus: There is a pretty good Coursera course on the same - Bitcoin and Cryptocurrency Technologies [1] and it also has a really good companion book - Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction [2]
Isn’t there a mistake with your proof of work?
Because the way you implemented the proof of work, it isn’t tied to the transaction history.
This means that somebody could re-write the transaction history, compute the new block hashes, and re-use your proofs of work.
He could then mine a single new block, and thus create a new longest chain and cause everybody to accept this chain.
The way to fix this would be to include the hash of the last block in the proof of work for the next block. This way, proofs of work can not be recycled on other chains.
I always seem to internalize concepts like this better using code, vs. formal math or abstract explanations. I learned basic neural networks that way using this book last year:
Whole heartedly agree, I can't believe how well it breaks it down. I'm already looking forward to the next post about transaction verification. I'm actually going to try and solve it myself before reading the new post.
Thanks for this. Any idea how to build a simple p2p network though (over the internet not local host) and make it decentralized? That’s the hardest part :p
It's actually not that hard. Most blockchains use a variation of Gossip, which is quite trivial to implement. On startup, your nodes get a list of seed nodes, recursively ask for peer lists until they can connect to some "max peer count."
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.)
Aren't there existing implementations of decentralized data storage or database that use a blockchain?
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?
Databases or data storage would be some of the dumbest applications of
blockchain. Blockchain is very expensive way of storing data, much more
expensive than plain DHT.
> 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.
>Blockchain is not the first idea of cryptographic money,
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.
>> 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.
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.
When a software concept is explained in code it leaves no ambiguity, can anyone verify this is a legit explanation? I do find it make sense but some code such as the Proof of Work I had to just trust the writer without testing it out
