Great missive indeed, had a great time listening to this one!
Some really interesting points too btw. I especially liked this one:

Now, am I the only one that immediately thought of a money printer? 

Damn slick design on MoneroDice. Very nice job rznag & fluffy.

GSYTeam:
Please check the Skynodes description on the roadmap, which is incorrectly stating 5 coins per stake.

@all:
We've just switched to the long term fixed reward bracket of 0.5 coins per stake.
Still hoarding, though more slowly now   

Igual, igual, não diria, uma vez que foi o primeiro fork de Ethereum.
Ainda assim, eu também não estou convencido que tenha qualquer valor de futuro.

Will do, cheers Smooth!

@Smooth:

Reporting back on the high mixin transfers I just did while running the light-node:
Both the 100 and 200 mixin transactions bounced (balance restored in the originating wallet after about 24 hours). I then attempted re-doing the 100 mixin transfer using a full-node, and that worked out, balance is confirmed at the receiving end.

I can imagine that the light-node would have a smaller UTXO set available to work with when building any transaction, though I would expect that the only limitation that would bring, would be a higher rate of instances where the necessary outputs for a given transaction are not available/found (when doing very high mixin values).
So, used mixin 100, and was transferring 5 aeon, while the balance on the originating wallet was exactly that of having solo mined a block the day before. In this particular instance, I don't have a clue as to what would cause the transaction to not be accepted when using the light-node, and then get accepted if done with the full-node.

About the instance where I reported that my light-node was actually some ~20 blocks behind, there's nothing meaningful in the logs. The only interesting thing that I noted, is that the moment when my node caught up with the rest of the network, was right after an automatic blockchain save (which takes just a few seconds to complete on this box). Dunno if this warrants any further investigation, could well have been an isolated case of my node running low on peers, having some external connectivity drop or something...

@GSYTeam: great update guys, really looking forward for some confront fun !!! 

@smooth: I'm still on the --pruning version, updated right after you had posted the equivalent 0.9.4.0 source. No issues at all to report, I get solo blocks now and then, I get a peer or two dropped as 'can't supply pruned blocks'. I've been doing as well some transactions in and out, no trouble.

I'm doing a couple of high mixin transfers now, for no particular reason. Tried mixin 500, and the daemon could not find a suitable transaction split method. I figure this is expected, as such high mixin will be attempting/generating a transaction that is too large for the current block size. A couple others with mixin 100 and 200 went through, will see if there is any that bounce.

Edit: Actually, have one odd issue, though I need to look at my logs 1st to see if I make any sense of it. It looks that my daemon was ~20 blocks behind just now, even though it had been running for over 48h, and had even found a couple of blocks in the meantime. I think it has/had many peers connected all the while, will check further.

This is the monitor, grid-style, on Nvidia Inspector. You can fully customize what is on display, launch the monitor from a command line or batch file, save settings as needed. Are you looking for something else?

You sure about this sp_?
I don't have any 750 TI cards anymore to test this out, and coincidentally, I was also using EVGA's PrecisionX when I did have them, so I don't have any personal account either way. A quick google search found me some hits showing posts from people that reported using Nvidia Inspector with the 750 TI to enable/disable performance mode and other stuff.

bensam1231: Try out Nivida Inspector
You can even build simply batch files that tweak all your cards with different parameters in one go. To satisfy even the most OCD miners out there, you can also build custom batch files for every different algorithm (since different algos allow for different overclock settings).

Here's a sample batch file tweaking one 980 card, undervolted, high fan, high clocks, fixed pstate-2:
nvidiaInspector.exe -setBaseClockOffset:0,0,220 -setgpuclock:0,2,1390 -setMemoryClock:0,2,3505 -setpowertarget:0,120 -setfanspeed:0,80 -forcepstate:0,2

Cheers!

@t-nelson: extending the invite that every cuda miner developer has probably received at some point:
Some of the usual suspects (both developers & community) hang out at #ccminer @freenode. It is not the most active channel in freenode, but it is a great place to exchange ideas with the other developers and the few of us there always try to help each other out (testing, etc).

In case that IRC is not your usual thing, maybe webchat will get you there: #ccminer webchat

I dug around the Kopiemtu thread for the relevant bits, and seems this is the most important one:
In xorg.conf, just before the coolbits statement:

If I read right, this is how one sets up fake monitors on headless systems.

This will not work for every driver version. Will probably require this command to setup a fresh xorg.conf if a driver update is needed.

I dunno, since I don't have a Linux system currently to test this on. I'd already been able to setup fake monitors (manually) before, so I know didn't use this at the time, but I did have 1 monitor attached to the 1st GPU, so mine was not a fully headless setup.

Edit: better yet, check the source. Hashbrown looks to be doing good stuff over there! 
https://litecointalk.org/index.php?topic=16800.msg266088#msg266088

Cheers!

Skynodes = Masternodes

Yep. TSIV's Cryptonight ccminer complains whenever the blocks/threads (don't recall which one now) is not a multiple of the SMX/SMM on the card. IIRC, it does this also accurately for cards that did not exist when it was released, so the approach is not LUT based.

