TD-Linux

The patent describes not just "slotting in", but one way in particular. Note that if you were to "slot in" ANS into the current AV1 codebase, for example, it wouldn't actually read on this patent because AV1 codes its coefficients differently.

Unfortunately, that's not the case, at least as the patent office currently sees things. There's thousands of patents for H.264 and HEVC that amount to "code a certain bitstream symbol with CABAC this certain way".

Better links are the Blockstream press release: https://blockstream.com/2017/08/15/announcing-blockstream-sa...

And the website: https://blockstream.com/satellite/

I think you have never had a proper midwestern bag of frozen mixed vegetables, boiled or microwaved to squishy tenderness.

The issue without "Direct Mode" is latency, as your link says. You need to bypass both the browser compositor and the system compositor. On Linux, most compositors will implement something like Direct Mode (compositor bypass) when you go fullscreen, but it's a bit hit and miss with multimonitor setups. It might fly as a stopgap, though. Here's the tracking bug for WebVR on Linux, if you want to follow progress: https://bugzilla.mozilla.org/show_bug.cgi?id=1310655

Something more directly analogous to "Direct Mode" on Windows are DRM leases, which give direct control over the scanout, rather than simply bypassing the compositor. This isn't possible on Linux at all yet, but Valve is working on it: https://keithp.com/blogs/DRM-lease/

Is the orbx format specification public? I can't seem to find it.

They are just trading their internal accounting of BCH, by crediting BTC holders with BCH. Nothing is hitting the blockchain.

Bitfinex did this too, but royally screwed up: http://hackingdistributed.com/2017/07/29/bitcoin-impending-a...

It's super unprofitable to mine BCH right now, at current exchange rates (assuming you could even sell BCH, which you can't). Miners stopped to wait for it to become profitable again, due to BCH's special difficulty adjustment. Details: https://medium.com/@jimmysong/bitcoin-cash-difficulty-adjust...

In fact, Bitcoin Cash does have modified retargeting that drops difficulty much faster. (they could just have well dropped difficulty by 100 times at the fork, as well)

I suspect that many people are sending their balances to a new address, so that they can import their old keys into a Bitcoin Cash client.

Luckily they last-minute added replay protection so that transactions are chain-specific, making the situation far better. I've not reviewed their solution for correctness, but others seem content with it.

[1] https://www.bitcoincash.org/replay

Electrum themselves recommend moving your coins to a different set of private keys before importing the old set into that client, though: https://electrum.org/bcc.txt

He's probably referring to this handy chart of Bitcoin Core developer support of current hard and soft forks: https://en.bitcoin.it/wiki/Segwit_support

However, I think it's incorrect to say most developers disagree with increasing the block size or a hard fork. Segwit increases the block size, as do hard forks proposed by some Bitcoin Core developers like Spoonnet [1]. There is just a general dislike towards the existing technical proposals.

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

Correct, though this isn't really anything special about SegWit. If BCC had forked right before Bitcoin added P2SH for example, the same would have resulted from P2SH transactions.

Actually, since BCC is a hardfork, they can make the Bitcoin Cash spending rules whatever they want. They could have made SegWit transactions totally unspendable if they wanted. They could have made all Bitcoin Cash corresponding to the Bitcoins sent to Blockstream spendable by anyone, etc.

Not quite, it needs 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes. That's the reason BIP9 has a 95% activation threshold.

Note this is by far not the first soft fork Bitcoin has done. P2SH, CSV, and CLTV for example were also soft forked in. The original design even included 10 blank opcodes designed for soft forking in features.

I think they also may be referring to some Bitcoin Core authors recommending against other implementations - the concern is if the implementations contain an error in the consensus code, they could accidentally fork off, and potentially lose funds for the user. For similar reasons, Bitcoin Core builds reproducible static builds and recommends those, the minimize the chance of behavior divergence.

But you're right - it's merely a suggestion from a portion of the developers, and it certainly doesn't stop anyone.

>It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?

Segwit, which activates on Bitcoin soon, already increases the the block size to ~2MB. Because Bitcoin Cash doesn't implement Segwit, increasing to merely the same size as Bitcoin wouldn't have been compelling.

It's definitely a concern! WebRTC solves this in two different ways:

1. The receiving end must consent to receiving packets by completing the DTLS handshake required by WebRTC.

2. The browser enforces SCTP congestion control to avoid spamming large numbers of UDP packets. Basically, it'll start throttling you when it detects packet loss.

>Fist of all it is not designed for server-client cases.

WebRTC is specifically designed for server-client cases. In the case of video and audio, the server is called a "mixer" or MCU. This is extremely important for large multi-user conferences - if it weren't for a mixer, you'd have to upload your video once for every user, burning all of your upload bandwidth. Examples of services using this are Appear.in Premium and Cisco Spark.

Note that games are the #1 use case mentioned in the Datachannel draft [1]. It's perfectly fine to argue that the standard is bad, but it was designed for these use cases.

The Google developer you linked seems to be arguing for improving the WebRTC C++ library, not changing the protocol.

[1] https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-1...

I think you checked too long ago. Appear.in, Jitsi, Discord, and Cisco Spark are all working with WebRTC now.

Well, the problem is that I currently think WebRTC 1.0 is sufficient. For the example I gave, I think a simple JS library to write out the SDP is a perfectly fine solution. So I'm more asking, what did you find wrong with WebRTC?

I think you're going to need a stronger argument for "Why not WebRTC", or at least concrete proposals about what parts of the API you would change. For example, "SDP parsing is too complex, have a JS API to set up a client-server connection without a SDP".

IMO the most complex parts of WebRTC are the SRTP-DTLS encryption (except you also specified TLS as a requirement for Web UDP), and STUN/TURN (which are optional and not required for client-server).

It sounds like you're describing HumbleNet: https://github.com/HumbleNet/HumbleNet

That's just IETF terminology. Number assignment is one of the last things to happen - so if it has a number, it's done.

You can already play Wikipedia's audio files on Edge or Safari. Try it here:

https://en.wikipedia.org/wiki/File:The_Adventure_Lights.ogg

Spoiler: it's ogv.js.

Luckily, those mostly slot in at clean locations in the presentation: amdgpu replaces radeon, vulkan replaces the bottom half of mesa.

I noticed this project is missing quite a few features common to modern image codecs, such as variable transform sizes, deblocking, or intra prediction. Of course, it's a work in progress, so those things could still be to come.

Have you considered using Daala's lapped transforms? They work with variable block sizes and are quite effective for still images.

Also, was there anything that motivated doing a custom image format rather than applying Butteraugli to WebP?

There's a huge marketing push at the moment for this fork as well on one of the Bitcoin subreddits. I suspect it's being pushed by ViaBTC, which just launched "futures trading" for it (as well as probably being the only miner), and has a lot of $ to gain by people trading on their service.

EDIT: yeah, totally organic growth I'm sure https://screenshots.firefox.com/1Jd3clym3pT37nAH/www.reddit....

For those unaware, "Bitcoin Cash" is a proposed future fork of Bitcoin. The primary miner supporting it also runs an exchange, so what they are effectively trading is "future promised coins" once they start actually mining the fork.

Because so few of % of the total coins are tradeable, I think this results in a similarly volatile "market cap" as many ICOs.

I think the reason the design is this way is because it was really convenient to get the ASN.1 format out of OpenSSL for the first implementation. If the protocol was designed today, there would be no ASN.1 involved at all. (see other comments for the problems associated with ASN.1 parsing)