I've just read it, sorry. It's a very nice idea and you're right, it doesn't lock your funds (or it does, but for a limited time). I wonder if "lock times" (see https://en.bitcoin.it/wiki/Contracts ) could be used to make your idea work (without requiring a change in the Bitcoin protocol).

The problem I see with all these solutions is that most simpler clients (such as the Android-based wallets) do not understand anything other than simple payments / scripts. I may be wrong but I think even desktop clients may (and currently do) choose to not forward certain transactions if they do not understand the scripts attached to the inputs and outputs. I don't know enough about the current clients to confirm this though.

As you said, the problem with involving a third party with each payment is that they could eventually go out of business (or simply have an outage at a certain point in time). If all they do is publish a list of Bitcoin addresses that have double-spend-proof smartcards behind their private keys, they can't lock you out of your own money (by refusing or being unable to sign the transaction when requested). This removes them from a position of power (they can't block your funds or refuse to allow you to spend them for political or legal reasons).

Also, if they ever go out of business, you can still use your smartcard-backed wallet as a regular wallet (it would still sign transactions and they can still be verified as double-spend-proof by anyone that still has the list of public keys they've published). New Bitcoin keys could be added to the wallet (or rather generated by the wallet) and it would then function as a standard Bitcoin wallet since there would be no one to update the public key list (vendor went out of business).

So you don't entrust a third party with your funds and give them the ability to block your transactions. You still have complete control over where and when you pay, you just don't get access to your keys. I suspect that most non-technical users will not care much - as long as they can quickly and easily pay for their transactions. Just like most of them don't memorize credit card numbers or account numbers, all they care is that the transactions go through quickly and without much involvement from their end.

@grue, I know very well what double spending means. What I'm proposing is a way to make it easier for merchants to accept payments with 0 confirmations (=immediately) by making double spending by a malicious user less likely.

@fpgaminer . Regarding A, the third party is just a signing authority, it cannot spend any funds, it has no access to the private keys. It simply certifies that the private key corresponding to the public key / paying Bitcoin address was generated on the smartcard and that the smartcard actively prevents double spends. Of course, the risk is not entirely 0, as you said there are hardware attacks against smartcards, but the merchant could classify the user as lower risk than a generic user with no restrictions on his keys.

The advantage of doing everything on the card would be that you wouldn't need to rely on any third party for each payment (or there could be multiple third parties / certification authorities, each with its own smartcard type/software, certifying various public keys for 0-confirmation payments). Larger merchants could become their own CAs and issue their own wallets/smartcards that could be used both as "secure wallets" (for sites that accept their certification) and regular Bitcoin wallets (for sites that do not know how to handle the additional information).

LATER EDIT: a third party in a multi-sig scenario doesn't prevent the user from sending one transaction through that third party and immediately doing a double-spend to another destination without going through them. As long as the user has access to his private key, he/she cannot be forced to perform a particular type of transaction (multi-sig, etc). Doing this in the wallet prevents the user from executing any transactions without anti-double-spend verification (they have no choice, the smartcard doesn't sign unless it's satisfied that all the security conditions are met).

Hello,

I was wondering if anyone with more knowledge of the Bitcoin inner workings thought about preventing double-spends by using a smartcard-based wallet (or signature system) that keeps track of inputs used and prevents the user from double spending. This would obviously mean generating the private key on the smartcard and only using it internally to sign but never exposing it to the outside world (the user would never know his private key).

I wonder if addresses generated this way could be marked in some way to tell merchants that the funds have been spent using a "double-spend preventing wallet on a smartcard", giving them the OK to provide the service/goods immediately, without having to wait for confirmations.

I'm working on such an implementation myself (on a smartcard), but I'm not sure how to approach the "tagging" part. One way (a bit convoluted) would be for each wallet to come with a separate private key that can be used to sign each of the public keys it generates, certifying that they have been generated on-card and not imported. The public key for each smartcard could sit on a server somewhere, allowing anyone to receive the "certificate" together with the payment and verify that the public key is one of the safe ones.

Any ideas?

Razvan

Hey guys, I've sent you an email (contact (at) btchip (dot) com ). I think I might have a solution for your problem with the fact that the smartcard doesn't have a display and keys. We have a service called VeriFi (https://www.veri.fi) that receives HTTP requests and calls you on the phone to ask you a question (it could be like "Rosie's shop wants to charge you $5 for shoes, do you want to authorize this transaction?" - you would say "yes" or "ok" and the transaction would go through. If you say anything else, it doesn't.

So if your BTChip smartcard asks the card reader to establish an encrypted (or maybe just signed) channel to our server, it can ask it to call the user and tell him the amount and the merchant name, then get his/her authorization to proceed and sign the transaction.

It could work something like this:
1. Terminal sends AMOUNT + MERCHANT_NAME to the smartcard.
2. Smartcard generates a signed request like "smartcardid:AMOUNT:MERCHANT_NAME:nonce:signature" and sends it to the terminal.
3 .Terminal sends request to VeriFi (it can't modify it, it's signed)
4. VeriFi calls the user, gets his response, then sends back "smartcardid:nonce:ANSWER:server_signature".
5. Terminal sends the signed response back to the smartcard.

Even if the terminal is hostile, it can't modify a request. Even if it replays a request, VeriFi will ask the question again but the answer will be useless since the smartcard will compare the returned nonce with the one it expects - so it won't accept the answer.

So it would essentially be like your smartcard wallet calling you on the phone to authorize the transaction. Pretty cool, huh?

Razvan

You could do more than simply notify the user of the transaction amount, you could actually ask him if he's ok with the transaction. I've actually created VeriFi (https://www.veri.fi/) for this exact purpose - it's a web service that calls you on the phone and asks you a question (it could be like "Rosie's shop wants to charge you $5 for shoes, do you want to authorize this transaction?" - you would say "yes" or "ok" and the transaction would go through. If you say anything else, it doesn't.

Of course, this would require hosting the wallet somewhere or having a smartcard-based solution that only signs the transaction if the (signed) response from the server is "yes" or "ok".

I've sent an email to the guys developing the BTChip smartcard solution to see if we could work together on this somehow. I'll see what they say.

Same here... I fail to see how this protects the forums and improves the quality of the discussion ... some people might not have enough patience to get out of the newbie jail and just give up while determined trolls will have no problem posting 5 messages.

Is the whitelist thread still active at all? I mean does anyone read those requests and possibly whitelist their authors?

Does anyone still read these messages? Or should I just post until I hit the 5 post limit? It's a bit stupid, I want to contribute to the community, not write random stuff in various threads to hit the limit.

Hi everyone,

I am the owner/developer of VeriFi (https://www.veri.fi/) . Company name is Cayenne Graphics, we're located in Bucharest, Romania. We plan to integrate VeriFi with smartcard-based Bitcoin wallets and possibly software wallets as well to allow them to call their owner on the phone and ask for permission for certain operations (so that certain payments / actions can be performed when the user is away from his Bitcoin client, software or hardware).

Thank you,
Razvan Dragomirescu

Hi there,

I am the owner/developer of http://www.veri.fi/ and http://www.automonitor.net/ . I wanted to post an offer to help the guys developing the BTChip smartcard-based bitcoin wallet (offer them access to our VeriFi system and help with the code) but I realized I cannot post. Could you please unblock my account? I have no stake in Bitcoin (other than the fact we accept it on our site - nobody's paid us that way yet but it's there as an option ).

Thank you,
Razvan Dragomirescu