This is great. I am indebted for the clarity you bring to this topic through your elegant sentence forming skills. There are a lot more "proof of * " (e.g. proof of stake) these days, so, looking forward to a few more, I guess?.
Not sure I'm going to do more blockchain videos -- I did those mostly to teach myself the topic, and for now I am happy with what I now know about the area. :-)
Noob question: Can a rouge computer insert a block with a correct nonce but fraudulent transactions just because it was the fastest? How is this use cases prevented.
By definition whatever computer is fastest isn't "rouge", but is correct. Preventing fraudulent transactions (such as "Bob steals $1 from my wallet") is not part of the consensus algorithm (since all consensus does is makes sure everyone agrees on what transaction happened, even if those transactions are "fraudulent"). Preventing fraud of this form is done using cryptographic protections on the wallets themselves.
Not sure I understand the question, but I'll take a shot. The benefit of the proof of work consensus algorithm is that as long as the trustworthy nodes outnumber the untrustworthy nodes by enough[1] then the trustworthy nodes will reach consensus with each other. If you run your own node, and trust your own node, then you have a trustworthy node (by definition). Or are you asking how to locate a node to put your transaction into a block? Or are you asking how to locate and identify peers to exchange blocks with to populate your own local copy of the blockchain? [1] The original Bitcoin paper asserts that a simple majority is enough. Subsequent work has shown that that is not quite true, and my understanding is it is likely closer to 2/3 that is required to guarantee consensus is reached.
@@DistributedSystems Thanks for your reply. I was thinking of a scenario as below. Suppose new node wants to join the system. And some bad node generates a chain of blocks with their hashes maintained but all with false transactions. Is the node vulnerable to assume the bad node as a good node and follow the bad nodes instead of the good ones? Apologise if my question sounds profound...
Fascinating question. Let's say a new node joins the system, and for some reason chooses to only talk to a group of colluding "evil" nodes to get its copy of the blockchain. Then those evil nodes can trick the new node into getting a corrupt blockchain, that is true. So why isn't that a problem in practice? For a few reasons. First is how Bitcoin nodes find their initial peers. This problem is called "peer discovery" (and honestly, I've not looked into it before you asked your question). A bitcoin client reaches out to several nodes to get its blocks (and so they'd all have to be corrupted in the same way to trick you). It picks its initial nodes based on DNS seeds and a hardcoded IP address list -- so in theory, an attacker could pull off this attack if they corrupted all the hosts on that list. Once the new node is connected to at least one good node, that node can tell it about other peers and then the new node can remember those peers. A backstop against this class of attack -- anyone attempting to learn about bitcoin will likely compare what they see on their local client to published information about the blockchain, such as on blockchain.com. If their blockchain differs from that (such as not seeing all the transactions, or failing to have a Proof of Work problem size that is as hard) then this will raise suspicions pretty fast.
Nice work! Question.... how does the block that sits at the head of the short end of the fork ever get reconciled ? The node that proposed the block has to be minimally notified that its block was rejected so it can resend.... is that a correct understanding ?
(Sorry for the delayed response -- was on vacation.) The node that proposed the block will learn about the other block(s) with the same parent. It will then learn about additional blocks which get added to that branch. As more and more blocks get added to the other branch, it can increase its confidence that the block it added to the blockchain will never be used by anyone else. (Really, it can be reasonably sure as soon as the other branch has more than one block in it, since no other node will waste time trying to add to a shorter branch.) The mining node is not responsible for retrying the transactions in that abandoned block. Instead, the owners of those transactions try to convince that node and other mining nodes to include their transaction in a future block (by offering transaction fees as a part of the transaction). Assuming the transaction gets picked up by other nodes, it will eventually be added to the blockchain when a new block is mined.
I'm sorry, but I was searching for some information on the Strawman Consensus Algorith mentioned at min 5.30, but I could find none ... It would be possible for you to give a reference?
Ahh, sorry -- I wasn't trying to imply that this was a known published algorithm, but instead is a strawman argument I was using to help teach some ideas. en.wikipedia.org/wiki/Straw_man
Why is this channel so underrated ? Great explanation. Thanks Chris!
Thanks!
This is great. I am indebted for the clarity you bring to this topic through your elegant sentence forming skills.
There are a lot more "proof of * " (e.g. proof of stake) these days, so, looking forward to a few more, I guess?.
Not sure I'm going to do more blockchain videos -- I did those mostly to teach myself the topic, and for now I am happy with what I now know about the area. :-)
The best explaination about PoW I've ever heard :)
Glad you liked it. There are some other great ones out there. I really liked the one by 3blue1brown.
This video is so useful in understanding the purpose of proof of work
Glad it was helpful.
Nicely explained sir. Kindly upload a video on Stellar Consensus Protocol with examples and implementation.
Thanks! I've never looked into the Stellar consensus protocol, so I'm not sure I'd be able to do it justice. ;-)
Happy to have been the 200th person to like the video
This was awesome. Anyone with a link to how the POS consensus is achieved?
Noob question: Can a rouge computer insert a block with a correct nonce but fraudulent transactions just because it was the fastest? How is this use cases prevented.
By definition whatever computer is fastest isn't "rouge", but is correct.
Preventing fraudulent transactions (such as "Bob steals $1 from my wallet") is not part of the consensus algorithm (since all consensus does is makes sure everyone agrees on what transaction happened, even if those transactions are "fraudulent"). Preventing fraud of this form is done using cryptographic protections on the wallets themselves.
Hi Chris, nice explanation. But I haven't heard you talking about how to find a trust worthy node?
Not sure I understand the question, but I'll take a shot.
The benefit of the proof of work consensus algorithm is that as long as the trustworthy nodes outnumber the untrustworthy nodes by enough[1] then the trustworthy nodes will reach consensus with each other. If you run your own node, and trust your own node, then you have a trustworthy node (by definition).
Or are you asking how to locate a node to put your transaction into a block?
Or are you asking how to locate and identify peers to exchange blocks with to populate your own local copy of the blockchain?
[1] The original Bitcoin paper asserts that a simple majority is enough. Subsequent work has shown that that is not quite true, and my understanding is it is likely closer to 2/3 that is required to guarantee consensus is reached.
@@DistributedSystems Thanks for your reply. I was thinking of a scenario as below. Suppose new node wants to join the system. And some bad node generates a chain of blocks with their hashes maintained but all with false transactions. Is the node vulnerable to assume the bad node as a good node and follow the bad nodes instead of the good ones? Apologise if my question sounds profound...
Fascinating question. Let's say a new node joins the system, and for some reason chooses to only talk to a group of colluding "evil" nodes to get its copy of the blockchain. Then those evil nodes can trick the new node into getting a corrupt blockchain, that is true.
So why isn't that a problem in practice? For a few reasons. First is how Bitcoin nodes find their initial peers. This problem is called "peer discovery" (and honestly, I've not looked into it before you asked your question). A bitcoin client reaches out to several nodes to get its blocks (and so they'd all have to be corrupted in the same way to trick you). It picks its initial nodes based on DNS seeds and a hardcoded IP address list -- so in theory, an attacker could pull off this attack if they corrupted all the hosts on that list. Once the new node is connected to at least one good node, that node can tell it about other peers and then the new node can remember those peers.
A backstop against this class of attack -- anyone attempting to learn about bitcoin will likely compare what they see on their local client to published information about the blockchain, such as on blockchain.com. If their blockchain differs from that (such as not seeing all the transactions, or failing to have a Proof of Work problem size that is as hard) then this will raise suspicions pretty fast.
Nice work! Question.... how does the block that sits at the head of the short end of the fork ever get reconciled ? The node that proposed the block has to be minimally notified that its block was rejected so it can resend.... is that a correct understanding ?
(Sorry for the delayed response -- was on vacation.)
The node that proposed the block will learn about the other block(s) with the same parent. It will then learn about additional blocks which get added to that branch. As more and more blocks get added to the other branch, it can increase its confidence that the block it added to the blockchain will never be used by anyone else. (Really, it can be reasonably sure as soon as the other branch has more than one block in it, since no other node will waste time trying to add to a shorter branch.)
The mining node is not responsible for retrying the transactions in that abandoned block. Instead, the owners of those transactions try to convince that node and other mining nodes to include their transaction in a future block (by offering transaction fees as a part of the transaction). Assuming the transaction gets picked up by other nodes, it will eventually be added to the blockchain when a new block is mined.
Best explanation ever 🙌🏼
Thanks!
How do other nodes stop a malicious node that adds blocks without a timer, just pumping out blocks...
That's actually covered in the video. See the section starting here: ua-cam.com/video/f1ZJPEKeTEY/v-deo.html
I'm sorry, but I was searching for some information on the Strawman Consensus Algorith mentioned at min 5.30, but I could find none ... It would be possible for you to give a reference?
Ahh, sorry -- I wasn't trying to imply that this was a known published algorithm, but instead is a strawman argument I was using to help teach some ideas. en.wikipedia.org/wiki/Straw_man
Thank you so much sir.
Most welcome
Hi Dear sir could please help me about how to make build Distributed system at the environment.
thanks
I'm sorry -- I don't quite understand your question.
The inventor must have a fight with his/her spouse last night to come up with this consensus strategy -- no consensus? go to sleep.