I know they're trying to make it slightly more accessible, but I really wish that - especially when it's coming out of Princeton University - they would actually specify that reality is a bit more complex and they're giving slight simplifications.
I'm not a grump, so I'll also give some thumbs ups - and I'll happily also stand corrected myself
The task of Bitcoin miners04:02 -
watch lecture at t=4m02s"And then you have to start searching over this nonce field to try to have the hash of the block header start with the required number of zeros."
The 'leading number of zeros' has often been used as a simplification. Unfortunately this causes some confusion as some people wonder if that's the number of zeros you typically see on screen (in hexadecimal), or the number of bit-wise zeros, and leads to the incorrect impression that the number of zeros is all that matters; i.e. as a further simplification, are 0x0001 and 0x000F equal, given that they have the same number of leading zeros, if we're actually looking for a value below 0x000A?
As difficulty increases, the appropriateness of this simplification decreases.
http://bitcoin.stackexchange.com/a/80344:47 -
watch lecture at t=4m47sThe lecturer states that there is a parameter in the coinbase transaction called extranonce. Technically, this is not a parameter. The coinbase transaction has a field that can contain arbitrary data, and some part of that has been usurped for the purposes otherwise described, and which was only later formalized. Sort of.
http://bitcoin.stackexchange.com/questions/36455/determining-a-blocks-extranonce-value/36461#364614:47 -
watch lecture at t=4m47sThis would also have been a good point to mention that any data change can be used to modify the input header, including e.g. the timestamp which has also been used for extending the range of hashable input without modifying included transactions.
https://mining.bitcoin.cz/user-manual/stratum-protocol#ntime7:38 -
watch lecture at t=7m38sThe lecturer states that the difficulty is adjusted every 2 weeks. This is technically incorrect. It is adjusted every 2016 blocks. Those 2016 blocks should take 2 weeks, and the difficulty is adjusted in order to meet that goal.
It also states that it looks at the time taken for the last 2016 blocks. This is also technically incorrect, but is less fundamentally incorrect - it's actually 2015 blocks, an off-by-one issue. At least, I don't think that was ever modified
https://bitcointalksearch.org/topic/m.5553918:48 -
watch lecture at t=8m48sThe lecturer notes that "generally, more and more hash power comes online" and how this affects the difficulty. As one of their slides had an August 2014 date on it, the lecture was authored before the first difficulty drop in a long time (December 2nd, 2014), but it would still have been good to mention the case of less hash power coming online, causing a drop in difficulty.
https://bitcointalksearch.org/topic/m.97226628:48 -
watch lecture at t=8m48sSHA256(SHA256()) "For reasons that aren't completely specified"
Though I don't know the validity of the claim, it's mentioned at several sources that this is related to birthday attacks against SHA1;
https://en.bitcoin.it/wiki/Hashcash#Double_HashMining hardware14:50 -
watch lecture at t=14m50sThe lecturer notes that for a given CPU, it would take 134,461 years to find a block, and states further "if you're mining on a general purpose PC today [...] it's gonna take you that 140,000 years". It should be noted that this is an average. It could take many times longer, it could take a split second.
The same issue applies to 20:40 regarding GPU mining, 24:00 for FPGA mining.
The lecture does go into this at 51:08, but a quick note about it with a "we'll get back to that later" would have been good, as by then it's more than half an hour ago since these initial statements.
17:38 -
watch lecture at t=17m38s'Goodput' - I don't think I've heard that term used for Bitcoin mining - more for block relaying - but at least pointing out that you can trade off slightly higher errors against a higher performance was nice, even if they didn't go in-depth on that.
http://diyhpl.us/~bryan/papers2/bitcoin/wizards/2013-12-06.txt - IRC log with the use of 'goodput' by Bitcoin devs as referring to relaying blocks.
https://bitcointalksearch.org/topic/m.561665922:15 -
watch lecture at t=22m15sThis section would also have been good to mention some custom FPGA board work, as that's really where custom (not just using off-the-shelf computers/GPUs/FPGA dev boards in racks) Bitcoin mining rigs started. Examples:
Icarus:
https://bitcointalksearch.org/topic/fpga-development-board-icarus-discontinued-important-announcement-51371 (most mining software and several devices still implement its comms protocol)
ModMiner:
https://bitcointalksearch.org/topic/high-efficiency-fpga-asic-bitcoin-mining-devices-httpsbtcfpgacom-79637X6500:
https://bitcointalksearch.org/topic/x6500-custom-fpga-miner-40058BFL Single:
https://bitcointalksearch.org/topic/1ghs-20w-500-butterflylabs-is-it-a-scam-48863 (there's probably a better thread for this)
24:26 -
watch lecture at t=24m26sNot technically errors, but as of the date that these videos were posted, the examples given - CoinTerra's TerraMiner and BFL's Monarch - are very much outdated. CoinTerra went out of business in January of 2015.
https://web.archive.org/web/20150202050534/http://cointerra.com/25:09 -
watch lecture at t=25m09sPointing out the time it takes for you to get a miner being an important factor. Perhaps that makes the previous mentions more appropriate. Perhaps it's also meta, given that the video itself is by the time of publishing based on quite old data.
26:40 -
watch lecture at t=26m40s"perhaps the fastest chip development ever!"
This is really something that you won't hear much about outside of technical conferences, but the design development behind Bitcoin ASICs is absolutely staggering. There's a paper from two years back that also made that observation. Outside of mobile development, this rapid development is generally unheard of.
I will make the side note that Bitcoin mining, unlike mobile processors/sensors/etc., is a relatively simple task so seeing that design development isn't surprising in terms of technology, but certainly is in terms of going from a non-existent market to one that is booming (or has boomed).
http://cseweb.ucsd.edu/~mbtaylor/papers/bitcoin_taylor_cases_2013.pdf - Bitcoin and The Age of Bespoke Silicon
28:08 -
watch lecture at t=28m08sUnlike the CPU/GPU/FPGA examples, here the lecturer correctly notes that - for the given ASIC miner - it would take 14 months
on average to find a block.
29:35 -
watch lecture at t=29m35sPointing out that most consumer miners probably lost money, that Bitcoin's rise in exchange rate may have saved them, but that they probably would have been better off if they had bought Bitcoin directly instead.
https://bitcointalksearch.org/topic/m.555719532:32 -
watch lecture at t=32m32sThe lead-in to the debate on small miners vs industrial miners and discussion on ASICs and how they fit into the Bitcoin ecosystem, and pointer to a future video on alternative mining work. I suspect the questions raised here would be addressed in that video, but in terms of the original idea behind Bitcoin, Satoshi himself has said that this type of centralization is to be expected.
https://bitcointalksearch.org/topic/m.6306 Energy consumption & ecology42:44 -
watch lecture at t=42m44sThese slides should have been reading Gh/s, rather than GHz. The distinction is debatable, but because mining hardware has itself a clock frequency (Hz), this should not be conflated with how that translates into a hash rate (h/s)
45:28 -
watch lecture at t=45m28s"All payment systems require energy"
Although I'll add the side note here that some cryptocurrencies still manage to combine the task of securing the block chain with getting a secondary use out of the work performed (although realistically speaking it seems to be their primary use as these cryptocurrencies aren't widely used at this time). This may be something they'll touch on in a future video. Examples:
math: primecoin:
https://bitcointalksearch.org/topic/xpm-ann-primecoin-release-first-scientific-computing-cryptocurrency-251850math: riecoin:
https://bitcointalksearch.org/topic/annric-riecoin-constellations-pow-cpu-hard-fork-successful-world-record-446703medicine: curecoin:
https://bitcointalksearch.org/topic/ann-curecoin-20-is-live-mandatory-update-is-available-now-dec-2018-603757medicine: foldingcoin:
https://bitcointalksearch.org/topic/ann-foldingcoin-mine-for-medicine-phase-20-781352data storage: BURST:
https://bitcointalksearch.org/topic/annburst-burst-efficient-hdd-mining-new-123-fork-block-92000-731923data storage: storagecoin:
https://bitcointalksearch.org/topic/annstoragecoin-a-blocktree-based-proof-of-storage-cryptocurrency-48635946:40 -
watch lecture at t=46m40s"Data furnaces".
This goes into the dual-use of the actual hardware for both mining, and heat generation. This has popped up on these forums several times as well, usually tongue-in-cheek to refer to older hardware, but sometimes proffered as a more serious suggestion.
https://bitcointalksearch.org/topic/mining-machine-vs-space-heater-36429https://bitcointalksearch.org/topic/m.1076805648:15 -
watch lecture at t=48m15sThe lecturer makes the suggestion that network hashing power may go up/down seasonally if in fact miners were used as "Data furnaces". Given the points made earlier about small miner vs industrial miners, and where they tend to put their mines, any such limited use would have negligible impact on the network hashing power. It also ignores a global mining landscape. This felt out of tone, tbh.
Mining pools51:08 -
watch lecture at t=51m08sSlight redemption with regard to the time it takes to find a block, as the lecture dips its toe into variance; "Mining is a random process - you don't know when you're going to find your next block". This is more a prelude into pooled mining, however, and doesn't go into details.
https://bitcointalksearch.org/topic/m.731382853:56 -
watch lecture at t=56m27sThis may also have been a good point to 1. explain the difficulty as it applies to the hardware level (quick check for golden nonce, if fixed difficulty), the pool level (check if valid share based on share difficulty), and the network level (check if valid hash based on block difficulty), and 2. why pools may vary the difficulty
https://en.bitcoin.it/wiki/Difficultyhttps://en.bitcoin.it/wiki/Higher_difficulty_pooled_mining56:27 -
watch lecture at t=56m27sIn the lecture it is suggested that pool miners will send in all their shares
after one of them finds a valid block. This is generally incorrect. Although in theory it could work as described - for the very reason the lecture does mention a bit earlier: shares can't be faked - in practice shares are sent all the time for various reasons (transparency, monitoring, etc.)
https://bitcointalksearch.org/topic/m.3066257:27 -
watch lecture at t=57m27sPPS, PROP and '"Luke-jr" approach'... no PPLNS and explanation of why that came into existence. Missed opportunity given the further description of the three that
are listed.
https://bitcointalksearch.org/topic/what-is-wrong-with-the-prop-payout-system-9856321:00:03 -
watch lecture at t=1h00m03sstratum, getwork, getblock
share? I suspect they meant getblock
templatestratum:
https://en.bitcoin.it/wiki/Stratum_mining_protocolgetwork:
https://en.bitcoin.it/wiki/Getworkgetblocktemplate:
https://en.bitcoin.it/wiki/Getblocktemplategetblockshare:
https://www.google.com/webhp?#q=%22getblockshare%22 (crickets)
Mining incentives and strategies1:23:20 -
watch lecture at t=1h23m20sTransaction fees. Only listed in green here because I was wondering why they hadn't been properly mentioned yet outside of the attack strategies section, as 'tips'. This should really have been mentioned early on when discussing the reward for mining.
https://en.bitcoin.it/wiki/Transaction_fees1:24:30 -
watch lecture at t=1h24m30s'Magic number': priority > 0.576 = no transaction fee.
The lecture suggests that this seems random and very arbitrary. However, the 0.576 is written into the client as COIN * 144 / 250. Plunking that into the very equation on the same slide (sum(input_value * input_age)/size_in_bytes) makes it seem a lot less random - albeit still somewhat arbitrary.
https://github.com/bitcoin/bitcoin/blob/f914f1a746d7f91951c1da262a4a749dd3ebfa71/src/txmempool.h#L18general - and very much petty - feedback
As a commenter in the YouTube video mentions, there's a video editing issue about 40m25s in (slight arithmetic fluke which he later corrects).
Something that bothered me (ever so slightly) more is the lipsmacking. This could easily be edited out of the audio. This is probably a microphone dynamic gain issue and wouldn't be nearly as noticeable in person.