TD-Linux

This coin uses Stellar, which is not a decentralized consensus like Bitcoin, but rather federated. It's not really surprising that it has performance advantages.

Also not sure how I feel trusting the fate of a cryptocurrency to the strength of Intel's SGX.

I don't know what you mean by "prove". People have known about the block size limit for years. It's been increased, but most haven't updated their software to make use of it yet. Lightning now works on mainnet, but no one is using that either.

Maybe it's more proof that no one cares?

I really like Game Boy development - one nice thing is that its graphics hardware is more regular in comparison to e.g. the NES, and its sound hw is legendary. Also fun is the DS, which although being far newer still retains the tile-and-sprite graphics hardware. Flash cartridges are also plentiful.

It seems to be the season of homebrew - Tobu Tobu Girl is another Game Boy game on a physical cartridge to come out this month, with full source code (also using GBDK) http://tangramgames.dk/tobutobugirl/

Just knowing it's in your mempool isn't a very strong guarantee that the payment will go through. Probably fine for reversible digital goods, but not much else. Some systems pay miners to look at their block templates to get a better assurance it will confirm (and that it won't be replaced), but it's still not very good, and given that Lightning is now running on mainnet there's little value in continuing in that direction.

While it is true that Bitcoin transaction sizes* vary depending on the coins available in your wallet (vs Ethereum only depends on the account), most of the volatility is based on the pricing of gas or bytes, not coin selection.

Also, pertaining to the original article, it's unclear if either ring signatures or bullet proofs can be made to work with an account model. Is there any examples of this?

*Bitcoin now measures transactions in weight, not size, a similar concept to Ethereum's gas (though much simpler)

The screw mechanism they describe is quite a bit different than an injection molding screw. The screw in an injection molder is like an auger, designed to push plastic pellets. A hobbed bolt is not an option because it can't pick up the pellets. Here they are grabbing the filament from the outside with threads, kind of like rifling.

Reading the paper, it seems like they managed to double the force compared to a traditional pinchwheel. However, there are now extruders that used geared pinchwheels on both sides of the filament, doubling the force without requiring threading the filament.

It is Tensorflow based which has a C++ API. Though, it looks like they provide Rust bindings for the Deep Speech library itself.

In the Baidu Deep Speech 2 paper, the Baidu implementation is able to get 5.33%, and a human 5.83%. https://arxiv.org/pdf/1512.02595v1.pdf

They are listed as a contributor to the Common Voice dataset: https://medium.com/mozilla-open-innovation/sharing-our-commo...

I think their product is higher level - it has things like recognizing commands and sentence structures, and hotword detection.

No, but DRM is at the container level, so nothing prevents you from adding it.

They actually added Opus support for WebRTC, and more recently FLAC support in iOS 11.

Yet no one wants to use it because of the content fees.

Lots of Alliance companies also helped develop and have patents on H.265, it shouldn't be an obstacle to shipping AV1.

We already have an enscripten'd decoder, built into a nice analyzer tool that lets you inspect the AV1 bitstream! But you're right, it'll need SIMD to decode at high resolutions in realtime.

[1] https://0x0.st/tQ

That can sometimes happen if the CPU gets too far behind. There is a bunch of missing SIMD code at the moment - I'd expect it to be at least 4 times faster by the time it ships.

Nope, Ethereum fast sync has to trust that peers don't give it an invalid state (it checks that all it's peers have the same state, but that is much weaker protection). https://github.com/ethereum/go-ethereum/pull/1889

Yes, it is in the same way. In both cases you keep enough state to verify future transactions but not enough to rebuild up to the current state if it were to get corrupted. I don't see anything in your links that says otherwise.

These most recent vulnerabilities don't require AMT. I don't see any reports of me_cleaner being used on a Mac yet, but I'd assume they are running the same ME firmware as everything else unless there is evidence otherwise.

On newer Thinkpads, the firmware for the EC is on the same SPI Flash as the ME firmware, but on a different partition. The EC is an entirely separate chip (labeled ThinkEngine) and by virtue of being only on SMBus is a lot less dangerous.

This is backed up by older systems working fine with the ME firmware completely removed, and on newer systems, for 30 minutes before a watchdog triggers: https://github.com/corna/me_cleaner

