[BIP][Draft] Transaction Signing via QR Codes

[songchenwen]

Request for discussion

BIP: Transaction Signing via QR Codes

Reference text :
https://github.com/bither/bips/blob/master/unsigned_transaction.md

Code:

Title: Transaction Signing via QR Codes
Author: Song Chenwen, Bither Team
Type: Standards Track
Created: 2014-9-6

Abstract

This BIP describes a way to sign Bitcoin transactions via QR Codes.
Let us suppose we have two devices here. One can build and send transactions. And the other has the private key to sign transactions.
We defined a format to send unsigned transactions via QR Codes to the later, and send signed transactions back to the former.

Motivation

In this way, the Bitcoin private keys can be stored away from network connected devices. This is the safest way to store private keys. And via QR Codes, the user can still spend bitcoins belonging to these private keys.
It is easier for different online and offline clients to communicate with each other, if they all follow one common protocol of QR Codes content format.

Process

There are two roles in this signing process, "HOT" for the online device which has the private key's transaction history and unspent transaction outputs, "COLD" for the offline device which hold the private key.

• 1. HOT generats a transaction based on the unspent transaction outputs. But it can't sign the transaction.
• 2. HOT converts the information needing to be signed in the unsigned transaction into formated signable QR Codes. HOT displays the QR Codes.
• 3. COLD scans HOT's screen and gets the signable information.
• 4. COLD finds the right private key that the signable information requires.
• 5. COLD signs the signable information using the private key.
• 6. COLD converts the signed information to formated QR Codes and displays them.
• 7. HOT gets the signed information and attach it onto the unsigned transaction.
• 8. HOT verifies if the transaction is correctly signed. The transaction will be spread to other peers if it passes the verification.

Format

HOT and COLD can understand each other only by restricting the QR Codes they provide to a certain format protocol.
The protocol goes below.

Unsigned Information

Since We need to prove we own the private key which the unsigned transactions inputs have been sent to, so we need the inputs to be signed.
And COLD need some information to ask the user if he likes to sign the transaction.

Following parts are joined and seperated by colon to make an unsigned QR Codes content.

• The address used to send bitcoin from
• The transaction fee
• The address to receive bitcoin
• The amount of bitcoin being sent (not including transaction fee)
• Sha256 hash byte arrays of all the transaction inputs seperated by colons which is in hex string format

source code

Signed Information

After COLD signs the transaction's inputs, it builds the input scripts based on the ECDSA signactures.

COLD convert all the input scripts to hex strings and join them with colon as separator.
This joined string will be the content for the signed QR Codes.

source code

Optimization for QR Code

According to Information capacity and versions of the QR Code, one QR Code can serve more content if it only contains uppercased letters, digits and some kinds of punctuations, so we can optimize our content.

Following rules are applied to the content.

• All byte array hex strings only use uppercased letters (source code)
• Uppercased letters in addresses are transformed to * followed by the letter. e.g. A -> *A . And then all the letters are transform to uppercased. In this way, our donation address: 1BsTwoMaX3aYx9Nc8GdgHZzzAGmG669bC3  is transformed to  1*BS*TWO*MA*X3A*YX9*NC8*GDG*H*ZZZ*A*GM*G669B*C3. (source code)
• Amounts of bitcoins are represented by uppercased hex strings for the count of satoshis.

QR Code Pagination

One transaction can contain multiple inputs. Therefore the content of unsigned or signed information can be too long to be displayed in one QR Code.
A QR Code in a limited graphic size with too much information can be too hard to scan.
So we need a way to paginate the QR Codes.

The length of one QR Code's content can vary with different graphic size. We find 328 to be a suitable content length to be displayed and easily scanned on mobile phones.

When we need multiple pages of QR Codes. We add (Total page count minus 1):(current page index starts from 0): in front of every page. e.g. QR Code Page 1 in 3 pages will be prefixed with 2:0:.

source code

[1714717228]

1714717228

[1714717228]

1714717228

[amaclin]

3. COLD scans HOT's screen and gets the signable information.
...
7. HOT gets the signed information and attach it onto the unsigned transaction.

This means that COLD is connected to a network by very slow and specific interface  
If I have full access to HOT - I can create and display QRCode on screen aaaaand... sign transaction!

One transaction can contain multiple inputs. Therefore the content of unsigned or signed information can be too long to be displayed in one QR Code.
A QR Code in a limited graphic size with too much information can be too hard to scan.
So we need a way to paginate the QR Codes.

In fact, to sign one input you should transfer 32-byte digest and publicKey(address) from HOT to COLD. Not much data
The signature is ~72 bytes (can be easy compressed to 64 bytes). This should be transferred back from COLD to HOT

[songchenwen]

I proposed this BIP in response to this reply on reddit

[songchenwen]

3. COLD scans HOT's screen and gets the signable information.
...
7. HOT gets the signed information and attach it onto the unsigned transaction.

This means that COLD is connected to a network by very slow and specific interface  
If I have full access to HOT - I can create and display QRCode on screen aaaaand... sign transaction!

One transaction can contain multiple inputs. Therefore the content of unsigned or signed information can be too long to be displayed in one QR Code.
A QR Code in a limited graphic size with too much information can be too hard to scan.
So we need a way to paginate the QR Codes.

In fact, to sign one input you should transfer 32-byte digest and publicKey(address) from HOT to COLD. Not much data
The signature is ~72 bytes (can be easy compressed to 64 bytes). This should be transferred back from COLD to HOT

1. When you have full access to HOT and you have physical access to COLD, you will be able to do anything you want. This is the rule of physical world.

