Weird... why were bluebit and vlight's posts deleted?
Anyway, I have some other issues with the transaction locking mechanism.
Let's take t = the total number of Masternodes, as the paper does. But let us also define l = number of lazy Masternodes. I define a lazy Masternode as one who will not bother participating in the consensus process if elected as an authority node for that block. I see no mechanism discussed to not pay them if they refuse to reach consensus. In fact, I'm not sure how the network would really even be able to decide that (this is where nodes that have reputation, delegates, that can be voted out based on human judgement comes in handy). So, if a Masternode is going to be paid anyway for being a Masternode regardless of whether they participate in the consensus process for confirming locked transaction or not, we must assume some percentage of them will be lazy.
The probably of selecting 10 authority nodes that do not have any lazy Masternodes is p = ((t - l)!/(t - l - 10)!) / ((t)!/(t - 10)!) = ((t - l)! * (t - 10)!) / ((t)! * (t - l - 10)!). Then, ln(p) = ln((t-l)!) + ln((t-10)!) - ln(t!) - ln((t-l-10)!). If I assume that t is large and that l/t is not to close to 1 (say l/t <= 0.5), then I can use Stirling's approximation to get an estimate of ln(p): ln(p) ≈ (t-l)*ln(t-l) - (t-l) + (t-10)*ln(t-10) - (t-10) - t*ln(t) + t - (t-l-10)*ln(t-l-10) + (t-l-10) = (t-l)*ln(t-l) + (t-10)*ln(t-10) - t*ln(t) - (t-l-10)*ln(t-l-10). Define f = 1 - l/t. Then ln(p) ≈ t*f*ln(t*f) + (t-10)*ln(t-10) - t*ln(t) - (t*f-10)*ln(t*f-10).
So, p ≈ exp(t*f*ln(t*f) + (t-10)*ln(t-10) - t*ln(t) - (t*f-10)*ln(t*f-10)), and f = 0.5 corresponds to half of the Masternodes being lazy while t = 1 corresponds to none of the Masternodes being lazy. And (1-p) is the probability of failing to reach consensus due to the existence of at least one lazy Masternode in the set of 10 randomly chosen authority nodes. I have plotted this probability for a choice of t = 1000
here. Even if 15% of the Masternodes are lazy, that will result in an approximately 80% failure rate. That means 80% of the time, users will have to wait for the slow confirmations rather than the fast ones. If you want the failure rate to be less than 5%, you will need less than 0.5% of the nodes to be lazy (which seems extremely unrealistic to me unless you have a way to punish authority nodes that fail to reach consensus).