One of the components (not yet finalized) of ATSC 3.0 is an entire web browser that runs as an overlay in front of the video [1]. Which itself supports LocalStorage, XHR, and all the goodies you've come to expect - and EME DRM, of course.

[1] http://www.atsc.org/wp-content/uploads/2016/12/A344S34-230r1...

It does. Here's example output from me_cleaner.py, which removes non-essential modules and allows you to reflash with modified firmware:

  rbe          (Huffman     , 0x007cc0 - 0x00a380): NOT removed, essential
  kernel       (Huffman     , 0x00a380 - 0x019f40): NOT removed, essential
  syslib       (Huffman     , 0x019f40 - 0x02cf40): NOT removed, essential
  bup          (Huffman     , 0x02cf40 - 0x055d40): NOT removed, essential
  pm           (Huffman     , 0x055d40 - 0x059740): removed
  vfs          (Huffman     , 0x059740 - 0x066880): removed
  evtdisp      (Huffman     , 0x066880 - 0x069300): removed
  loadmgr      (Huffman     , 0x069300 - 0x06dec0): removed
  busdrv       (Huffman     , 0x06dec0 - 0x071700): removed
  gpio         (Huffman     , 0x071700 - 0x0738c0): removed
  prtc         (Huffman     , 0x0738c0 - 0x074c00): removed
  policy       (Huffman     , 0x074c00 - 0x07fa40): removed
  crypto       (Huffman     , 0x07fa40 - 0x09a680): removed
  heci         (LZMA/uncomp., 0x09a680 - 0x09e580): removed
  storage      (Huffman     , 0x09e580 - 0x0a4b00): removed
  pmdrv        (Huffman     , 0x0a4b00 - 0x0a6700): removed
  maestro      (Huffman     , 0x0a6700 - 0x0ab600): removed
  fpf          (Huffman     , 0x0ab600 - 0x0add40): removed
  hci          (LZMA/uncomp., 0x0add40 - 0x0ae600): removed
  fwupdate     (LZMA/uncomp., 0x0ae600 - 0x0b3140): removed
  ptt          (LZMA/uncomp., 0x0b3140 - 0x0c82c0): removed
  touch_fw     (LZMA/uncomp., 0x0c82c0 - 0x133000): removed

Unfortunately we know little about these modules other than their name and size.

I have had pretty good luck running me_cleaner on various computers - the main difficulty is the hardware access to the SPI flash, but once you have that it's not too difficult, and low risk because you can always flash a backup of the original back on.

It is a bit unfortunate that all we can do is disable some modules or set the HAP bit without knowing exactly what has been neutralized, but it's certainly far better than the extremely limited control Intel provides the user over the ME.

It will be interesting to see if Intel tries to make this more difficult with future iterations (it will certainly be even more suspicious if they do).

Every Thinkpad I've run me_cleaner on so far has had the full suite of ME modules loaded.

Does it? To use the IOMMU for VFIO, I had to explicitly enable it via a kernel parameter.

The Bitfinex hack was due to getting enough parties of the multiparty signature to sign it (e.g. by stealing 2 out of 3 keys, or taking advantage of insufficiently secure automatic signing systems), not an issue with the contract itself.

This is effectively the announcement of discontinuation of software, and anything relating to that is usually signed. For example, Bitcoin Core release notes are signed when sent out via email, the binaries are reproducibly built and signed many times, and most git commits are signed by their author (and all merge commits are): https://github.com/bitcoin/bitcoin/commits/master

Jeff Garzik was the only author of btc1, the primary 2x implementation. For it to survive for any length of time, someone needs to step up and take over code maintainership.

One of the Ethereum founders (Gavin Wood) lost the proceeds from their recent ICO to this bug. So, very good friends?

>If they used a library instead of a contract, this wouldn't have been possible.

It's actually the opposite, using a library allowed this to break all the wallets using it. However, an Ethereum "library" isn't what you'd expect a software "library" to be - it's an executable contract that just is never supposed to be executed directly. But oops, nothing prevented that from happening.

The concept of everyone using a common, well-audited contract makes sense though. Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.

You can use Janus for this - it's a server daemon that you can blast plain RTP to, and it will relay it to all connected WebRTC clients.