I'm willing to give them the benefit of doubt, they do however have a lot of damage to repair - & if this ticket system doesn't work out right, I fear the worst for them with regards to yet more customer backlash on this forum.....

Let's hope they do it right.

I'm not a fan of ticket support - it's an easy way to be ignored. That's why crooks like GHash/CEX/BAN use it. A good support system is open & transparent.

But do you honestly think any of the big manufactures will do this? Justify even if it was a dollar per x item. I think until more acceptance its a pipedream.  

I would love it though really would.  Just don't expect it soon.

couple of mine were deleted. Humorous, nothing ugly or terribly off topic. Seemed random. In a self moderated thread, too. I'm dead certain the owner of the thread didn't do it, he was in on the jokes. And we're friends.

Besides, when has BCT EVER deleted spam or scams?

Maybe it's not worth to pay the fee...

thanks for posting this information

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 miners
04: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/8034

4:47 - watch lecture at t=4m47s
The 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#36461

4:47 - watch lecture at t=4m47s
This 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#ntime

7:38 - watch lecture at t=7m38s
The 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://bitcointalk.org/index.php?topic=46498.msg555391#msg555391

8:48 - watch lecture at t=8m48s
The 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://bitcointalk.org/index.php?topic=808145.msg9722662#msg9722662

8:48 - watch lecture at t=8m48s
SHA256(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_Hash

Mining hardware
14:50 - watch lecture at t=14m50s
The 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://bitcointalk.org/index.php?topic=508851.msg5616659#msg5616659

22:15 - watch lecture at t=22m15s
This 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://bitcointalk.org/index.php?topic=51371.0 (most mining software and several devices still implement its comms protocol)
ModMiner: https://bitcointalk.org/index.php?topic=79637.0
X6500: https://bitcointalk.org/index.php?topic=40058
BFL Single: https://bitcointalk.org/index.php?topic=48863.0 (there's probably a better thread for this)

24:26 - watch lecture at t=24m26s
Not 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=25m09s
Pointing 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=28m08s
Unlike 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=29m35s
Pointing 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://bitcointalk.org/index.php?topic=504530.msg5557195#msg5557195

32:32 - watch lecture at t=32m32s
The 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://bitcointalk.org/index.php?topic=532.msg6306#msg6306

Energy consumption & ecology
42:44 - watch lecture at t=42m44s
These 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://bitcointalk.org/index.php?topic=251850.0
math: riecoin: https://bitcointalk.org/index.php?topic=446703.0
medicine: curecoin: https://bitcointalk.org/index.php?topic=603757.0
medicine: foldingcoin: https://bitcointalk.org/index.php?topic=781352.0
data storage: BURST: https://bitcointalk.org/index.php?topic=731923.0
data storage: storagecoin: https://bitcointalk.org/index.php?topic=486359.0

46: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://bitcointalk.org/index.php?topic=36429.0
https://bitcointalk.org/index.php?topic=988572.msg10768056#msg10768056

48:15 - watch lecture at t=48m15s
The 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 pools
51:08 - watch lecture at t=51m08s
Slight 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://bitcointalk.org/index.php?topic=651450.msg7313828#msg7313828

53:56 - watch lecture at t=56m27s
This 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/Difficulty
https://en.bitcoin.it/wiki/Higher_difficulty_pooled_mining

56:27 - watch lecture at t=56m27s
In 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://bitcointalk.org/index.php?topic=1976.msg30662#msg30662

57:27 - watch lecture at t=57m27s
PPS, 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://bitcointalk.org/index.php?topic=985632

1:00:03 - watch lecture at t=1h00m03s
stratum, getwork, getblockshare?  I suspect they meant getblocktemplate
stratum: https://en.bitcoin.it/wiki/Stratum_mining_protocol
getwork: https://en.bitcoin.it/wiki/Getwork
getblocktemplate: https://en.bitcoin.it/wiki/Getblocktemplate
getblockshare: https://www.google.com/webhp?#q=%22getblockshare%22 (crickets)

Mining incentives and strategies
1:23:20 - watch lecture at t=1h23m20s
Transaction 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_fees

1: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#L18

general - 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.

Don't listen to these haters Barbara.  I appreciate you contributing to the BTC community, and hope you will continue to do so in the future!  

-David

I am not to surprised sadly with this.  They took images I made for a guide for the SilverFish 28 (scrypt miner).   Was really fun asking them in person at a bitcoin conference how it happened.  They acted totally surprised... then admitted they might have gotten it off forum.   They did not take image down till they stopped selling the miner.

I don't like a lot of drama so I just let it be.  Guess karma happens sometimes.