I posted my first draft of something approaching a proper tech spec for this fidelity bond/contract stuff:
https://github.com/petertodd/trustbits/blob/master/fidelitybond.mdI'm not really happy with it either, but I think it's better than fidelity bonds: my issue with this name is that both "fidelity" and "bond" (as a financial concept) are not terms commonly used in English. Fidelity tends to have connotations to sexual loyalty even though it can be used more generally, so it could be confusing to have it crop up in another context. Also whilst anyone who is interested in finance knows all about bonds, most people have never actually experienced one themselves.
Keep in mind that the term "fidelity bond" isn't just a finance term, it also crops up in stuff like security guard jobs. That's actually the first place I heard it, talking to someone explaining how they were now a bonded guard. That said, more specifically for what you are talking about re: wiki and similar services, I think "passport" is reasonable enough. It's also good that it has the real-world connotation that acceptance of a passport is not absolute. Similarly what is blacklistable behavior is ultimately a human criteria, and you'll find that rough consensus emerges among groups of mutually trusted services, but a passport revoked by Wikipedia may not be considered revoked by 4chan.
Fidelity bonded banking has the advantage that the contracts can be made machine readable. Of course, equally, the disadvantage is that the contracts are machine readable... One little mistake...
As for the term "sacrifice", I think this is a really good one for describing the nitty gritty of any of these protocols; I was racking my brain trying to come up with a decent term and I think sacrifice solves that problem.
Seeing as the transactions are all-fee anyway, miners have no incentive to not include them (unless Bitcoin turns into a network for high value transactions only of course). I'd think you could set a threshold, say 4 of 6 blocks must include them, or something like that. The right gap thresholds could be determined empirically.
It's not just about incentive, what happens when you get a near orphan by pure luck? We already see transactions getting passed up by miners who missed them for whatever reason all the time. Yet as gaps increase, it just makes it easier for a relatively low hash rate miner to just wait until they get lucky, while only risking the small chance that their block is orphaned and another miner picks up the tx for the fee.
Besides, embedding a transaction inside another transaction seems superfluous (the second tx could just be broadcast and sit in the memory pool for a while).
How do you prove that a tx existed in the memory pool after the fact?
Post-pruning size with OP_FALSE outputs is zero, is it not?
I'm pretty sure any script ending in OP_FALSE is guaranteed unspendable. Even the OP_IF stuff has a check (via vfExec) to ensure that an IF block is terminated; there are no op-codes that mark a script as valid and terminate execution. OP_RETURN at the end of the script would work too I think.
I'm not worried about the size. As I said, all-fee transactions should be completely prunable away.
It's not just blockchain size, it's proof size. You have to be able to prove to a SPV client that the transactions exist, so you have to hand them the transactions and the merkle path to the block header. In addition a malicious miner can currently pad transactions to a maximum of 10KiB scriptSigs.
You don't need a whole lot of blocks, just a few would be sufficient, so gaps are OK. I'm not worried about miners who manage to mine the majority of all blocks within the consecutive-blocks period because if that could happen we'd have a 51%+ attacker, and then we'd all have bigger problems than this.
Again, you don't have to have 51%, you just need to get lucky once every few months.
I'm not sure minimum fees will be much larger in future. That's certainly not a consensus anyway. I see fees being similar, lower or even being zero for most casual users, that could happen in a world where miners are funded through assurance contracts of participants who need the security (merchants, exchanges, traders etc).
Well, you're assuming the block size will be lifted which I'm dead set against.
The problem that I have with fee values is that the purchasing power with Bitcoin is not fixed - a passport created 3 years ago might have needed to burn 100's or 1000's of BTC to claim legitimacy; requiring any application to have some sort of exchange rate lookup as part of the passport application.
The app that checks the passports needs the block headers anyway. It can always record spot rates along side its storage of the headers. There's no trust-free way to bootstrap that, but exchange rates are a matter of public record and would be hard to forge in any significant way without someone noticing that it's historically inconsistent.
Being able to sell part of the cost of an identity, as you suggest, fixes the problem of fee values just fine: sell off the part of the fee that you don't need. It's a lot nicer than the huge pain of trying to record spot rates, although having said that you will need some estimate of the liquidity and supply and demand for the current market for fidelity bonds for any given application.
One issue with making passports smart property that just occurred to me is that it'd increase the requirements to having a copy of the utxo set because otherwise you couldn't know if the control output on the tx you were given was already spent or not. So you'd have to either run a full node or extend the p2p protocol so membership in the utxo set could be remotely tested by thin clients.
Well, I think this touches on one of the reasons why I'm 100% against raising the 1MiB block limit, especially with the sort of floating limit that Gavin and others have proposed: you can't have really trustworthy fidelity bonded transaction processors, and unbounded block sizes at the same time. It's in miner's incentives to do what they can to undermine the off-chain transactions to try to get as many transactions as they can for themselves, and just by increasing the block-size they achieve that goal by further centralizing who can verify the utxo set.
Keep in mind it's not even just a total blockchain size issue, it's a bandwidth issue. 1MiB/10minutes is just 2KiB/s, small enough to keep up with even on highly bandwidth constrained nodes stuck behind restrictive firewalls in unfriendly countries. A node operating under these conditions may never need to actually make an on-chain transaction, but they will be able to easily keep track of fund movements for the fidelity-bonded transaction processors they are depending on to move their Bitcoins, and they'll be able to keep track of those movements with a much higher degree of certainty than with any of the utxo proposals, especially because that one single node, which might be the only connection to the blockchain for a big area, can redistribute everything every other node in that area needs to know. And again, in an unbounded blocksize world miners have every reason to sabotage UTXO mechanisms if they'll stop off-chain transaction processors from operating successfully.
I'll write more on this later, but increasing the block size is madness. I thought people were still taught how ugly O(n) and O(n^2) scaling was in school...