Greg Maxwell

Two confirmations is fine for this use case.

Normal chain reorganizations of length two are rare (4 observed in a 2 year period [1]), and since miners mostly select transactions for inclusion in a block based only on price, blocks on both side of the fork normally contain the same set of transactions.

It is of course possible for some motivated attacker to force a reorg and double spend some Bitcoin.

Since Nakamoto consensus is probabilistic, it is possible to force a reorg with significantly less than 51% of the total hashpower in the network. For example, an attacker with 20% of the hashpower has a 22% chance of causing a reorg after 2 blocks and an attacker with 51% of the hashrate has a 98% chance of causing a reorg after 2 blocks [2]

The commonly cited 6 block wait time was chosen as after this time the probability of an attacker with 10% of the hash power being able to force a reorg is below 0.001 [2].

Only ~0.05% of the hashpower in the Bitcoin network is available to rent on the open market[3], meaning that it is extremely cost and labor intensive to attain the required computational resources (even 20% of the hashpower would require being able to direct the hashpower of ~733,000 Bitmain's newest miner [4]).

However it is safe to assume that organisations with control of sufficient computational power exist (Bitmain, operators of large mining pools), and it seems quite credible to believe that multiple large mining farms would collude if forcing a reorg would…

This is inherent. A code can only unambiguously correct errors at half the distance of the code.

Visualize a lattice of possible input words: https://people.xiph.org/~greg/temp/lattice.png lets say that we are using a code where the valid codewords (dark dots) are at least 4 moves apart. If you use this code for error correction, you'll take a received word and move to the nearest codeword, but this is only unambiguous if you correct errors at up to half the distance between any two words.

RS codes are optimal in that they achieve the best possible distance for their size (they are MDS codes).

They may not be what you want to use in some applications because of the computational complexity of decoding with errors, or because the application can make use of list decoding which can be more efficiently achieved with other codes, or because they need different sizes in particular, the symbol size constraint with RS is burdensome for many applications.

The symbol size issue is a particular driver for other choices. Say your HDD codes data with 4-bit symbols but to get good performance you want a code that is a whole sector wide. If you use a 10 bit RS code to code in blocks of 10240 bits, then a single 4-bit symbol error potentially corrupts 20 bits of input.

Codes with large input symbols also don't lend themselves well to soft-input. (because instead of propagating around a single 1 or 0 probability you need to propagate around a probability distribution function…

Oddly enough, the website brainwallet.org which is used to create most brainwallets seems to be in itself malicious. nullc on reddit makes an interesting comment about it.

 > "Yes, the creator of Brainwallet.org got his start with password based private keys by cracking them. Here is an old IRC log extract I pulled out for someone else who didn't believe this: https://people.xiph.org/~greg/brainwallet.txt*

  More recently he really was in IRC asking for information on faster cracking mechanisms, right after whining about needing money. But uh, he might have just been trying to further convince himself that brainwallets really are secure and that it's really the users fault (or a MITM on the site) when they get robbed.

  I'm less inclined to assume malice, and more inclined to assume that he's clueless— both of the insecurity of these schemes, the acceptability of blaming the victims when users inevitably choose poor keys, and how scammy his own actions look. But thats just my own impression.

  When you choose to use something like that you should start with the assumption that the creator is malicious and ask yourself why its safe to use anyways. For the Bitcoin reference software you can point to the large amount of open public review, processes which prove the binaries agree with the source, etc. For brainwallet.org? Not much.

  So if ever you find the prospect that the creator of something might be a bit black-hat and this concerns you thats potentially a…

Amazing; the very first sentence in the article is factually incorrect:

Pundits are roasting Apple over a scuffle raised by Mozilla and Opera to define the free Ogg Theora video codec as the official way to present video on the web in the new HTML 5 specification.

There was never any attempt to define Theora as the "official way to present video". It was merely provided as a baseline, a lowest-common-denominator format that could be relied upon by content providers.

Ogg Theora is based upon VP3 video technology originally proprietary to On2, and subsequently abandoned after it became obsolete.

Theora is not obsolete; it is superior to most popular codecs, such as XVid, WMV, and QuickTime. In standard-definition encoding, it's even superior to modern proprietary codecs such as H.264:

http://people.xiph.org/~greg/video/ytcompare/comparison.html

http://people.xiph.org/~maikmerten/youtube/

Apple has also voiced concerns that Ogg Theora may be encumbered by unknown patents. That risk isn't significant to Mozilla and Opera, both of whom could simply abandon the format for something else [...] Apple also has a bankroll to attract patent trolls that Mozilla and Opera both lack.

This hand-waving ignores that Google will also be supporting Theora, and undoubtedly has deeper pockets than Apple. Besides, a risk of unknown patents applies to any video codec. There's no technical or legal reason to exclude Theora support.

It is a traditional view that in order to increase throughput we need to increase the bandwidth. This is true but we also know that throughput can be increased by abstracting the existing bandwidth to hold more information.

Increasing the blocksize will increase throughput, but is it the only way? Definitely not. The very recently improvement by Dr.Peter Wuille to segregate the witness (cryptography used to validate transactions) from the data (transactions) increases the capacity by around 66%, even if block's max size is unchanged. This is already in the testing phase. There is a whole bitcoin scaling roadmap & a lot of work going on.[0]

Practically, the death scenario being painted by XT hasn't realised and transactions are still going through normally.[1]

The bitcoin developer community comprises of very capable hackers many of whom are not only PHDs but have also invented new cryptographic techniques and also are robust security coders.[2][3]

[0]https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
[1]http://statoshi.info/dashboard/db/transactions?panelId=4&fullscreen&from=1435768112971&to=1452875394268
[2]https://people.xiph.org/~greg/confidential_values.txt
[3]https://blockstream.com/2015/08/24/treesignatures/

> See the multiple charts at http://opus-codec.org/comparison/, for one presumably-unbiased source.

Further nitpick: the page is very misleading. Audio compression has different targets, a crucial one being music.

The Opus official page has comparatively little test references for music, both of which are at 64/96kbps for AAC [1-4], which is significantly below the general audience listening standards (160+ kpbs).

This implies that the red line on the top right of the first diagram is literally made up.

Until further blind listening tests are performed, generic conclusions such as "Opus outpeforms the competition" are unfounded.

> It attempts to summarize results [...] and (when no data exists) show anecdotal evidence

This is borderline offensive for people who are serious about researching music quality. Any anectodal evidence [in this field] is garbage.

[1] http://listening-tests.hydrogenaud.io/igorc/results.html
[2] https://people.xiph.org/~greg/opus/ha2011/
[3] http://listening-test.coresv.net/results.htm
[4] http://opus-codec.org/static/comparison/GoogleTest1.pdf