TD-Linux

Note that base58 for addresses was generally considered a mistake - there's a replacement for Bitcoin proposed here: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi...

Even disregarding any flaws, I'd still consider it a blockchain - just one where each block only holds a single transaction.

It wouldn't, though a lot of the initial "Web 3.0" hype seemed to imply that, such as this post by a cofounder [1]. Even their website used to mention Facebook [2].

[1] https://web.archive.org/web/20140723210829/http://insightsin...

[2] https://web.archive.org/web/20140801161657/https://www.ether...

Even if you hand-roll a transaction, when you try to send it, Bitcoin Core will parse it and refuse to send it if the fees are too high:

https://github.com/bitcoin/bitcoin/pull/2949

That information is out of date - in particular, "priority" is long gone. Nowadays most miners (and Bitcoin Core) maximize for highest fee profits - basically select transactions highest fee/kb first.

It seems that this operates on the same principle as The Thing: https://en.wikipedia.org/wiki/The_Thing_(listening_device)

Several devices in the ANT catalog also rely on radio reflection, for example this video transmitter: https://en.wikipedia.org/wiki/NSA_ANT_catalog#/media/File:NS...

I think that's why TFA suggested only doing this in CI (with a known compiler version) and not for local builds.

Yes, the third citation is a transcript of his talk in the Future of Bitcoin conference. For those curious, you can also watch it on Youtube [1] (warning: maximum cringe).

He mentions the PGP key, but only connects it to the Australian Tax Office (which he defrauded, and is now living in the UK). I'm not sure how that's supposed to change my conclusion.

[1] https://www.youtube.com/watch?v=YAcOnvOVquo&feature=youtu.be...

If you have such a copy of the SGI endorsement letter, why don't you post it? I don't think a press release written by Craig Wright is particularly compelling evidence.

That said, I don't actually doubt that the SGI letter exists, but also believe it was totally fabricated by Craig Wright.

CoinGeek is either run by or paid for by Craig Wright. You can see that all of the articles are either strongly in his favor or in line with his recent opinions [1].

Craig Wright is a known fraud and scammer, who claims to be Satoshi. He not only failed to prove it, but created a clearly fabricated PGP key to do so [2]. He has recently threatened to sue anyone who questions his claims [3]. Stay far, far away.

[1] https://coingeek.com/author/eliafram/

[2] https://motherboard.vice.com/en_us/article/jpgq3y/satoshis-p...

[3] https://gist.github.com/harding/b7067d2943706e2e3d3f7aab539a...

The linear motor is confined to the rails behind the cabin. It's basically a bigger version of the linear motors seen on some CNC equipment.

Opus does something similar in the frequency domain, but much simpler. It just copies codewords (minus energy) from lower bands to higher bands. It also lets you signal the energy of the copied bands (something you wouldn't have access to if reconstructing blindly).

See "band folding" here: https://people.xiph.org/~xiphmont/demo/celt/demo.html

Yeah, it's a neat motor design, but it doesn't support the headline - 6% greater power to weight of the motor.

How is the coin value jumpstarted, then? Who do the scientists sell the tokens to for real money?

This has been tried - the problem is that FLAC works by removing redundancies and correlation in the audio signal. When you subtract an Opus encoding from the original, the resulting difference file is the difference, which is much less correlated noise - often it actually compresses worse than the original FLAC. WavPack gets around this by making its lossy format a subset of the lossless data, but as a downside the lossy compression is far worse - about 3x worse than Opus.

Other attempts include Dolby TrueHD and DTS HD - but both of those ended up larger than just separate FLAC and Opus files.

The AOM patent license covers any implementation of the format. It additionally covers the reference implementation, because the encoder may use techniques that aren't part of the bitstream format, and it's important to grant rights to those too.

http://aomedia.org/license/patent/

Not exactly the same situation as Ubuntu - the MP3 decoding checkbox downloaded Fluendo's decoder, which was actually properly licensed. But otherwise you're correct (FYI, there are EU and JP patents too).

>To date all major tokens have either a fixed amount of tokens right away or eventually (e.g., BTC) or a rate of inflation that asymptotically goes to zero (e.g., ETH).

These are both incorrect. BTC has inflation that asymptotically goes to zero. ETH has undefined inflation (the current codebase has constant inflation, but has a "difficulty bomb" that is supposed to force a hard fork that will presumably change the inflation).

EDIT: I think I read the OP incorrectly, I think what they meant was that while the rate of coin issuance in ETH is fixed, the inflation as a % goes to zero, and that due to quantization BTC issuance actually hits zero.

If you come up with a patentable idea, you can specify its implementation in either hardware or software in the patent (or just be ambiguous). However, if your idea alone is unpatentable, you can't add "implement it in software" to make it patentable, according to Alice vs CLS. Basically, Alice vs CLS removes a certain class of software patents, but certainly not all.

Yes, any software patent is possible by describing it as running on a processor. See for example [1], which has the very common claim prefix of "A machine readable storage medium storing a computer program..." Alice doesn't invalidate these patents unless, by removing that text, the remainder of the claim is unpatentable.

Because software patents are still legal, there's no need to attempt to describe them as running on a custom hardware device - you just specify them as software. Specifying custom hardware would unnecessarily reduce the scope of your claim.

[1] https://www.google.com/patents/US6126544

Nope, an abstract idea has always been invalid. Alice vs CLS Bank found that "on a computer" wasn't a sufficient inventive step to transform an abstract idea into something patentable [1]. This can be used to invalidate a claim, but won't shrink the scope of a claim to hardware only (as then, if software was the only inventive step, it would be a pure abstract idea).

The USPTO certainly seems to think an ISA is patentable, and I haven't seen a court disagree yet.

[1] https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern...

Yeah, it'll depend on your jury whether they consider an emulated register to still be a register as described. However, what's super common in these sort of patents is to duplicate the same claim language several times with slight variations to cover all implementation types. If you look at claim 9, it gives a much more broad heading:

"A computer system coupled to receive and respond to computer instructions from a program routine comprising"

In later patents, they got even more clever and just say a "method" rather than a "processor", and explicitly define registers as potentially being emulated in the description (search AVX2 patents if you're curious)

Patents are entirely unlike copyright in this, in that you can come up with a totally independent implementation, and still infringe the patent. The patents are very similar to audio or video codec patents - for example, they patent the process of executing a particular instruction.

For example, here's Intel's (expired) patent on the CPUID instruction:

https://patents.google.com/patent/US5671435A

It claims the particular encoding of the return data. Good luck implementing CPUID in an emulator without infringing.

It's actually a pretty nice value add - you don't have to pay transaction fees, nor wait for confirmations. Of course, this assumes the implementation is competent, which seems to be under question in this case.

Why is that bad practice? Creating a duplicate transaction only doubles your transaction fees.

Cisco provides a fully licensed encoder, OpenH264, that you can download for free (Firefox uses it). That loophole was removed for H.265, though. I would have rather had only VP8 mandatory to implement in the standard, but at least this situation is better than the reverse.

WebRTC has codec negotiation, which means you can give preference to a particular codec while still supporting both.

It does support Opus for audio! No VP8 yet, but halfway there.

It guarantees UDP for all of the cases when UDP would work. You can choose to not use TCP if you like, though I think most games would actually desire a TCP fallback.

You can also fall over to a classic client/server model with WebRTC for one to many broadcasting, while still keeping the advantages of very low latency (and reusing much of the same code).

Plan B is pretty disappointing, Chrome compatibility winning over standards compliance :(