Mike's work on bitcoinj enabled most mobile wallets and by that a big part of mainstream adoption.
His lighthouse project is one of the finest demonstrations of what Bitcoin, as is, is capable of.

His view might be too pessimistic, but community lost a good engineer.

A copy of wallet.dat contains all information you need to spend or transfer your coins at any later date (except the scenario described by teukon).

I would however advise against long term storage using wallet.dat for practical reasons:

Chances are rather good that in a few years
a) a current Bitcoin Core will not even have a wallet, therefore unable to import wallet.dat
b) your old Bitcoin Core might not be able to join the network, e.g. because current nodes use a different chain download protocol and you can't find old nodes.
c) your old Bitcoin Core might create transactions that are no longer forwarded/accepted by the network because they violate some later introduced soft-fork rule
d) your choice of new wallet might not be able to import wallet.dat

There are developments in Core that support assumptions a-c and d is probable because all modern wallets use HD key generation instead of a random key chain, that is wallet.dat.

I suggest you move your coins to a more modern wallet, e.g. the TREZOR and store its recovery seed in your long term store. Also assume that you may need to move on again later.

It is a bit like converting your videos to a newer codec. Ignore the development and will become a pain, but will work with sufficient expertise.

I have not claimed it should not happen, but that the event is less likely than temporary technical problems.
I also presented a model for the appropriate trigger levels of investigation, since a pool operator who has to explain production outcome to investors needs a model more precise than ..... your dribble.

Yes it is 1/2500, that means it is expected once in 7 years within the continous operation of a pool of that size.

No, it is not linked with lifetime of the universe or with *any block*.

That gap was confirmed by slush, it is not a problem on his website.

This was an improbable event, lets not argue about the adjectives.

What I claim is:
The assumption it was linked to e.g. a technical problem, a withholding attack etc. is much stronger than that it was bad luck.
Because having e.g. technical problems more often than once in 7 years is quite feasible.

It was also disappointing if the discussion of this topic was about adjectives and Slush' operation and not about using
more advanced metrics for pool audit.

I used the above probability metrics while running the mining operation of CoinTerra, (was 3-5% of the total network in 2014)
and they were helpful to define error levels where an investigation of infrastructure was triggered.

The below graph shows the alert levels we used. The trigger was no block for n hours (y axis) with a maret share as of x axis.

