Lets suppose we take away everything but the transaction/scripting
system from Bitcoin. What is left is basically a way for to prove that a
set of pubkeys authorized the movement of coins from one place to
another. Of course, such a system is flawed as a currency because of the
double spend problem - specifically the need to know that there exists
global consensus on what particular set of transactions is the accepted
state.
However, in the event that a party commits double-spend fraud, it is
trivial to prove to others that they did so. Thus if a way to punish
that party can be found, we can give them an incentive to behave
honestly.
Consider the following new opcode and scriptPubKey:
n m CHECK_DOUBLE_SPEND_PROOF
spent with the following scriptSig:
{transaction 1} {transaction 2}
where where both transactions are part of the block chain starting at
the given genesis hash, and whose blocks are signed by n of m ledger
pubkeys; the ledger is the entity entrusted to keep the ledger accurate
and not allow double-spends to occur.
Anyone with proof of a double-spend attempt made in the blockchain
starting at a given genesis hash can collect a reward. In essence, the
txout is the fidelity bond holding the ledger accountable.
Of course, the devil's in the details...
Transactions and blocks
---
Transactions themselves can follow the Bitcoin system of scripts,
scriptPubKeys, and scriptSigs and re-use the existing validation
machinery.
A so-called block however is reduced to the simpliest possible form:
where the signatures are that of the ledger. The block hash is optional
and provides a way to further link a block into some sort of system to
make double-spend fraud detectable. Importantly the Bitcoin validation
machinery itself only needs to know that the double-spend happened at
all, not how it was detected.
Note how had the string manipulation opcodes not been disabled, in
particular SUBSTR, and had CHECKSIG not been designed as a single
opcode, it might have even been possible to create the double-spend
detector using the existing scripting system. Equally with just a set of
ECDSA opcodes one could probably construct a double-spend detector using
non-Bitcoin compatible transactions, but alas, things didn't work out
that way.
Moving funds in and out of fidelity-bonded ledgers
--
First the depositor informs the ledger of the amount they wish to
deposit, and one txin that will be used for that deposit.
Nex the ledger first creates a ledger-only transaction with the the
following scriptPubKey:
CHECK_PAYMENT
VERIFY CHECKSIG
spendable with the following scriptSig:
The CHECK_PAYMENT opcode returns true if provided with a proof that a
transaction with a txout of the correct value and scriptPubKey spending
the given txin exists in the Bitcoin blockchain. The ledger should
ensure that a different scriptSig is created for every deposit. The txin
is provided to allow the ledger to use the same scriptPubKey for all
deposits and thus make external audits easier. (note that an UTXO merkle
sum proof system is most likely to index by scriptPubKey)
The ledger gives the depositor the fully signed transaction, and the
depositor makes it valid by broadcasting that transaction and getting it
confirmed in the block chain.
Withdrawls from the ledger to the blockchain proper can happen the same
way, but this time it's the ledger that provides the transaction, and
the transaction owner that spends the transaction to an address of the
ledger's choosing.
Detecting double-spends
---
From the point of view of the Bitcoin validation machinery, double-spend
detection is undefined. Thus multiple systems are possible without
changing the validation rules.
One simple method would be for the ledger to maintain a publicly
accessible website, in particular publically accessible over Tor.
Transactions would be incorporated into a single log, and clients would
expect to be able to get copies of that log at any time anonymously. If
their transaction did not appear in the log, they could immediately
prove the double spend. (going as far back as the genesis block) The
optional block hash signed by every transaction would be incorporated
into the audit logs.
Equally trusted computing technologies can also be used instead of, or
in conjunction with, the ledger audit logs.
Ensuring the bond can-not be collected by the ledger
The simplistic scriptPubKey presented in the introduction allows for the
ledger to create their own fraud proof and run with the funds. What we
actually need is a way to constrain the destination of those spend
funds. Consider the following scriptPubKey:
{bond ops omitted} GET_TXOUTS HASH160 EQUAL
GET_TXOUTS would put a serialized version of each scriptPubKey, value,
and so on on the stack. (ideally using the existing CHECKSIG
