Bitcoin PayPhrase - human-friendly payment system

[drazvan]

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

[1715292779]

1715292779

[1715292779]

1715292779

[1715292779]

1715292779

[fluidjax]

A couple of things spring to mind.
How can you generate a reasonable short phrase from a private key?
At the end of a transaction doesnt the sender still has access to the coins, as they will know the phrase and the private key is in their wallet somewhere?

[drazvan]

A couple of things spring to mind.
How can you generate a reasonable short phrase from a private key?
At the end of a transaction doesnt the sender still has access to the coins, as they will know the phrase and the private key is in their wallet somewhere?

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.

[fluidjax]

A couple of things spring to mind.
How can you generate a reasonable short phrase from a private key?
At the end of a transaction doesnt the sender still has access to the coins, as they will know the phrase and the private key is in their wallet somewhere?

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.

The phrase stuff, of course you are right, I was thinking about it backwards, creating a phrase from a pre-created key,  which would be difficult, but of course you can create the key from the SHA of a few random words, which is want you want here.

One issue with the pay phrase, the recipient would be able to claim that the money was transferred out of the address by someone else. And the sender couldn't prove where the money had gone.
i.e.

1) X owes Y some bitcoins and communicates Y a pass phrase containing the coins.
2) Y transfers the money out of the address of that pass phrase
3) Y claims the address at the pass phrase is empty, and so infers that the communication of the pass phrase was insecure.
4) X can't prove that the money was sent to one of Y's addresses, so in I should think X is still liable to pay the coins again.

[drazvan]

1) X owes Y some bitcoins and communicates Y a pass phrase containing the coins.
2) Y transfers the money out of the address of that pass phrase
3) Y claims the address at the pass phrase is empty, and so infers that the communication of the pass phrase was insecure.
4) X can't prove that the money was sent to one of Y's addresses, so in I should think X is still liable to pay the coins again.

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.

[fluidjax]

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.

It differs because it is necessary to communicate a secret between the parties, this adds a significant layer of complexity, and obviously large transactions are unsuitable to unencrypted email and possibly phone.
Person X could also be dishonest and remove the coins from the address before Y has redeemed them, and then X can claim the Y has poor security and lost them to an unknown 3rd party.

Bitcoin as it stands doesnt require the communication of secrets, but you are right to point out the weakness of communicating a receiving address.  Signing the address with your trusted public key is going to be sufficient but adds massive complexity for the average user.

It just made me think about a new type of malware thats going to appear, one that simply changes bitcoin addresses on websites to the hackers bitcoin address.

[drazvan]

It differs because it is necessary to communicate a secret between the parties, this adds a significant layer of complexity, and obviously large transactions are unsuitable to unencrypted email and possibly phone.

The parties should already have a secure channel set up in order for the payer to receive the address that the payee wants him to send the funds to. If that channel is not secure, the payer has no way of knowing it's sending the coins to the the correct person.

The other option would be for the payee to use a single address (and lose the privacy features), one that payers could add to their address books. But first time payers would still be vulnerable.

Person X could also be dishonest and remove the coins from the address before Y has redeemed them, and then X can claim the Y has poor security and lost them to an unknown 3rd party.

They can do that right now, without my extension! X can transfer some coins to an address he controls, then claim it was a payment to Y and that Y has lax security and lost the funds. You can't have both anonymity and proof of spending. If there is a way to publicly prove that you've paid Y some funds, then Y is no longer anonymous. Of course, you can prove that you've paid "some address that supposedly belongs to Y".

Bitcoin as it stands doesnt require the communication of secrets, but you are right to point out the weakness of communicating a receiving address.  Signing the address with your trusted public key is going to be sufficient but adds massive complexity for the average user.

It just made me think about a new type of malware thats going to appear, one that simply changes bitcoin addresses on websites to the hackers bitcoin address.

The Payment Protocol (https://en.bitcoin.it/wiki/BIP_0070) will solve part of the problem, but it cannot stop malware from just replacing Payment Protocol-enabled addresses with simple (unprotected) ones - I've described this a bit in the Trezor thread at https://bitcointalk.org/index.php?topic=122438.msg3448363#msg3448363 .

Finally, there are already services that accept private keys as payment ... you might have heard of some of them (MtGox, BIPS). See https://en.bitcoin.it/wiki/Private_key and also http://www.othercoin.com/mtgprvkey.png for a screenshot.

[drazvan]

There is one additional advantage - the PayPhrase can be used for truly decentralized remittances. The recipient of the funds does not need a Bitcoin wallet, he can just go to an agent (or an ATM), type in (or say) the PayPhrase, then the agent or the ATM sweeps the funds and gives the recipient his cash. Each ATM or agent will have its own wallet, so when the sender transfers the money he doesn't know who will end up receiving it.

The agent or the ATM does not need to talk to a central server - he simply takes the PayPhrase, checks that the Bitcoins are there, transfers them to a safe wallet and gives the recipient his cash (minus his commission I guess).

[Crowex]

If I understand your idea correctly, you are proposing a standardised protocol for converting private keys to a set of common words.
Could this be used for public keys too?

[drazvan]

If I understand your idea correctly, you are proposing a standardised protocol for converting private keys to a set of common words.
Could this be used for public keys too?

Yes, it could be used to encode public keys as well - the problem with those is that they're 64 bytes long - so if you use the standard Electrum encoding (3 words for every 32 bits) you end up with 48 words!

What I'm proposing is a way to use the transfer of private keys, in a human-readable format, as transfer of value between parties. They would be used as temporary "vouchers" - so the funds will not be attached to that particular private key for long, they would be immediately transferred to a secure wallet by the recipient. See the thread above for details.

[drazvan]

BTW, the Electrum seed system is useful when you want to encode an existing random private key into a set of words (basically translating chunks of 32 bytes into sets of 3 words). This would require both the sender and the recipient to use the same word list.

However, if the private key is generated by randomly choosing words from the list, a much simpler way is to run the generated phrase through SHA256 or a similar hashing algorithm and use the result of that as the key. This has significant advantages: each party can use its own word list, the word list can be in any language - this could prove useful for non-English speakers, especially in the case of remittances. The downside is that the entropy situation is not as clear (see https://bitcointalk.org/index.php?topic=157820.0 for a discussion). But since the generated PayPhrase is not expected to live more than a few hours/days, it is probably safe enough for the purposes I described here.