Thank you Peter, I'll look into those paywords, I wasn't aware of that system. Smartcards do not have an internal clock, so I was initially thinking of using a certified time source (that is a web service that accepts a nonce and returns a signed time+nonce packet indicating the current time), but if this could be done in a distributed fashion it could be interesting. I'm not sure how that would work though, how would you limit the amount being transacted or do you only suggest limiting the number of transactions that a card can do in a given time interval?
Sorry! I must have read your reply and forgotten about it.
The blockchain itself can be used as a clock in a few ways. The most obvious way is to process the block headers and just use the latest one lower bound on what time it is. However then you have to ask how does the card get the blockchain? You can add to the protocol an encrypted field that essentially lets anyone feed the card with block headers within any transaction going to it - if I'm sending you money I can inform your card about what time it is against your will.
However, all the block headers are kinda large for a Java card, so you really want to only send a subset. When you think about it every header the card gets is essentially making a kind of statement that some amount of work was done claiming the current time at least blockHeader.nTime Every header the card gets pushes the likely current time in some direction, usually forward. Making a bunch of fake block headers with high difficulty is very expensive, so you can probably come up with some rule that makes faking headers to lie to the card about the current time unprofitable. You can be a bit more clever with this by using interactive or non-interactive proofs, but long story short, Bitcoin doesn't support that yet.
You can also force the owner of the card to provide recent block headers via timestamping and merkle paths. The card would generate a nonce and and the card owner would be required to timestamp that nonce in the Bitcoin blockchain and provide the card with a merkle path from the nonce to the block header. The user is forced to keep providing the card with new blocks; with a minimum difficulty the cost of compromise is well defined, almost. Unfortunately it is possible for a group of card owners to collude and have some fake block headers generated so as to let them all benefit, driving the per-card cost of faking the time down. (possible without timestamping too I might add)
Timestamping infrastructure doesn't exist yet, but creating it isn't hard. I have a project called OpenTimestamps that was doing just that - I'd be happy to put some time into it again.
As for centralized time services personally I'd be very hesitant to use any kind of centralized service simply because it'd be temping for a court to order them to either shutdown, change keys, or sign fake timestamps as a way of disrupting OtherCoin users.
A quick status update: OtherCoin is progressing nicely, I have cleaned up the protocol a bit and added the ability to send PIN-locked keys. A locked key is transferred just like any other Bitcoin key in the OtherCoin system but it's also protected by a PIN. Without the PIN, the recipient is unable to spend it or transfer it to another user. This allows a primitive type of escrow - once a key is transferred, the sender no longer has it but without the PIN, the recipient cannot do anything with it (other than verify that it exists and has funds on it). So the two parties have to agree in order for the recipient to obtain the necessary PIN to unlock the key.
Good idea! How long will this pin be? What will you do to prevent brute-forcing it?