TD-Linux

Probably the worst outcome is easier 51% attacks: https://en.bitcoin.it/wiki/Majority_attack

Note that from this perspective, a mining pool is effectively a single miner - so a Serbian miner might not actually help, depending which pool it's attached to.

If a proof of work solution is economically valuable to solve, the hashrate will just increase to the point where it's just marginally profitable again.

No one has yet created a Proof of Stake system that offers the same guarantees that Proof of Work offers. In fact, there are arguments that it's not possible [1]

You can implement any feature you want in Bitcoin, but for a feature like this (hard fork), you need to convince all users to upgrade. I think it's really unlikely you could sell a switch that drastic in Bitcoin land, especially considering the current unknowns.

[1] https://download.wpsoftware.net/bitcoin/pos.pdf

One suggested way to use it is to basically make a "jet" for every existing Bitcoin Script [1]. Then you compose a script make exclusively of these jets and it's no worse than Bitcoin Script. Of course, I think that there's probably better solutions than that.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...

I don't know if ASN.1 is turing complete, but I don't think Simplicity can handle arbitrary depth recursion, either. Luckily, to parse a BER coded certificate, you only need a fixed depth.

Of course, if you are actually parsing BER in a smart contract, you should really reconsider what life choices brought you to this point :) But it might be useful for a non-blockchain related crypto library.

Oh, this requires server modifications too? I had thought it was only client-side.

If that's the case then it makes it especially useless for the smart contract oracle use case. If you're going to have to change the server anyway, you may as well make it offer very tiny signed messages instead. You could even use secp256k1 and make it directly compatible with Bitcoin.

On the wheel, it's unsprung mass. That extra mass hurts the ability to the wheel & suspension to quickly respond to bumps, and causes energy to be lost into the suspension and tire.

It's even a problem on trains - early electric trains had connecting rods between the motors and wheels just like steam trains. Later ones have the motors in the bogeys, but the motors are sprung and can swivel on the same axis as the drive gear.

It also requires the motors to be larger because motor size mostly corresponds with torque output, not power output, and there is no gear reduction.

However, it also avoids a lot of weight due to the lack of gearbox and axles, and efficiency losses in the gears. It can make sense especially in applications that require lower power output - for example virtually all solar cars use hub motors for efficiency.

So, this basically has two parts as far as I can tell:

1. "signing" the contents of a TLS session (proving that they happened)

2. putting this on the blockchain

I can kind of see the utility of (1), but why (2)?

In fact, in Firefox it works without creating the extension.

In the case with audio, it might be the opposite - even with a modern audio codec like Opus, an Apple CPU can decode an entire song into RAM in a fraction of a second. At that point, the CPU has to wake up anyway to download another song from Spotify or read one from disk.

Indeed, several good examples of these DSPs are the Qualcomm Hexagon and the VideoCore IV, the latter of which has a 64x64 register bank, and is largely reverse engineered so you can actually figure out how it works [1]. They are really good for highly serial per-block operations, such as video encoding and decoding. They would also work OK for stuff like large convolutions, which is what I kind of imagine the IPUs are for, but not really significantly better than a GPU (the low serial latency is wasted).

I did find the original source to the Ars article [2] and it says that each IPU core has 512 ALUs. This seems more like a extremely wide GPU than the VPU. It also seems to be programmable in Halide [3], which presents a more "SIMT"-like interface, just like a GPU shader. It probably lacks the super fast bilinear texture mapping units that a GPU has, but otherwise seems very similar. It'd be interesting to know if the texture/pixel cache is handled automatically, or manually with a large register file like the VPU.

The article also features this quote, which also seems to back Google being unsatisfied with only high level access to the GPU:

>A key ingredient to the IPU’s efficiency is the tight coupling of hardware and software—our software controls many more details of the hardware than in a typical processor.