The lines are:
- blue (watch) : check systems
- red (alert): elevated manual checks
- yellow (panic): search for a problem until you find it (You see that slush' example is deep in that range)

One might set different levels but the shapes should be ike this. We applied the model overall and on data centre level.


 

We know that the expected production of a mining pool is linearly proportional to its market share (x%), it is 24*6*x% blocks per day.
 
The actual production however follows the Possion distribution for reasons you find in the first paragraph of https://en.wikipedia.org/wiki/Poisson_distribution
 
"... the Poisson distribution ... expresses the probability of a given number of  events occurring in a fixed interval of time and/or space if these events occur with a known average rate and independently of the time since the last event."

The probability of not finding a block within a time span in which one would expect n blocks is simply e^-n
Remark: This is the CDF with i = 0 and lambda = n

This means one can assign probability to an observed production outcome and quantify how likely is it.
A probability measure is more informative than "luck" used on many sites and you only need a pocket calculator for the check.

Historic Example:

Slush did not mine a single block for two consecutive days between 19 and 21. Jun 2015 while reporting 9.516 PH/s miner at pool.
see https://mining.bitcoin.cz/stats/blocks

The difficulty implied a network total in the same period was 355.711 PH/s, see https://bitcoinwisdom.com/bitcoin/difficulty
This translates to a historical market share of 2.68%

With that market share one would have expected 2*24*6*0.0268 (means nearly 8 ) blocks in two days.

How probable was not having any blocks in the same time just bad luck? 

Exp[-2*24*6*0.0268] = 0.04%

for me that falls into the practically impossible bucket.

I think a more interesting question is, how big is the probability of not finding a block within time period in a mining pool of x% market share.

Knowing this enables you to audit pools.

Example:

Slush could not to mine a single block for more than 2 days between 19 and 21. Jun 2015, see
https://mining.bitcoin.cz/stats/blocks/?page=23

Slush' market share was 2.2% around that time, see http://organofcorti.blogspot.hu/2015/06/june-14th-2015-block-maker-statistics.html

Such a bad luck has a probability of only 0.17%

The probability of 5 or more blocks within the next 40 minutes is 1 - N[CDF[PoissonDistribution[4], 4]] = 37%, I made a correction in my first reply, see striketrhough.

Since events are independent, it does not matter if you are just after a block or not.

Probability of 5 or more blocks includes probabilty of 5, probability of 6 ....

The way you deal with this is using cummulative probability function as I enumerated in the previous post. Using that table you can compute the probability of any block number range withing 3 hours.

Examples:

The probability of less or equal 15 blocks is 28.6 %
The probability of more than 20 blocks in 3 hours is 1-0.73072 = 26.9%
The probability of 16-20 blocks is 0.73072 - 0.286653 = 44.4%

here you are:

1. probability of exactly n block within 3 hours:



2. cummulative numeric, that is probability to have <= n blocks within 3 hours:

Yes, as you see on the plot I added in parallel to my first reply,  the probability of 5 blocks within next 40 mins is 15%.

In probability theory and statistics, the Poisson distribution (French pronunciation [pwasɔ̃]; in English usually /ˈpwɑːsɒn/), named after French mathematician Siméon Denis Poisson, is a discrete probability distribution that expresses the probability of a given number of events occurring in a fixed interval of time and/or space if these events occur with a known average rate and independently of the time since the last event.

From: https://en.wikipedia.org/wiki/Poisson_distribution

Mathematica says that: N[PDF[PoissonDistribution[4], 6]] is 10.4 % that is the prpbability of exactly 6 blocks per 40 min.
The probability of 6 or more blocks in 40 minutes is: 1 - N[CDF[PoissonDistribution[4], 6]] or 11%  1 - N[CDF[PoissonDistribution[4], 5]] or 21%

Below the plot of probabilty of n blocks per 40 min:

If that is the idea, it does not work for reasons:
- further spend attempts will not be broadcasted by a node after one of the attempts is included into the mempool
- people will figure soon that miner have advantage grabbing the outputs and stop trying.

Therefore the attack, if that is the purpose, is pretty lame.

What is the purpose of creating tons of trivially redeemable outputs?
 
See:
https://blockchain.info/address/162TRPRZvdgLVNksMoMyGJsYBfYtB4Q8tM

Anyone could claim the 0.04 BTC there (at the moment) with a key derivable as SHA256("cat").
Rational miner will claim them for themselves, that however leads to a block stuffed with a big transaction like:
https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
since the 0.04 is distributed to hundreds of outputs.

The redemption attempts of non-miner will be included into the mempool by nodes in some non-conflicting combination until they are purged as doublespend.

Is this a troll, a DoS, trying to prove some point or engineered to drive up fees?

Bits of Proof has no access to the servers of myTREZOR.

Bits of Proof wrote the software behind myTREZOR. It was a more than year ahead of alternate solutions, enabled the TREZOR product offer in the first place and has been serving thousands of customer daily since then.

The software was delivered in source code to Satoshilabs, was compiled and deployed by Satoshilabs. There were a few source code patches delivered and applied to the orginal code base, last in February this year. They were again applied and deployed by Satoshilabs.

I offered them a patch a few weeks ago for a marginal issue, they did not even reply to that message. I have no Idea if they used it.

Here is a fragment that works for me. Not complete but you get the idea how to deal with ipv4 or 6.

It is used to connect you, assuming your node was accepting incoming connections. If so, you should indicate in the service bits.

Actually the generation of the word lists from a given entropy does not increase it, if the dictionary is known and fixed,  just like hashing does not.
Therefore the key set is size is determined by the entropy generator. I was overestimating the entropy using the stats of the language.

Yes, the user would be a worse source of entropy if he was to chose the words directly.
My point is, that if you are able to encode entropy into 12 words then it can not be more than entropy represented by 12 words, no matter of its source.

You are right, that there are options generating a longer list, but I think default is 12 in popular wallets.

ok here in detail how and why it works:

1. payer and payee agree on a 2-of-2 address and own addresses
2. payer crafts a bond transaction that deposits X to the common address, but sends only the hash (outpoint) of it to payee. payer does not yet broadcast it, hence no risk to him.
3. payee crafts and signs a refund transaction that spends the outpoint back to payee time locked, such that it can not be included into the block chain until that time point. Payee can safely sign since if he does not own any coin with the outpoint.
4. payer verifies that the refund transaction if counter-signed and broadcasted by him would return the bond to him and if so broadcasts the bond transaction. He can safely do so, since if payee would not proceed, but he could get his money back on his own after the timeout.
5. now payer wanst to use some service of payee and crafts and signs a settlement transaction spending the same outpoint that pays him X-delta and delta to payee. The transaction is not yet valid since it needs payee's signature, hence payer can not broadcast it. Payer sends it to Payee.
6. Payee verifies that the settlement transaction has valid signature of payer and that it gives him enough to offer the service. Payee could countersign and broadcast the settlement transaction thereby closing the channel and also invalidating (double spending) the refund transaction.
7. Payer keeps sending new versions of the settlement transaction with increasing deltas while using the service. If delta does not increase sufficiently Payee closes the channel.
8. At close of the channel Payee will counter-sign and broadcast latest version, since that is most favorable to him.
9. Payee will close the channel well before the refund timout to avoid a race of the two alternatives.

Bob does not broadcast the refund at start as it would not be included to the block chain or mem pool until its time has come.

The point of micropayment channell is not to broadcast anything but the final version of the settlement transaction.

The payee can flush the latest version of the settlement transaction any time to the block chain which then double spends and thereby invalidates
the refund. If this happens long before the refund timeout then malleability is not a concern.

The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
The payee will sign and broadcast the most favorable to him and that is the regular close of the channel.

Strictly speaking the block chain is not irreversible, in contrary it is able to reorganize in any depth.

Actually a valid critique of the technology that convergence to global consensus is not guaranteed within a time span of any length.
Consensus just becomes less and less feasible to change with time.

If you like playing with those numbers also consider that private keys in modern wallets are generated from word lists of length 12.
If those words were used as an alphabet then they would define a 2048^12 or 132 bit key space.

The word lists are instead hashed (see BIP39) which gives an approximate entropy of 2.62*4.5*12 = 141 bits.

Therefore the attainable private key set in modern wallets is smaller than the 160 bit range of addresses.

Using entropy estimates from here: http://people.seas.harvard.edu/~jones/cscie129/papers/stanford_info_paper/entropy_of_english_9.htm