41–50 of 77 posts
I really like the intention and good will behind the post but almost every part is incorrect (even on an abstract level not restricting to bitcoin). I feel like OP is yet another someone who needed the keyword "blockchain expert" on his/her linkedin profile and trying to justify it now with misleading and incomplete information.
> The PoW is suffice if the hash begins with a certain number of 0s This is a common explanation of PoW, but is actually incorrect. If you think about it, this would mean that the PoW difficulty could only increase (or decrease) by a factor of two. In reality, the block hash is simply interpreted as a (very large) number, and this number must be less than some other very large number (the "target"). So you do end up…
(author here) Absolutely. Thanks for pointing this out. If difficulty adjusted in factors of two, the ability of the network to accurately maintain its 10 mins blocktime become impaired. I try to keep these concepts rather simplified to ease the reading and learning process. Perhaps there should be a note for these situations.
Earlier quoted context omitted.
It is computed using only information embedded in the block chain, specifically the timestamps of blocks 2016 * i and 2016 * (i+1).
But aren't blockchain timestamps unreliable? It was my understanding that difficulty was based on subjective node timestamps..
Once embedded in the header, everyone will agree on past timestamps as they agree on the chain with the most accumulated difficulty.
Earlier quoted context omitted.
Each node independently comes to the new difficulty on their own in an entirely deterministic way. After 2 weeks there should be 2016 blocks mined, 1 block every 10 minutes. After each 2 week period every node recalculates the new difficulty based on the actual number of blocks mined in the last 2 weeks. If the actual number of blocks produced was 25% higher than the target of 2016, then simply increase the difficult…
Thanks. Given that this relies on subjective timestamps, is this really entirely deterministic? I can imagine that one node counted 2014 blocks in the past two weeks, another 2015. What happens in such cases?
I really like the intention and good will behind the post but almost every part is incorrect (even on an abstract level not restricting to bitcoin). I feel like OP is yet another someone who needed the keyword "blockchain expert" on his/her linkedin profile and trying to justify it now with misleading and incomplete information.
I really like the intention and good will behind the post but almost every part is incorrect (even on an abstract level not restricting to bitcoin). I feel like OP is yet another someone who needed the keyword "blockchain expert" on his/her linkedin profile and trying to justify it now with misleading and incomplete information.
I already qualify for the "blockchain expert" tag by working in the space for 2 years, though I don't find it that desirable. Maybe a few years ago.
I wrote a toy (but working) implementation of the Bitcoin algorithm here: https://github.com/tlrobinson/tomcoin The main logic is a few hundred lines of code: https://github.com/tlrobinson/tomcoin/blob/master/src/node.j... A somewhat unique aspect is since it's written in JavaScript a node can run on the server or the browser, which makes for easy demos: 1. Open https://tomcoin.herokuapp.com/ and https://tomcoin1.her…
const {
mine,
sign,
verify,
hash,
validateProofOfWork,
stripTxSignatures,
generatePrivateKey,
getPublicKey
} = require("./util");
And will this really run in a browser? I think brosers don't have require()?
Earlier quoted context omitted.
It used to work this way, but got changed to a less-than check for performance reasons. The Bitcoin whitepaper [0] even has the original approach: > The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. [0] https://bitcoin.org/bitcoin.pdf
> It used to work this way, but got changed to a less-than check for performance reasons. I don't know who told you that, but they were weirdly confused. It not unlikely the case that sometime early in development (long before publication) that it was bits-based, not only is this how the standard hashcash code works-- but the Bitcoin code calls the relevant field that encods the difficulty "bits". But Bitcoin itself…
The bitcoin whitepaper told them that, in more than one place too, so it's not a simple typo, e.g.
...we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.
I wrote a toy (but working) implementation of the Bitcoin algorithm here: https://github.com/tlrobinson/tomcoin The main logic is a few hundred lines of code: https://github.com/tlrobinson/tomcoin/blob/master/src/node.j... A somewhat unique aspect is since it's written in JavaScript a node can run on the server or the browser, which makes for easy demos: 1. Open https://tomcoin.herokuapp.com/ and https://tomcoin1.her…
const { mine, sign, verify, hash, validateProofOfWork, stripTxSignatures, generatePrivateKey, getPublicKey } = require("./util"); What does this do? And will this really run in a browser? I think brosers don't have require()?
I wrote a toy (but working) implementation of the Bitcoin algorithm here: https://github.com/tlrobinson/tomcoin The main logic is a few hundred lines of code: https://github.com/tlrobinson/tomcoin/blob/master/src/node.j... A somewhat unique aspect is since it's written in JavaScript a node can run on the server or the browser, which makes for easy demos: 1. Open https://tomcoin.herokuapp.com/ and https://tomcoin1.her…
const { mine, sign, verify, hash, validateProofOfWork, stripTxSignatures, generatePrivateKey, getPublicKey } = require("./util"); What does this do? And will this really run in a browser? I think brosers don't have require()?