@sp_:
Shouldn't the optimal blocks/threads values always be relative to the number of SMM/SMXs in any given card? It might be possible to have ccminer automatically detect - and adjust - to the number of SMM/SMXs on the available cards, and then just use the intensity parameter for the fine tuning.

I lost this bit of information somewhere along the thread history, but seeing as you now have -X , is -i still doing anything on your fork? If both parameters can be used, what the F#%@ is each one doing? Thanks for clearing this up 

It's starting to look a bit mad to find the best settings for one's card, if there are 3 distinct parameters to tune (-X, -i, -l).

Yeps. On Windows it is extremely simple to set fixed clocks, fans, overclocking, so you can easily have a "benchmark platform".

With a headless Linux system I don't think there's any solution for fixed fans yet, others might know differently. I previously had fixed fans and clocks on Linux, but I perfectly recall that I specifically had to configure/attach a monitor in order to get that working at the time.

Most important recommendation I have, is to benchmark at a low'ish & fixed GPU clock setting (stuck in performance mode), along with a high'ish & fixed fan speed. This should eliminate most/all thermal & clock stability variations.

For significant code changes, and particularly when the changes are not strictly related to the hashing algorithm in particular - so more about backend/generally efficiency - definitely need to test with a pool, Nicehash is usually great at that, with a minimum interval of 4 hours, but ideally, a full 24 hour cycle.

For specific kernel changes, benchmark should be best (and also the practical approach). I tend to benchmark for whatever duration is necessary until I see that I get about 5 minutes of stable output speed & stable temperature reading. Some algorithms take a while ramping up, others not so much, some algorithms start faster, but slow down once temperatures get high enough.

@Sarahiko, the giveaway coins are to be distributed somewhere late 2015, if I recall correctly.
The Ziftr website has details on that, but the short of it is, there is no point in sending out free coins before the merchant network fully established.

There's enough vaporware altcoins around for the trading aficionados to play with. Ziftrcoin will have a real purpose, in that they will work much like a discount coupon, but this is only possible if there is meaningful merchant adoption (which I understand is what they are working on).

Exactly. Which is another reason why I'm really digging this light-node  

I have effectively been solo mining on the light-node ever since the 1st test release was posted. With light-node in mind, particularly in some future iteration where one can setup bandwidth limits and is powered by some DB backend, I would probably revise my suggestion at 20% reward boost ... Maybe some 10% would be a sufficient motivator. All arbitrary numbers that I'm pulling out of my rear end btw.  

Edit: Maybe worth considering a doubly-light-node, the rough equivalent of a light-node that stores an even smaller range of the network history? Or perhaps a strict barebones construct that would only store the absolutely necessary data (as you well described)... I would think that such a barebones node is still a valuable contributor towards network health (and security).

Edit2: Require some further thought as to how would we ensure that such a doubly-light-node or the barebones construct, would not include invalid transactions in blocks that it mines (double-spends, etc). Obviously, the offending node would eventually fork off, as the rest of the network would reject that block (assuming a super-majority of full nodes). Still, at minimum, this would represent a DoS attack on these nodes: that they could be "poisoned" with invalid transaction data, so that their blocks would be rejected by the network.

Edit3: Need moar edits 

Following your (criss-crossy) line of thought, here's another ramble on pools and miners:   

I think that pools are a necessary evil. The smallest of miners, would be practically impeded of participating on the mining network, if there were no pools, and given sufficient nethash that their average time to find a block would be leaning towards infinity (exaggerated, yes). 

On the other hand, pool concentration, and the lack of a technical necessity for running a node (for the majority of participants), present us with a very common dilemma:
nodes are too few, and they lack any substantial form of incentive.

I think this problem was indeed neatly approached by Spreadcoin, in that it attempted to prevent pool formation entirely. I think it failed at the original goal, but the fact that it resulted in a modified trust model (note the existing private pool for Spread) is quite interesting.
I'm not sure the same existed for Spread as I am not sufficiently familiar with it, but with Ziftrcoin, I know that there is an incentive to solo-mine, built on some of the same principles that Spread initiated, and by providing knowledge over the current transaction pool, solo-miners can claim a higher reward in their block finds (5% IIRC).

I think it is this latter approach that deserves some further thought. If we could work out a way to incentivize solo mining, and at the same time encourage more full nodes to exist, we'd see a much healthier network (as well as more secure, relatively speaking ofc).

I do believe that a 5% reward boost is too small of an incentive to pursue this approach sensibly, and would suggest something as high as 20%. My rationale is that: technically, solo-miners are usually at a disadvantage, because part of their mining resources are implicitly tied up with the business of running a full node (hence, some potential hashrate performance is lost). Additionally, external miners will usually perform best, seeing as they run code that is systematically being optimized for that function alone, and are less concerned with wide cross-platform support and code portability (compared to a full node).

Personally, I run a full node and I'm happy solo mining, even though I get a performance drop when compared to pool mining. Thanks to Smooth's recent updates, the performance drop is rather tiny (in the region of 5% or so), though my motivation is not so much an economical one, as it is of participating with a full node and contributing towards a healthy network.

Most miners are economically motivated, period. I think it would be nice to leverage on that motivation, and drive some of these miners towards a more meaningful contribution to the network (solo-mining, full node incentives). This ramble is just my collection of past ideas on this matter, and food for thought as much brighter minds are around