How exactly is this different from the current situation:

1. X owes Y some bitcoins. X generates a fresh Bitcoin address and tells Y to pay there
2. X transfers the coins to that address
3. Y claims funds were not received and that the address X has paid to is not one of his.
4. X has no way to prove that the address it has paid to really belongs to Y - so X is still liable to pay the coins again

Since Bitcoin transactions are not reversible, you need to at least trust the merchant to ship your goods (or use escrow), so they would gain nothing by pulling stunts like these. If you've transferred the coins to them over a secure connection (HTTPS) you can safely assume that when the funds were spent it was either you or the merchant that spent them - you want your goods and they have better ways of scamming you (they could just take your coins and disappear), so the protocol I described does not give them additional powers.

If you look at how Electrum works (https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.py if you know Python), they use a list of about 1600 English words and encode 32 bits of data within 3 randomly-chosen words. So 128 bits would go into 12 words, 64 bits into 6 words and so on. As long as you don't let the user choose the words (humans are pretty bad at randomness) but instead randomly choose the words from a large set, you can adjust the number of words for higher or lower security.

The recipient of the funds is supposed to immediately (or shortly thereafter) recover the private key from the PayPhrase and send the funds to its own wallet/address. The PayPhrase is only used as a temporary key, like a "voucher" if you want. The Bitcoins are sent to that, the private key is transferred via PayPhrase, then the recipient transfers them again to safe storage.

Hello everyone,

