You're trusting the recipient anyway to deliver the goods. You don't use the processor because you trust him, you use him because he allows you to send payments everywhere with a single channel, without knowing in advance who you're going to pay.
Without wandering too far off topic, I'm not disputing that this is a very cool idea, or that the trust in the processor is a minor issue compared to trusting someone with the whole escrow. I just wanted to point out that there are drawbacks to each solution which have to be considered, and there's no obvious best solution which trumps the others being discussed.
...The real issue is race attacks, which are certainly feasible. Minor blocks would make race attacks a lot more expensive than they currently are because you'd have to put in the effort to solve minor blocks (assuming the merchant is willing to wait an average of 10 seconds).
I don't see how it really helps security against race attacks. With the current system you can query each of your peers if they know of a conflicting transaction. In none do you can be pretty sure the network recognizes the transaction.
There's a big assumption there that you're well connected to peers, that those peers are well connected to miners, and that there's no sybil attack. Being properly connected is an extra precaution that has to be managed carefully by vendors, as opposed to being baked into the system. If you wait for a few minor blocks, at least you know for sure that the attacker had to pay for a considerable amount of hashing power. I feel that's a big win.
Also, proof of stake proposals strive to make the network immune to >50% hashrate attacks. I've had a discussion about PoS lately and I think I have a new framework to think about it, your suggestion could fit in as well.
I'd love to hear your thoughts on this, is there somewhere I could read about this?
There are advantages to the hybrid minor/major block approach (high time resolution, faster confirmations, while retaining the longer term safety of the major blocks), but I'm not at all convinced a Bitcoin fork with a 10 second interval couldn't work better. Maybe I'm missing something but the wasted hash power (assuming 7% orphan blocks) and header overhead don't seem like a huge deal to me.
Header overhead is a pretty big deal. Most people won't run full nodes, and hopefully they'll choose the more secure lightweight clients over eWallets. The resource cost of this is proportional to the number of headers.
That's a very good point. This merits a lot more discussion, but off the top of my head I don't see why the minor/major block paradigm couldn't be used here so that lightweight clients would only be looking at major blocks, at least for historical transactions. In fact, since old transactions have such a massive amount of buried hashing power protecting them, one could consider a scheme that would decrease the number of blocks needed per time interval as you go back in time, potentially making that header chain even smaller.
