The particular issue I'm submitting for consideration in this post is the implementation of a new future-proof address type.
TerminologyAn overseen transaction is one where the user requires the assent of one or more third parties to complete the transfer of bitcoin.
The third party is termed the overseer. The service they provide is oversight.
Bitcoins sent to the user which require an overseen transaction to spend are overseen coins. The address they are sent to is an overseen address. Note that sending coins to an overseen address does not require an overseen transaction.
Oversight ServiceThe user signs up to an oversight service with a certain policy and mechanism on approving spends. The oversight service might be implemented as a USB dongle with a display or a web page accessible by a browser or by a call centre accessible by phone.
Overseen AddressesThe user needs to distribute a new overseen address to receive bitcoins and/or to send his existing bitcoins to. The scriptPubKey for transactions sending to an overseen address must require the users signature (like a normal transaction) and the overseer signature.
This is a non-standard transaction which potentially needs to contain two hash160s of information - one for the user's key and one for the overseer's key. It's troublesome to type in such a lot of information and to come up with a new address format for every new type of non-standard transaction.
Out numbers - a new address typeWe observe however that it's very easy for the standard client to create a new transaction by copying the scriptPubKey of an existing transaction. So instead of sending to an address like 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa which contains the hash160 of the credited public key we could send to scriptPubkey 0 as seen in the block chain. I'm going to refer to this as "out 0".
Address
1PSSGeFHDnKNxiEyFrD1wcEaHr9hrQDDWc would be out 170 as it's the coinbase transaction for
block 170. The coinbase transaction for
block 171 would be out 172 as block
block 170 contains
the first ever transaction, sending 10BTC to
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 which is then out 171.
The onus for creating the first non-standard transaction and getting it into the block chain can therefore be shifted onto the oversight service.
When the user signs up, the oversight service creates a non-standard transaction crediting a tiny amount of bitcoin to the overseen address and gets it into the block chain. After a suitable number of confirmations the overseer works out the what position that address has in the block chain and passes that "out-number" (typo-protected, see below) to the user. The bitcoins required for the small transaction could have been transferred by the user to the oversight service on subscription as part of the fee for the service.
Paying to overseen addresses - or to generic out-numbersWe modify the standard client so that when the user types an out number into the "Pay to:" box, the client looks up the relevant scriptPubKey and fills in the fields accordingly. So if a user types "o170" the client finds out that the scriptPubKey is just a simple transaction to address 1PSSGeFHDnKNxiEyFrD1wcEaHr9hrQDDWc and fills it in. If the user types the out number for an overseen transaction then the client looks up the scriptPubKey and recognizes the transaction type. It redraws the Send Coins window to include a box for the overseer address and it populates the "Pay to:" and "Overseen by:" with the destination address and overseer address respectively.
New schemes involving non-standard transactions will be seen to be useful and will be invented and implemented in future. The above solution is completely future-proof as the client software doesn't even need to understand the scriptPubKey in order to create a transaction sending coins to it. If the standard bitcoin client software and UI is altered to allow transactions to out-numbers then users of that software can send money to overseen addresses even if the bitcoin client does not understand overseen transactions. The client should allow the user to send bitcoins to an out-number for which the client does not understand the scriptPubKey after a suitable warning such as "This version of the bitcoin software cannot inform you how coins sent to this address will be disposed".
Preventing bitcoin transfers going astray with out-numbersThere is an issue with preventing the mistyping of an out-number because it's very likely that adjacent numbers will be valid out-numbers and also many transpositions of adjacent characters will also yield valid out-numbers. I suggest that the hash160 of the scriptPubKey base-52 encoded into "a-zA-Z" be appended to the displayed out-number. A typo-protected out-number would therefore look like "o170XcaYfWuomDEsiFqnaXDVxqHHTxMe". The user would not have to distribute, store or remember all the alphabetic part of the out-number as the client would look up the relevant scriptPubKey, hash it and fill it in. So for the above example "o170X" would provide approximately a 98% chance of typo detection, "o170Xc" would provide approximately a 99.9996% chance of typo detection and "o170XcaYfW" would reduce the chance of an undetected typo to about one in about twenty billion. Anyone distributing their out-number to receive payments could decide how long their protected outnumber was going to be up to a max of the number + about 28 characters.
The exact format of protected out-numbers is thrown open for discussion. There must be no confusion between the current address system and protected out-numbers. Out numbers are "numbers" by analogy with bank account numbers and to avoid commerically embarassing issues whereby inappropriate words are spelled out (cf. the issues with rude words in CAPTCHAs). The alphabetical "check" portion can be engineered to be free of inappropriate words.
Sending overseen coins from an untrustworthy computerUsers subscribed to an oversight service are possibly using rootkitted computers and must be running an oversight-enabled version of bitcoin to spend overseen coins. if all the coins in the users wallet are overseen then when the user presses send, the computer can't send a complete transaction as it does not have access to the overseer's key and can't generate the overseer's signature. (Except by using the "disappearing overseer recovery pack" mentioned by Gavin).
One possibility is that incompletely signed transactions be allowed to propagate across the bitcoin p2p network like a normal transaction. The overseers would see all the incomplete transactions which they could sign to complete and after checking with their policies and/or phoning the users etc they sign the transactions and send the complete transactions out across the network to be included in blocks. In this instance, the behaviour of the incompletely signed transaction is similar to a transaction with a nLockTime in the future.
Another possibility is that the bitcoin client has been informed of the IP address of the oversight service that they are using, so the client sends the incompletely signed transaction direct to the overseer who, after suitable checks, signs it and distributes it or sends it back etc..
In the case that the overseer is a USB key, the incompletely signed transaction is sent to the USB device. It checks the transaction and displays the amount and the address to be credited to the user on its own display so that the user can check them. If the user approves then the USB key signs the transaction and sends the completed transaction back to the computer to send to the bitcoin p2p network. It seems likely that some extra USB-key-specific software needs to be installed on the computer to handle the communication between the bitcoin client and the USB key.
General ConsiderationsI think the system should not prefer any particular oversight service to any other. Anyone should be able to provide oversight service if they follow the protocol and any user should be able to subscribe to any oversight service.
The system should be able to be extensible to facilitate coins overseen by multiple overseers in which case the system should be able to facilitate situations in which both overseers are required to sign, and situations in which only one is required to sign.
If the overseer is a USB key, care has to be taken so that the bitcoin client does not have to concern itself with the details of transacting with the USB device.
In order to facilitate oversight services, bitcoind should be changed to enable the sending of transactions with explicit custom scriptPubKeys, possibly specified as a hexadecimal string encoding of the scriptPubKey contents.
ByteCoin
