Basically, the Bitcoin Cheque is a file promising that the its issuer will pay a certain amount to the holder.
In order the make usage of Bitcoin Cheque possible, certain standards and protocols must be defined. This is a description of the Bitcoin Cheque Standard.
The purpose of the Bitcoin Cheque is to define a financial building block that can be used in Bitcoin payments and overcome some of the limitation Bitcoin has.
The Payment Cheque Specifications based upon the following requirements and premises:
- The cheque must be able to hold any currency
- both as defined by ISO 4217;
- and commonly used by the crypto-currency com community.
- The cheque must be an item independent from the payment protocol
- It must be possible to store the cheque as a file for later usage.
- It must be possible to give the cheque to others by using the protocols outlined at Bitcoin Cheque project, or by sending the file by e-mails or other data transferring mechanisms, or by printing it on paper.
- The cheque data shall be stored in JSON format. The whole JSON structure shall be encoded in Base64, for easy data transmit. This will also allow a check file to be copied and pasted as text.
- The cheque shall have an Serial Number and Access Code. It shall be possible for a user to collect the cheque’s money from its issuing bank by knowing the cheque’s Serial Number and Access Code. (Provided that the bank offer such service.)
- The cheque file shall contain a hash calculation of its information.
- The cheque shall have field for a bank to sign it using the bank’s private key. The sign shall be made from the hash.
- It shall be permitted and safe to give the cheque’s has, digital signature and its issuing bank URL address (so that the bank’s public key can be obtained) to third party. Since the signature is made from the hash, the third party can verify the cheque. This way a third party can receive financial information without having the Access Key to steal the cheque’s money or knowing anything else about the payer, but what has voluntarily being sent by others.
- The cheque shall include a money-back feature. (A service that in practice will be offered by a bank.)
- Have the ability to be crossed, i.e. the cheque’s money can only be collected by the assigned receiver (This is currently being refereed to as “Locked” in the texts and drafts of the standard.)
The specification document
Below is the current draft of the specification. It can also be found on Github:
Payment Cheque Specification v0
This document defines the specification for a Payment Cheque. The Payment Cheque is a note promising that its issuer will pay a certain amount to a receiver at some predefined conditions. The Payment Cheque is constructed to be flexible and can hold any currencies. The cheque can be sent using Payment Protocol and it can be saved to a file and sent as an attachment in an e-mail.
During this specification the following terminology has been utilized.
2 Data fields
This chapter defines the information in a Payment Cheque data fields.
The cheque's information is organized in data structures, which again can contains other data structures and data fields.
Each data field and data structure are listed in tables in the following sections. The tables have the following columns with information:
2.1 Data structures
2.1.1 Root structure
The Payment Cheque has the following data fields.
2.1.2 ChequeData data structure
The ChequeData field contains a JSON encoded string made of a strucutre.
The structure has the following fields:
2.1.3 MetaData data structure
This structure contains various fields to identify the type of this cheque.
2.1.7 Condition data structure
This data structure holds conditions that must be meet in order for the cheque receiver to collect the amount value hold by the cheque.
2.1.4 IdField data structure
A IdField data structure holds information that can be used to identifies the parties involved in the cheque payment.
The IdFields data type is a structure consisting of the following fields:
2.1.5 Hash data structure
The Hash data type holds the hash value of the ChequeData field.
The ChequeData shall be stored as JSON encoded string and the hash shall be calculated of this string.
2.1.6 Signature data structure
The Signature data structure holds digital signature of the hash.
2.2 Data types
Integers are both positive and negative.
Strings shall be UTF-16 encoded.
The size indicates number of characters that the field must be able to store. As UTF-16 encoded characters use 2 bytes, the actual data storage needed in bytes is twice the size.
2.2.3 DateTime data type
This type holds a date and time in string format.
Format is YYYYMMDDhhmmss.
2.2.4 HashAlgorithm data type
2.2.5 SigAlgorithm data type
3 File format
3.1 Data encoding
The Root Structure including all its sub-structures and fields are first encoded to JSON string and then encoded using base64.
Integers are stored as integer number type in the JSON string.
Base64 encoding shall be according to RFC 4648.
The base64 encoded string shall be stored using UTF-8 character encoding when saved as a file.
3.2 File prefixing
The base64 encoded string may optionally be prefixed with a text string. The purpose of the file prefix is to include a human readable text that helps identifying the content of the file.
If a file prefix is included it is recommended that it starts with the text "PAYMENT_CHEQUE".
The file prefix can include additional issuer specific texts.
The prefix text must consist of UTF-8 encoded character in range from 0x21 to 0x7E. Space character is not permitted. It is recommended to use underscore character in the need to separate words.
When using letters, it is recommended to only use uppercase.
The file prefix text and the base64 encoded data part must be separated with a colon character (:). When processing a file, it shall be possible to use this colon character when searching for the encoded part.
If a file prefix is included, the data field FilePrefix in the MetaData structure must be included and populated with the same prefix text. (The colon character between the file prefix text and the encoded data part is not included in the FilePrefix field.)
3.3 File name extension
When saved as a file the Payment Cheque shall have ".pcf" as extension.
4 Description of usage
Issuance is the process of creating a Payment Cheque and giving it to somebody else. Once the cheque is given to somebody else, it is expected that the issuer will fulfill the promise of paying the cheque's face value to the first whoever meets its stated condition.
When the cheque is created, all data mandatory structures and data fields must be created and populated with valid data.
Optional data structures and data fields can be created if required by the purpose of the cheque. If a optional data structures or data field is created, it shall be populated with valid data.
It is highly recommended that the cheque's field does not change or fields created after issuance. Hence all field expected to be needed to fulfill the purpose of the cheque must be prepared and populated.
4.2 Payment condition
The condition structure field may contain one or more condition that decides where the claimed money will be put.
If this structure contains more than one conditions, then all conditions must be meet to claim the cheque. Note that some combinations of conditions may be contradictory and impossible to meet. It will be up to the cheque issuer to ensure that no such contradictions are present.
4.3 Cheque claiming and money collecting
For a Cheque Receiver to get the promised money of a Cheque, two procedures will be needed.
First, the receiver must claim the cheque. The claim must be conducted within the cheque's Expire Time. If the cheque has any conditions field, all conditions must be verified within the the expiration time.
Once a receiver has claimed a cheque and all conditions has been meet, the cheque is claimed and can not be claimed or paid to other.
After the cheque has been claimd, its promised money can be collected. The collection must be conducted after the Escrow Time but before the Pay Time.
When claiming and collecting a cheque, its Access Code and Hash should be shown to the bank as evidence that the reciever actual has the cheque.
The Pay Time will give a cheque receiver the ability to bundle and transfer money from several cheques in one transaction. This will recieve transaction costs. However, the bank shall not be expected to hold the money for a longer pariod after the Hold Time. After Hold Time the bank can make the money transaction to the receiver's address without prior notice.
The claim and collect procedure can be done in one single operation. This will be for the bank to implement. In any case, the actual money transaction should not take place before the Escrow Time as passed.
4.4 Money back-guarantee
The Escrow filed indicates when the cheque's money can first collected, that is payd out the receiver.
Due to the Escrow Time, the cheque's promised money will be hold back by the bank for a certain time. This will give the customer (Cheque Payer) and the bank a reasonable time to evaluate if a merchant (Payment Receiver) has meet his part of a deal. In case the merchant has not meet the deal, the customer can fill in a complain to the bank and request the cheque to be canceled.
The process of handling a complain and decide whatever a cheque will be canceled or not, or maybe only be paid partially, will be for the bank to decided. That process is out of scope of this specification.
4.5 Information to receiver
The cheque has two fields that can be used to give information to a receiver.
4.6 Indentifications of parties
The cheque has tree data structure fields for identifying each of the parties involved in a cheque payment, the Cheque Issuer, the Cheque Payer and the Cheque Receiver.
The identification structures has field to identify a party by post/office address, web address, e-mail address.
Jurisdictions may require these field to be set. It will be the Cheque Issuer that will be responsible to ensure the correctness of this information.
4.7 Fees and transaction costs
Operating a payment system is not without costs and eventually somebody will have to pay for these services.
The cheuqe has two fee fields that have the following purposes:
Obviously, the cheque's face value must be large enough to cover the fixed fee. However, it does not be large enough to cover the transfer fee.
The fees may also be paid partially or completely by the Cheque Payer. In the case where the Cheque Receiver will not be required to pay any fees, these fields can be omitted.
A model for cost coverage and fees will be up to the bank to decide.
The cheque has several in-built security features to prevent cheque fraud and to prevent a cheques to get in the wrong hands and prevent misuse of the system. One or several of these security mechanism may be utilized, depending on the circumstances and the value of the cheque.
4.8.1 Hash and signature
The Hash is calculated from the Cheque Data field. The signature is calculated from this hash.
By having the bank's public signature, a Cheque Receiver can verify the cheque is correct and valid. It is recommended that a Cheque Receiver always fist verifys the integrity of the cheque before claiming it. This is to prevent the receiver to unawarely participate in a DoS attack, repeatedly claiming no-existing cheques sent by criminals.
4.8.2 Access Code
For a Cheque Receiver to claim and collect the cheque, he must have the Access Code. In practice also the Cheque's Serial Number will also be needed provided. The Access Code should be of certain length to prevent brute force attack.
In the case where user is manually claiming a cheque at the banks webpage, a combination of Access Code together with other techniques like captcha, should make a system resistant enough against brute force attack.
Additional to the Access Code, one or more conditions may be required.
If no condition is required, than anybody having the cheque's Serial Number and Access Code can claim and collect the cheque. In some situations, this may be the purpose and then it is all fine to leave the condition structure empty.
By adding condition, this will effectively prevent a stolen cheque to be collected and have its money put in a criminals account.
If only the Wallet field is added, a stolen cheque can still be claimed and collected by the thief, but the money can still only be put into the predetermined wallet.
4.9 Distributing financial information
The cheque's hash can be verified by having the cheque's signature and its issuing bank's public key. This makes it possible to verify that a cheque exists without having the rest of the details.
Any of the parties involved in a cheque payment, can transmitt the cheque's hash, signature and the bank's address (so the bank's public key can be obtained) to a third party. Additional cheque information like serial number, amount and currencies can also be sent. To verify the additional information, the third party will need to contanct the cheque's issuer. The hash can act as a key to access the bank and verify the additional information. (The MoneyAddress interface supports such verifications.)
This system will allow two levels of access rights to a cheque. By having both the Hash and Access Code, a suer has full access to the cheque and can claim and collect the money. By having only the Hash, a user will only have limited access like verifying the additional sent information.
This feature makes it possible to safely distribute payment information to third parties. These could be statiscical service, payment insurance, payment advisory etc.