Small pedantic point to add here, in that the question in the OP and the thread title are slightly different:

OP: What is the probability that 6 blocks will be found in 40 minutes? - Poisson distribution is appropriate because block discoveries are independent events.

Thread title: Re: What is the probability of a 40 min 6 block streak? - I assume the word streak here means chain? 6 independently discovered blocks do not necessarily form a block-chain of height 6 due to orphaned blocks.

So to answer the thread title: the probability of a 6 block chain in 40 minutes is slightly less than (1 - N[CDF[PoissonDistribution[4], 6]]) because one of those discovered blocks may become orphaned (due to block propagation speeds or other reasons).

Short answer: yes

Note that the link you give is for Gavin's private github account, not the official BIP repo.

Gavin's reply here: https://groups.google.com/forum/#!searchin/bitcoin-xt/bug/bitcoin-xt/T9Q_zIn3K9M/6MNfQayeDgAJ says that the BIP originally said "bits 1,2,3 and 14 set (0x20000007 in hex)." and that he'd change it to "bits 1, 2, 3 and 30 set (0x20000007 in hex)"

If I look at the official BIP here: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki, it hasn't been changed yet, but I assume it should now read "bits 1, 2, 3 and 30 set (0x20000007 in hex)".

Hi domob.

The lightning network is definitely a very cool idea and I'm really excited about watching it develop. On the other hand, reading the white paper makes my brain hurt. It's a very complex system and seems like overkill for a bunch of applications where a simple unidirectional payment channel would suffice.

At the moment payment channels seem more theoretical than practical. There are a few applications being built, but my feeling is that widespread adoption would be helped along by having a standard way to negotiate and open channels. Creating a very lightweight protocol with that goal - and only that goal - could be a step towards proving out payment channels (before lightning comes along and solves all our problems )

Has there been any consideration to a payments channel protocol - something like BIP70, but designed to signal and negotiate a new payment channel rather than single transactions?

Payment channels seem like a killer app for bitcoin - something that just hasn't been possible before a decentralised trustless currency existed. Most people on the forum probably understand the basic mechanics of setting up a payment channel (see Mike Hearn's original description at https://bitcoin.org/en/developer-guide#micropayment-channel or https://en.bitcoin.it/wiki/Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party if you're not familiar with the concept). There's really interesting work going on in payment channels, for example https://streamium.io/ and https://www.bitmesh.network/ , but as far as I can tell, there isn't a standard way for a service provider to signal to a client that they want to set up a payment channel and exchange the information required for that channel to be set up (eg bitcoin addresses, bond amount, nLockTime, payment frequency, payment amount). Would a standardised way to signal this be helpful for getting payment channel projects off the ground? Would it help streamium, for example, if wallets could natively understand payment channels and pay for streams?

I've been really interested in payment channels for a while, but this is my first post to bitcointalk. Apologies if this has already been covered before - I've had a search through the forums but couldn't find anyone else suggesting this as a way forward for payment channels. I've already spent a lot of time thinking about what a protocol should look like and will be happy to flesh out the details in the comments below, but wanted to gauge interest before writing everything up.