While working on my OtherCoin off-chain payment system (https://bitcointalk.org/index.php?topic=321085.0) I kept thinking of ways to make the Bitcoin network more friendly to newbies and non-technical people. Most of you have probably experimented with teaching an older (or non-technical) relative how to use the system, so you know what I mean when I say that in its current state it's a bit scary to most non-geeks.

Since OtherCoin uses the secure transfer of a private key as its main method of payment (and the method itself appears to have been described way back in 2011 - https://bitcointalk.org/index.php?topic=24429.10 ), I came up with a very simple person to person or person to merchant payment system, designed for humans (not wallets/machines).

The idea is really simple:

1. Whenever you want to pay someone, your wallet generates a new private key and prompts you for the amount to pay.
2. The wallet generates and sends a transaction paying the specified amount to the address corresponding to the private key it has generated in step 1).
3. The key is transformed into a human-readable sequence of words (e.g. "correct horse battery staple"), similar to the way brainwallets (or Electrum seeds) work.
4. The user reads the word sequence - the PayPhrase - to the other user over the phone, puts it in an email or writes it in a text box on a website to pay

This has a few obvious advantages:

A1: No communication is needed from the payee to the payer - this is very important if the wallet is a hardware one (it might not have a camera or a keyboard and even if it had a keyboard you probably don't want to type in a Bitcoin address by hand). This also adds security - in order for the payee to attack the payer, he/she would have to go through the Bitcoin network (the only thing the wallet is connected to), it cannot exploit a local buffer overflow or a similar weakness.

A2: No Bitcoin addresses are displayed or used. The paying party does not know the recipient's Bitcoin address and could prepare the transaction in advance (if it knows the amount to be paid). The transaction can then be claimed by whoever has the sequence of words that corresponds to the private key.

A3: Web merchants can easily associate a payment with a client - they no longer have to wait for a broadcast on the Bitcoin network, etc. They can handle the PayPhrase like they would a credit card number - they simply need to take that, convert it back to a private key, then sweep the funds to one of their addresses.

A4: Depending on the type of service/product being ordered, for a short time the funds can be controlled by either party - the payer or the payee - since they both know the PayPhrase. So the merchant could receive the PayPhrase, verify that the funds are in there, but only sweep it right before shipping the items.

A5: Depending on the expected time between the generation of the PayPhrase and its sweep to another address, you could reduce its bit size (and thus its security) in order to obtain a shorter phrase. I mean 64 bits of entropy (6 words using the Electrum algorithm) would be perfectly fine for 24 hours but maybe not for 1 week or 1 month. Also, brute force attacks are unlikely (because you wouldn't know which payments to target - they are plain Bitcoin payments), but a rainbow table could still be used to instantly break the key if we make it too short.

So, to summarize - What if in the near future, a Bitcoin payment would only be a matter of reading 6 words to someone over the phone or entering those 6 words in a textbox on a website. No Bitcoin addresses, no complicated protocols, etc. Just take out your wallet, enter the amount, then read the 6 words it displays to someone to pay them quickly and anonymously. Beat that Visa/Mastercard/WesternUnion .

Has this been described/used before? Do you think it could help non-technical people? Would you (as a payer or a merchant) use it?

Let me know what you think. Thank you!
Razvan

Also, paying by sending a private key allows for some very interesting form factors for the hardware wallets. Right now, the wallet needs to be able to read or receive the address of the recipient (so it needs a camera to read a QR code or an NFC reader or Internet connectivity). If payment is done by giving away the private key, the wallet no longer needs to "read" anything from the payee and payment can be prepared in advance, without knowing the final destination address. It's also safer since the payee has no way to inject any code/data into the wallet, it never sends it anything.

I was actually thinking of writing a wallet for these: http://wyolum.com/projects/badger/ - you would sync the wallet with the blockchain via USB once a day or so, then all payments would be done by simply selecting the amount using the 5 on-board buttons, then displaying a QR code containing the payment transaction to an address generated by the wallet and the private key associated with that address. The recipient would scan it, post the payment transaction to the blockchain, then post a second transaction sweeping the funds to whatever address it uses.

Just my 2 cents - this would be something separate from OtherCoin but equally interesting.

That only works if the majority of the merchants support the Payment Protocol. Otherwise the user will receive the "insecure payment" warning a lot and will eventually disable it altogether since most of the time it simply means the merchant (or individual) being paid does not run the protocol rather than something fishy going on.


Yes, that's precisely when it happens (when the Signature object is initialized when the applet is created). It does _not_ happen if the signature object is created right before signing. Thanks for your help, I would appreciate it if you could give it a try, let's move that part to the Yubico forum though, as you suggested.

The problem with the payment protocol and malware is the one I described on the Trezor thread ( https://bitcointalk.org/index.php?topic=122438.msg3448363#msg3448363 ). Basically, browser malware could simply strip the payment protocol parts and change the destination address. Since most individuals and some of the merchants will not have certificates, the wallet cannot simply refuse to pay to addresses that do not present a certificate.

So it's basically safe if you absolutely know that the merchant implements the protocol (so if it presents the wrong cert or no cert at all, you do not pay them) but kind of useless to secure interactions with merchants you've never used before or individuals.

The YubiKey Neo is a great tool for development, I've actually used it to test the OtherCoin code over NFC. It does have some problems though with RSA key generation and randomness - see my thread on the Yubico forums at http://forum.yubico.com/viewtopic.php?f=26&t=1207 .

There's also another very interesting application for this technology/idea: Bitcoin addresses are anything but human-readable and since they are supposed to change with each incoming payment, there's no chance for the user to remember them.

The Bitcoin Payment Protocol (https://en.bitcoin.it/wiki/BIP_0070) addresses this concern by allowing payment requests to be signed using standard X.509 certificates. However, this requires the Bitcoin client to redo all the work that the browser has already done when accessing the site over HTTPS, present the certificate to the user for verification, etc. Browsers already do that and have done it for years and people are starting to get used to the iconography and visual cues that come with this process ("green lock", "green address bar", various warnings in the browser that the certificate doesn't match, etc).

So I was thinking that we could reuse this knowledge and leave the verification and the UI to the browser and the user. People already know how to check the certificate and ensure that they're not sending money to a phishing site. When they enter their credit card number on a site, they only have to check that the site is genuine, not check the merchant's bank account number or ask the bank to confirm that it really belongs to the merchant.

Users could simply pay by entering the private key of a Bitcoin address holding the funds in a text field on the site (just like they enter their credit card details) after they verify that the site is genuine. It would then be up to the merchant to sweep the funds to the correct address. This would also make it a lot easier to track down payments since they would no longer have to match incoming payments from the Bitcoin network to invoices/payment requests issued over HTTPS.

This could also work in face to face transactions - you would give the key to the other person after you are personally satisfied that they are who they say they are (or ask them for an ID if you don't). I guess what I'm trying to say is that people (and their computers) are becoming pretty good at identifying sites and other people, so maybe we should reuse that knowledge.

What do you think?

I don't think it's going to be an "all or nothing" situation - I'm definitely not trying to replace the blockchain transactions, I am trying to augment them. Just as beeblebrox said, whenever they need anonymity or instant confirmation, people will pay off-chain. For large amounts and high security, they will go to the blockchain. For instance, I fully expect merchants to "redeem" their private keys onto the blockchain every now and then.

The "off-the-blockchain" transaction chain could be shorter or longer depending on how much you trust the system and how anonymous you want/need to be. This is why I'm trying to make it clear what the system knows and what its capabilities are and intentionally limit its abilities in order to prevent it from being abused by the issuer (which could be us or a licensee).

Thank you beeblebrox! My answer was directed at justusranvier, I was just explaining that we do not hold our users' bitcoins in any way and we have no idea if/when transactions take place and what the value of those transactions is.

In the case of the OtherCoins, we're definitely not "holding bitcoins on the user's behalf". They're Bitcoins and remain Bitcoins, accessible at any time without contacting any external servers. The idea is to just allow them to be passed on to another person without going through the blockchain, but they can be used on the Bitcoin network just as easily - the OtherCoin smartcard simply makes sure that you can only do one or the other - it keeps parties honest, it doesn't hold your bitcoins.

If you read this thread, you'll see that it doesn't have the notion of Bitcoins and balances and doesn't even know what address you're using.

You are right Piotr, it can be made into a standalone wallet (and I expect others to do just that once the OtherCoin card is released). My focus right now is completing development on the JavaCard / smartcard side and adding compatibility with the standard Android Bitcoin wallet. But I am also the author of VisualBTC (https://bitcointalk.org/index.php?topic=210371.0) so at some point in the future I could also try to merge the two. I'm just taking it one step at a time .

I just realized, an easy way to think about all this is if you're familiar with GSM networks - the SIM card (a smartcard) secures the key that is used to identify you to the network. It does not speak the GSM protocol, it cannot talk to towers or call numbers or receive texts. It just securely runs an authentication protocol with the network, using the phone to relay its messages. The SIM card never knows if your subscription is even active or how much credit you have (if it's a prepaid account).

OtherCoin works in a similar way - it only secures keys and offers some guarantees regarding their status (never revealed before). The wallet runs the Bitcoin protocol and handles everything else. The only thing it cannot do itself is sign transactions to send funds away, it asks the card to reveal its half of the key or just send it to the other card in encrypted form.

It doesn't have to be done in the card, that's the job of the wallet. The card secures the key, the wallet knows about balances. Once you send the key to the recipient, his card gets the key and the wallet verifies that the public key / address has the expected funds on it. The card simply verifies that the received private key corresponds to the public key and that it has never been revealed, that's all. The wallet is the one that checks the balance (either by parsing the SPV chain or actually looking at the blockchain) and confirms that the funds are really there (of course, there could be _more_ funds than it expects if someone sent additional Bitcoins to that address after the sender created the proof, but I guess the recipient would not mind ).

Yes and yes. They are both there. I already have them working (ECDSA on secp256k1) but the only place the Koblitz curve is used is to calculate the public key corresponding to the private key received (to check that the sender didn't just send a random number but the actual private key to the public key it's pretending to use).

The card is just a microSD card, with no network capabilities. So it has to be plugged into something to work and that something is your smartphone. And in order to prevent the card (that you might not fully trust) from knowing what you are doing with your funds, the smartphone also generates a keypair (public + private key) that it combines with the keypair the card has generated to get to the final Bitcoin public key / address to use.

Of course, there's nothing stopping a wallet from just using what the card gives it (that is take the public key from the card and run it through SHA256/RIPEMD and generate an address).

The card always controls its part of the private key and without that part the wallet cannot make payments but can receive payments and monitor the blockchain. It's also the wallet that runs all the Bitcoin functionality (checking balances, sending funds, etc). The card is just a private key generator that either keeps the key to itself or sends it securely to another card.

Does that answer your question? You can't go completely without a wallet, you would need at least a screen and some network connectivity. But the wallet will not be a specific wallet, any wallet should be able to just send/receive requests to/from the card. It's a simple library to send/receive APDUs (http://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit) through filesytem operations.

Piotr, adding funds to the card is simple - the wallet already knows the address that results from combining the public key on the card with the public key it has generated. It also knows the private key it has generated, just not the one the card has.

So it works like this:

The card generates a private key x and calculates the corresponding public key P. The card reveals P to the wallet but keeps x secret.
The wallet generates a private key y and calculates the corresponding key Q.
The wallet then calculates the final public key as P+Q and calculates the associated Bitcoin address. That is a plain Bitcoin address, it can receive funds from anywhere.
Whenever it needs to spend the funds, the wallet asks the card for x (the private key corresponding to P). The card reveals it and discards x and P.
The wallet then calculates x+y => the private key corresponding to the P+Q public key.

So the wallet knows the Bitcoin address, you can send funds to it just as you would to any Bitcoin address. So there's no need for a "top up" procedure, any Bitcoin wallet can be used for that.

Getting cards back or forcing people to go to specific locations to reload them would probably make most of them think twice about buying them in the first place. I want them to be able to load them up by simply sending funds via the Bitcoin network to their address, I want them to be able to pay offline (or mostly offline - like gmaxwell suggested).

I also don't want to force people to go through the blockchain at any time - if they choose to just pass keys around using the OtherCoin mechanism, they should be free to do so.

Also, key renewal cannot be done over the Internet - when we sign a key with the master key, we basically say "we've verified this card and it's physically and logically one of ours, with the restrictions we imposed". This is only done offline, at the time the card is manufactured. Of course, cards can have an expiration date (and there probably will be one, like 10 years or so) - at that time, the card would stop working as an OtherCoin but it could still be used to reveal its keys to be used on the blockchain.

Hi Adam,

The mechanism you described (which is pretty cool btw!) would protect against physical theft of the card by a previous owner, in the absence of any other security measures. But in the case of the OtherCoin, each card is protected by a 6 digit PIN code and you get 3 tries, so stealing the card doesn't get you anything unless you can also get the PIN code. The card is also physically inside the phone, so it would be hard to steal without the user noticing it (unless he leaves the phone unattended for a long time). Finally, previous owners have no way of telling that you did not forward that key to someone else - since there's no trace of the payment anywhere, they could steal your card only to find out that you've already spent the key that they have the other half for. So I think we're safe, at least in the current model. Of course, there's always the Rubber Hose Cryptanalysis method (http://xkcd.com/538/) - that is sure to reveal the PIN in record time .

A lot of things can be done by using an external oracle (in this case the issuing authority of the cards) - setting the time, confirming balances, etc. The problem with that is that it would make the system dependent on that authority and its uptime. It would also require signature master keys to be present on an Internet-connected server (or a separate set of keys that are only used to sign balance confirmations or the current time). I would like to keep the keys offline as much as possible (all cards will be certified completely offline and the master keys will never leave the computer used to sign/certify the cards).

Of course, there will have to be a server that hosts the CRL (Certificate Revocation List) but updates to that list would be very infrequent and the list itself could just be generated manually and hosted on multiple machines (or dropped on Amazon S3 for instance).

About the lock time, I think gmaxwell was talking about this: https://en.bitcoin.it/wiki/NLockTime , not an actual timer in the card. This could actually work because generating a Bitcoin transaction with 1 input and 1 output is considerably easier than implementing a full transaction parser/generator in JavaCard. The recipient of the funds could obviously refuse the payment if the key is "time bombed" this way and I would have to make sure that that single transaction the card generates is bulletproof (people will obviously ask if it doesn't leak their private key, etc). And of course, this would require the card to actually know the full private key (that is get the half that the wallet has generated as well) - so in theory the card would now know the Bitcoin address you are using, something that is impossible if it only holds just half of it and never signs anything.

Regarding the GPS question, I'm not sure what you're trying to achieve. The wallet (the smartphone) could log the GPS position, the exact time of the transaction, etc, but those would not be signed/certified by anyone. "Certified location" is a very hard problem - you would need a tamperproof GPS receiver, with spoofing protection, physically tied to the smartcard in some way (otherwise you could simply tunnel location requests to a remote location). So if that's what you're looking for, the answer is probably "no" for now. If you simply want to log where a transaction took place for your own use, your smartphone wallet can do that quite easily.

I understand that, and that is fine as long as the user expects the merchant to use the protocol. As far as I understand, the Payment Protocol starts by having a Pay Now button/link with the URL bitcoin:merchantaddress?request=url_of_request . The wallet opens that, sees the "request" parameter and goes there to fetch the payment request.

Malware running on the computer could simply rewrite all bitcoin:merchantaddress?request=url_of_request URLs to bitcoin:hackeraddress in the browser (that is rewrite the destination and disable the Payment Request protocol). The user will then pay the attacker instead of the merchant.

Of course, when everyone starts using the protocol, the user will be wary of sites that do not implement it (just like a shop that doesn't use HTTPS nowadays will not get much business).

I would say extracting the key is the hard part. The protocol is open, so once you have the key there's nothing stopping you from emulating a card. We're actually going to do just that as a way for users to try out the system before buying a real hardware card - instead of talking to a local smartcard (microSD inserted into the phone), they would establish an HTTPS connection to a server and send/receive data that way - it would work like a remote smartcard accessible over HTTPS.

This obviously doesn't offer the same guarantees (the entity running the server would see your requests to the virtual smartcard, so it could theoretically tell when you're paying someone and who you're paying - based on their public RSA key). So you would have to trust them considerably more than you would if you had a physical card in your phone, under your complete control.