2. But one transaction may contain more than one inputs. There is always a chance the content overflow QR Code's limit.

[amaclin]

1. When you have full access to HOT and you have physical access to COLD, you will be able to do anything you want. This is the rule of physical world.

So, what the reason to split HOT and COLD?

2. But one transaction may contain more than one inputs. There is always a chance the content overflow QR Code's limit.

COLD computer may know nothing about bitcoin, transactions and all other stuff. It is key-holder and tx-signer in your case.
The only things it can do are
a) scan QR-code
b) decode it to a pair ["pubkey", "digest"]  ("pubkey" - is an address or another hash function)
c) locate the private key in internal storage for the given pubkey
d) sign the digest
e) create QR-code for signature and display it

Let's put all transaction assembling logics (in case of several inputs) on HOT device.

[songchenwen]

1. When you have full access to HOT and you have physical access to COLD, you will be able to do anything you want. This is the rule of physical world.

So, what the reason to split HOT and COLD?

2. But one transaction may contain more than one inputs. There is always a chance the content overflow QR Code's limit.

COLD computer may know nothing about bitcoin, transactions and all other stuff. It is key-holder and tx-signer in your case.
The only things it can do are
a) scan QR-code
b) decode it to a pair ["pubkey", "digest"]  ("pubkey" - is an address or another hash function)
c) locate the private key in internal storage for the given pubkey
d) sign the digest
e) create QR-code for signature and display it

Let's put all transaction assembling logics (in case of several inputs) on HOT device.

HOT and COLD are split for safety reason.

[luv2drnkbr]

You could also add a security feature where hot and cold both have stealth keys (or some other public key to generate a shared secret), and the QR data is encrypted with shared secret, so that for example the unsigned QR message from HOT doesn't get compromised en route on its way to COLD.

[amaclin]

so that for example the unsigned QR message from HOT doesn't get compromised en route on its way to COLD.

It is not a problem. Message digests and signatures are not critical part in cryptography. Private keys are.
http://en.wikipedia.org/wiki/Byzantine_fault_tolerance

[onchain.io]

Hi. Onchain.io has support for signing transactions via QR codes.

You can see the code and some screenshots of the app here. https://github.com/onchain/onchain-android

It would be good if the BIP followed the existing protocol.

Let me know what you think.

[songchenwen]

Hi. Onchain.io has support for signing transactions via QR codes.

You can see the code and some screenshots of the app here. https://github.com/onchain/onchain-android

It would be good if the BIP followed the existing protocol.

Let me know what you think.

Bither was made half a year before.

So when you mention existing protocol, we should consider Bither's.

[jl2012]

This simple idea is obviously not new but no one tries to implement it. It is because the "COLD" cannot calculate the transaction fee without first knowing the full details of the inputs. You will need lots of qr codes to do this.

If you omit this, a malicious or buggy "HOT" could trick the "COLD" to pay a huge amount of transaction fee.

Learn more: https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki

[songchenwen]

This simple idea is obviously not new but no one tries to implement it. It is because the "COLD" cannot calculate the transaction fee without first knowing the full details of the inputs. You will need lots of qr codes to do this.

If you omit this, a malicious or buggy "HOT" could trick the "COLD" to pay a huge amount of transaction fee.

Learn more: https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki

1. Modern operating systems on mobile phones like iOS and Android run apps in sandboxes. One app can hardly become malicious if the user has not rooted or jailbroke his device.

2. The hacker who do his best effort to get control over HOT can not benefit directly from his work. He can only give the miners more bitcoins but leave no extra income for himself.

[jl2012]

This simple idea is obviously not new but no one tries to implement it. It is because the "COLD" cannot calculate the transaction fee without first knowing the full details of the inputs. You will need lots of qr codes to do this.

If you omit this, a malicious or buggy "HOT" could trick the "COLD" to pay a huge amount of transaction fee.

Learn more: https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki

1. Modern operating systems on mobile phones like iOS and Android run apps in sandboxes. One app can hardly become malicious if the user has not rooted or jailbroke his device.

2. The hacker who do his best effort to get control over HOT can not benefit directly from his work. He can only give the miners more bitcoins but leave no extra income for himself.

If a sandbox is so safe you don't even need a cold wallet.

How about a bug in the HOT?

And in your protocol you say "transaction fee" will be part of the QR code. You should realize that's completely pointless if you understand the bitcoin protocol. You make the users feel like they could endorse the amount tx fee while they actually couldn't. That's very misleading.

This defeats the purpose of using cold wallet. Please do not develop snake oil bitcoin wallet which people will put their real money in.

Unfortunately Satoshi did not consider this and we can't fix this without a fork. This has been discussed before: https://bitcointalk.org/index.php?topic=181734.0

[jiangjiazhi]

Why jl2012 hate cold wallet? hahaha

[jl2012]

Why jl2012 hate cold wallet? hahaha

I do recommend cold wallets, robust ones, like Armory

[jiangjiazhi]

lol, good luck to jl2012  

[zhouqi_cn]

I do recommend cold wallets, robust ones, like Armory

If you get a "malicious"/"bug" Armory, how can you protect your bitcoins? With your "robust"?

[jl2012]

I do recommend cold wallets, robust ones, like Armory

If you get a "malicious"/"bug" Armory, how can you protect your bitcoins? With your "robust"?

Armory is open source with a good dev team. They have a correct security mindset (BIP10 is written by Alan). The cold Armory wallet put no trust in the hot one.

Anyway, we already have BIP10. If one wants to use QR code with BIP10, it's straightforward.