It would be really awesome if they opened this chip up to third party developers. Unfortunately the press release only mentions availability in the Camera API so far, relegating it to the same opaque blob status as all the other dedicated image processors :(

[1] https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...

[2] https://blog.google/products/pixel/pixel-visual-core-image-p...

[3] http://halide-lang.org/

I'm a little bit confused too - all the operations they describe are usually quite fast on a GPU.

I wonder if it's not so much about being better at image processing, but having control and direct access to the hardware. For the Adreno, you have to go through Qualcomm's drivers and are subject to their limitations (there is freedreno which works great, but I don't think Qualcomm allows it on handsets). You're also stuck with the sizes of GPU that are available on Snapdragon SoCs - if you want a larger one, too bad.

The fan's frame is plenty strong to hold it up. The only issue I see is that a baffle or case would better direct the air, allowing a lower speed fan. However, the amount of air movement required here is exceedingly small already, as can be seen by their fanless heatsink already meeting the 85C requirement.

STUN allows all sorts of hole-punching for cases where both peers are behind NATs. For cases where the hole-punching doesn't work (a user behind two NATs might be one case), you can use TURN which is a dumb UDP or TCP relay.

That's probably a bad idea - miners target profits. There was a lot of oscillation in hashrate when BCH split - and it had a lot less support. It briefly exceeded Bitcoin's hashrate. http://fork.lol/pow/hashrate

You could do this with Bitcoin too. You would just send Bitcoin to an address, with an OP_RETURN with the coordinates and a hash of the pixel values you put there. Only the first one would "win". The Ethereum contract does have the feature that you effectively get your money back if you're not first - a transaction that tries to take already-taken pixels is invalid. You could implement this today on Bitcoin with HTLCs and zk-SNARKs, but there might be a simpler solution that I'm not immediately thinking of.

Arduino sketches don't have a "project file" to list which .c files to compile, so instead you just include all the code into one compilation unit. This works fine as most projects don't take long to compile anyway.

Thanks for this! Rikaisama had already sort of broken with e10s, and I had considered trying to port the Chrome version, but this is far better!

There's work to use Gnome client-side decorations for the title bar here, which should help with screen real estate: https://bugzilla.mozilla.org/show_bug.cgi?id=1283299

It probably won't land in time for 57, but hopefully soon!

See this post implementing it in ffmpeg: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215003...

>both pools! there are two!

There's actually three now, but the newest one hasn't announced their pricing yet: http://velosmedia.com/

I suspect the 360 controller being available in a wired-only version is a factor (also as to why 360 and not One)

Congestion control is required to be enforced at the browser level as an anti-DoS measure. You could just have the browser API limited to 15kbps, but that seems like a silly limitation when the way around it has already been implemented...

While it sort of looks like that, I don't know of any non-software implementations of the API (they use some SIMD at most). The problem is that 48,000 samples per second really isn't that much, even with very complex processing. When you compare it to a 1080p screen which has to process at least 373,248,000 samples per second, it hardly seems worth it to even spin up a shader.

I notice it too, and it's because the music is extremely low bitrate - usually 48kbps, but sometimes as low as 32. It's HE-AACv2 - not as good as Opus, but close. Its characteristic artifacts include destroying transients, like your hi-hats.

There is no reason the DAC or ADC can't internally do the resampling itself. In fact, most take it to the extreme - they resample to several MHz, but at 1 bit per sample, with noise shaped dithering as explained in the video linked elsewhere. They then have a very simple analog low pass filter - the noise is shaped far into the stop band of the filter.

That is no reason to store or even process your music at higher rates, though.

At least the good thing is you can run the same benchmark locally and figure out what went wrong. Anandtech posted similarly wonky results for Chromium compiles on Threadripper, but that one isn't reproducible.

The Overdrive 1000 (with an AMD A1100) has this. You can boot Linux off CD or USB and just install it. It's pretty magical.

No, it's still more profitable to mine BCH even considering the transaction fees, see the home page of fork.lol: http://fork.lol/

The graph you linked is not considering block difficulty.