Bitcoin Patent

Was going to file this, but would need lawyers to get it accepted, so publishing in the public domain so no-one else can patent it.
-------------------------------------------------------

System and method for enabling trusted digital cryptography based payments between 2 parties engaged in a commerce transaction for physical goods delivery

ABSTRACT
The present application describes systems and methods for enabling secure, trusted transactions between 2 parties for the delivery of physical goods for payment in digital cryptography based currency, such as but not limited to Bitcoin.

Crypto-currencies incur very small transaction costs and so are an attractive payment mechanism for the Payee. Crypto-currency can also not be challenged by the Payer as they can with PayPal or visa and so are attractive for the Payee as there can be no charge-back fraud.

This presents a problem for the Payer purchasing goods of non-delivery from the Payee. Once they have paid for the goods, they cannot reverse the payment and so run the risk of the goods not arriving. Crypto-currencies are not tied to a specific identity and so there is no way to prove that the payment came from a certain actor to another certain actor, only that the actors involved held the correct cryptographic keys to enable the transaction.

I propose a solution whereby the multi-signatory features of digital crypto currency are used to enable an escrow involving actors: the Payer, Payee and Courier. The Courier takes on the dual role of Courier and escrow agent. The payment is held in a multi-signatory escrow address which requires the digital signature of 2 or the 3 aforementioned actors in order to release payment to the Payee- or back to the Payer. The payment is released to the Payee on receipt of the delivery. The Courier does not release the goods to the Payer until he has signed the transaction. After which the Courier also digitally signs the transaction and transmits the transaction to the digital cryptographic currency network. The release of the funds to the Payee account can be confirmed at the point of execution and the transaction is complete.

The opportunity is also provided for the Payer to check the condition and correctness of the goods, if at which point they are not satisfied, the transaction can go into arbitration or the funds can be rolled back to the Payer there and then.

Negotiation can occur directly between the Payer and Payee, or via the Courier Company (in the example of the goods being damaged in transit). As the multi-sig transaction only requires 2 or 3 signatories, this provides flexibility in dispute resolution.

Current cash-on-delivery systems require the Courier to take on risk on behalf of the Payee, the system described in the present application requires no risk on behalf of the Courier and reduces the risk of Payer to non-delivery of, incorrect or damaged goods.


IMAGES
Figure 1. Process Overview
Figure 2. Signing Process
Figure 3. Method of Initiating Transaction
Figure 4. Methods of Loading Data onto the Signing Device
Figure 5. Method of Completing Transaction
Figure 6. Method of Rolling Back Transaction


CLAIMS
DESCRIPTION
COPYRIGHT NOTICE
FIELD OF THE INVENTION
The present invention related to fields of digital crypto-currency and escrow services.

BACKGROUND OF THE INVENTION
SUMMARY OF THE INVENTION
BRIEF DESCRIPTION OF THE FIGURES

DETAILED DESCRIPTION OF THE INVENTION
The emergence of digital cryptographic currency has provided the potential for both increased and reduced risks in the exchange of goods between two parties. Bitcoin relies on a distributed peer-to-peer network to validate transactions and maintain a cryptographically secure decentralized Blockchain of transactions. Funds move between addresses which are not tied to any person’s identity. If you are in possession of the cryptographic private key tied to the address, you have the authority to spend any funds associated with the address. Transactions of this nature cannot be reversed, once said transactions are accepted into the Blockchain it is cryptographically impossible to reverse back out.
Bitcoin addresses are based on a public/private key pair used to authenticate the address.

The address itself is a string of characters for example, mwDCKFdWGpFohottqxk6g4pqF6DFGKwUZb
The address is generated from an algorithm performing a series of hashes and transformations on the public key, such that the public key cannot be recovered from simply knowing the address. The private key associated with the public key used to generate the address is required if funds attached to the
address are to be spent.

The Bitcoin protocol allows for the generation of an address based on multiple key pairs, with a parameter determining the number of digital signatures required on the transaction to spend the funds attached to the address.
This is known as a MultiSig (multi-signatory) address and MultiSig transaction.

A MultiSig, or n of m, address might be a 2 of 3 address, with 3 public keys, requiring at least 2 digital signatures. Or it could be a 7 of 7 address, with 7 public keys requiring 7 digital signatures to spend the funds. Any combination of integers where n<=m.

The MultiSig address itself is generated based on an algorithm performing a series of hashes and transformations on the multiple public keys provided such that the public keys cannot be recovered from simply knowing the address. Funds are transferred to the MultiSig address as a standard transaction in the Cryptographic currency network such as but not limited to the Bitcoin network. At the time of spending the funds associated with the MultiSig address the transaction must be signed using the private keys of at least the number of signatories specified in the aforementioned parameter determining the number of digital signatures required on the transaction.

When generating a MultiSig address for escrow purposes each participant in the escrow must provide a public key from which the address is generated. n number of participants must then digitally sign the transaction in order for it to be released.
The integrity of the public key exchange and agreement process is critical to the functioning of MultiSig transactions and the level of trust between the parties involved determines the steps in this process. The present application is concerned with levels of trust from trustless to full trust and all combinations that could present themselves in all relationships between the parties.

In the simplest example the Payer, Payee and Courier all have full-trust with each other and so can trust any party to aggregate the public keys involved in the transaction. In this scenario the Payee is best suited to be the aggregator of the public keys. The Payee proposal of the public keys to use for the MultiSig address can be immediately accepted by the other parties as they all have full trust. An example of full-trust might be, but is not limited to, a Consumer purchasing from Amazon.com with Fed- Ex as the Courier. The long standing relationship between the three parties and the reputational damage to Amazon and Fed-Ex should they maliciously corrupt the key aggregation process could be enough to permit the parties not to validate that the public keys of the other parties do indeed belong to said parties.

In the other extreme all the parties involved have no trust with any other party that is a signatory on the transaction and so must turn to 1 or many trusted parties to prevent the public key aggregator acting dishonestly or to comply with regulations such as but not limited to, public keys being required to be validated by 1 or many trusted authorities. Any proposal by the aggregator has to be validated by each participant, who in turn validates each key. Once the validation of the keys is in place the process can move on to the next stage.

A more typical scenario would be the Payer has full-trust with the Courier but no trust with the Payee. In this scenario the Payer cannot trust the Payee as the aggregator of the public keys and so must validate the keys provided. He validates his own key was the one he provided to the Payee, and contacts the Courier to confirm that one of the other two keys provided is owned by the courier. Once the validation of the keys is in place the process can move on to the next stage.
It is important to note that any party in possession of the public keys and the parameter NumberOfSignatoriesRequired can derive the actual address that the funds will be transferred to. The present application presents a system whereby any of the participants can function as the key aggregator.

This present application is concerned with a 2 of 3 multi-digital signature address and 2 of 3 multi-digital signature transaction where the participants are a Payee, a Payer and a Courier. Upon the agreement to purchase goods between the Payee and the Payer in an online purchase, the Payee provides a Courier, or a list of available Couriers who can support escrow. A multi-digital signature address is generated based on 3 public keys provided by the Payee, Payer and the Courier. Any funds sent to this address can only be spent by a transaction containing at two digital signatures matching the respective public keys used to generate the address.
Valid combinations would be:

1. Payer and Courier
2. Payee and Courier
3. Payer and Payee

Payer and Courier
The Payer and the Courier are physically present on delivery of the goods. The correctness and condition of the goods can be validated by the Payer with the Courier present and if correct the Payer digitally signs a transaction which when signed by another valid signatory and transmitted to the relevant payment network, will transfer funds from the multi-digital signature address to the Payee. This indicates the Payer is happy with the goods and their condition. The Courier transfers the goods to the Payer’s ownership. The Courier then digitally signs the transaction confirming that the goods have been delivered and transmits the transaction to the network. The funds are released to the Payee and the success of the transaction is confirmed.

Payee and Courier
The Payer is not happy with the goods delivered and so will not digitally sign the transaction on delivery. The Courier retains possession of the goods and the Payer digitally signs a transaction transferring the funds from the multi-digital signature address to the Payer. The Courier returns the goods to the Payee.

Payer and Payee
In the event of the Courier company folding or losing private keys associated with the address, the Payer and the Payee can still authorize the movement of the funds directly

Methods of Key Exchange and Agreement
1. One party is nominated as key aggregator
2. Each party provides a key to the key aggregator and the key aggregator provides his own
3. The key aggregator publishes his proposal for the keys
4. Each party that has full-trust with the key aggregator approves the proposal
5. Each party that has no-trust with the key aggregator contacts each other party that it has full- trust with and validates that the proposed keys are genuine, if the keys are not genuine the proposal is rejected
6. Each party that has no-trust with the key aggregator, for each other party that it has no-trust with, contacts a nominated trusted party and validates that the proposed keys are genuine, if the keys are not genuine the proposal is rejected
7.  a. If any party rejects the proposal, the process stops b. If all parties agree on the proposal the process continues

Method of initiating transaction
See diagram 1

1. Payer selects goods
The goods available for purchase can be selected on any kind of e-commerce platform, be it a website or software application running on any technology platform, such as a web server or a smart phone. The Payee totals up the amount of the goods and provides the Payer with a pre- total for the goods.

2. Payer selects payment option
The Payer selects to pay with a crypto-currency based on a list of available crypto-currencies, such as Bitcoin.

3. Payer selects Courier option
Payer selects from a list of Couriers which support the MSE method for the crypto-currency selected in step (2). The Payee provides a total amount to pay including any taxes and Courier fees applicable.

4- 16. Public keys are agreed upon as per Methods of Key Exchange and Agreement. Each party now has a record of the public keys to be used in the transaction and can derive the MultiSig address.

17. Payer makes payment to multi-digital signature address
The Payer makes the correct payment amount established in step (3) to the multi-digital signature address derived from the public keys established in steps (4-16) and provided to the Payer in step (12). The Payer uses the payment network for the crypto-currency established as
currency for payment in step (2). The transaction is executed from, but not limited to, a wallet stored directly on a device owned by the Payer, a wallet hosted by a third party on behalf of the Payer, payment functionality provided by the Payee which may or may not utilize a third party that hosts the wallet  associated with the Payers addresses. The transaction will be broadcast to the network, such as but not limited to the Bitcoin network via a participating node and rebroadcast from node to node until it has propagated throughout the network. The transaction will subsequently be included in the Blockchain and can be verified by anyone with access to said Blockchain. In crypto-currencies such as Bitcoin the Blockchain is readable by anyone in the world with suitable tools or technology.

18. Payee confirms payment to multi-digital signature address
The Payee verifies that the transaction is present in the Blockchain and is of the correct amount agreed on in step (3). ? what if correct funds do not arrive?

19.
a. Payee requests dispatch from Courier
The Payee creates a dispatch request for the Courier and transmits the details electronically, including details of physical delivery address
b. Payee transmits details for payment release to the Courier
The Payee provides details required for payment release. The script created in steps (4)- (16), the currency of the transaction established in step (2), the amount of the transaction established in step (3), the address of the Payee to which the funds will be transferred in the event of a completed delivery. The address of the Payer to which the funds will be transferred in the event of a failed delivery. The data is transmitted electronically using protocols such as, but not limited to, a web service hosted by the Courier or via electronic mail such as, but not limited to email or text message.

20. Courier stores against dispatch record
The Courier receives the dispatch request initiated by the Payee in step (19a) and stores the transaction data received in step (19b) in a suitable database or data storage device.

21. Transaction Details are Transmitted to Devices The transaction details are made available to the electronic hand held devices carried by the Couriers engaged in the physical delivery of the goods. These handheld devices such as, but not limited to custom devices such as “STAR II/III” devices used by FedEx delivery personnel or an application running on a smartphone or tablet device. The handheld device requires software able to generate the correct transaction formats to be broadcast to the network, connectivity to networks such as but not limited to the internet, in order to connect to broadcast the transaction, software libraries to facilitate the communication protocols with the crypto- currency networks. The handheld device requires the ability to communicate with another
device via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks.

22. Payee generates shipping label with scan-able transaction details
The Payee prints a shipping label which includes a scan-able code, such as but not limited to a QR code. The code contains the details of the transaction to release funds from the multi- signatory address established in steps (4)-(16) together with the currency established in step (2), the amount established in step (3) and the address to release the funds to upon successful delivery established in step (19b). The standard details normally included in shipping labels are also included, such as, but not limited to name, address of recipient.

23. Courier ships goods

The Courier ships the goods to the physical address established in step (19a)
We define the following components:

Payer Signing Device: such as but not limited to a smartphone or tablet running an application provided by the Courier company or a third-party. The signing device requires the ability to scan a code such as but not limited to a QR code via a camera or other device. The signing device requires access to the private key associated with the public key used in the Payer component of the multi-digital signature generated in step (10). The signing device requires the ability to communicate with other devices via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks. The signing device requires software with the ability to generate and digitally sign transactions in the correct format for transmission to networks such as, but not limited to, the Bitcoin network.


Courier Signing Device: such as but not limited to custom devices such as “STAR II/III” devices used by FedEx delivery personnel or an application running on a smartphone or tablet device. The signing device requires access to the private key associated with the public key used in the Courier component of the multi-digital signature generated in step (10). The signing device requires the ability to communicate with other devices via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks. The signing device requires software with the ability to generate and digitally sign
transactions in the correct format for transmission to networks such as, but not limited to, the Bitcoin network.

Data for Signing:
The data can be, but is not limited to be, a hash of a transaction representing the transaction to be transmitted to the network, minus its signed key components.
The transaction to be hashed for signing takes the form of, but is not limited to:

1. Data for signing funds over to Payee

TransactionId
Inputs
 TransactionToSpend
 TransactionOutputToSpend
 MultiSig Script established in step (10)
Outputs
 AddressOfPayee established in step (15b)
 Amount established in step (3)

2. Data for signing funds over to Payer

TransactionId
Inputs
 TransactionToSpend
 TransactionOutputToSpend
 MultiSig Script established in step (10)
Outputs
 AddressOfPayer established in step (15b)
 Amount established in step (3)
Data for Payment to Payee:
The data can take the form of, but not limited to be a transaction containing the following:
TransactionId
Inputs
 TransactionToSpend
 TransactionOutputToSpend
 Signed DFSS by Payer
 Signed DFSS by Courier
 MultiSig Script established in step (10)
Outputs
 AddressOfPayee established in step (15b)
 Amount established in step (3)
Data for Payment to Payer:
The data can take the form of, but not limited to be a transaction containing the following:
TransactionId
Inputs
 TransactionToSpend
 TransactionOutputToSpend
 Signed DFBS by Payer
 Signed DFSB by Courier
 MultiSig Script established in step (10)
Outputs
 AddressOfPayer established in step (15b)
 Amount established in step (3)

Methods of loading data onto a Signing Device

Method 1
The Payer and Courier connect to the Payee’s server via a network connection on the signing device such as but not limited to the internet. The Data for Payment and Data for Signing are loaded onto the respective Device for Signing, the details are confirmed.

Method 2
The Payer and Courier connect to the Courier’s server via a network connection on the signing device such as but not limited to the internet. The Data for Payment and Data for Signing are loaded onto the respective Device for Signing, the details are confirmed.

Method 3
The Courier connects to the Courier’s server via a network connection on the signing device such as but not limited to the internet. The Data for Payment and Data for Signing are loaded onto the respective Device for Signing, the details are confirmed. The Courier transmits Data for Payment and Data for Signing details to the Payers Device for Signing via a protocol such as but not limited to, NFC, Bluetooth, Infra-Red, Mobile networks, wireless networks. The Data for Payment and Data for Signing are loaded onto the Payer’s Device for Signing, the details are confirmed.

Method 4
The Payer and Courier utilize an image reading device such as but not limited to a camera to scan the code printed on the package such as but not limited to a QR code. The Data for Payment and Data for Signing are loaded onto the respective Device for Signing, the details are confirmed.
Method of completing transaction

1. Payer loads transaction details using one of Methods of Loading Data onto a Signing Device

2. Courier loads transaction details using one of Methods of Loading Data onto a Signing Device

3. Payer Digitally signs Transaction The Payer uses software on the device for signing to create a “Data for Signing Funds over to Payee” on the device. The software loads the private key associated with the public key established in step (4). The software digitally signs the “Data for Signing Funds over to Payee” with said private key to generate a digital signature of the “Data for Signing Funds over to Payee”.

4. Payer Transmits Digital signature to Courier

The digital signature of the “Data for Signing Funds over to Payee” is then transferred to the Courier’s Device for Signing using a protocol such as but not limited to NFC, Bluetooth, Infra- Red, Mobile networks, wireless networks.

5. Courier receives and verifies the digital signature
Courier receives and verifies the digital signature of the “Data for Signing Funds over to Payee” transmitted by the Payer and stores said digital signature of the “Data for Signing Funds over to Payee” in a database or suitable data storage device located on, but not limited to be located on, the Device for Singing or a remote database connected via the Internet.

6. Courier Digitally signs Transaction
The Courier uses software on the device for signing to create a “Data for Signing Funds over to Payee” on the device. The software loads the private key associated with the public key established in step (8). The software digitally signs the DFSS with said private key to generate a digital signature of the “Data for Signing Funds over to Payee”.

7. Courier generates Data for Payment to Payee
The Courier uses software on the device for signing to create a Data for Payment to Payee on the device.

8. Courier Transmits Transaction to network
The Courier uses software on the device for signing to connect to the relevant network for the crypto-currency established in step (2) and transmits the data to the network via a connection such as, but not limited to an internet connection.

9. The Transaction is confirmed to have arrived on the network.

The Courier uses software on the device for signing to confirm the arrival of the transaction on the network via a connection such as, but not limited to an internet connection.
Method of rolling back transaction
Method of Immediate Rollback

1. Customer loads “Data for signing funds over to Payer” details using one of “Methods of Loading Data onto a Signing Device”

2. Courier loads “Data for signing funds over to Payer” details using one of “Methods of Loading Data onto a Signing Device”

3. Payer Digitally signs Transaction

The Payer uses software on the device for signing to create a “Data for Signing Funds over to Payer” on the device. The software loads the private key associated with the public key established in step (4). The software digitally signs the “Data for Signing Funds over to Payer” with said private key to generate a digital signature of the “Data for Signing Funds over to Payer”.

4. Payer Transmits Digital signature to Courier

The digital signature of the “Data for Signing Funds over to Payer” is then transferred to the Courier’s Device for Signing using a protocol such as but not limited to NFC, Bluetooth, Infra- Red, Mobile networks, wireless networks.

5. Courier  receives and verifies digital signature

Courier receives and verifies the digital signature of the “Data for Signing Funds over to Payer” transmitted by the Payer and stores said digital signature of the “Data for Signing Funds over to Payer” in a database or suitable data storage device located on, but not limited to be located on, the Device for Singing or a remote database connected via the Internet. 6. Courier Digitally signs Transaction

The Courier uses software on the device for signing to create a “Data for Signing Funds over to Payer” on the device. The software loads the private key associated with the public key established in step (8). The software digitally signs the “Data for Signing Funds over to Payer” with said private key to generate a digital signature of the “Data for Signing Funds over to Payer”.

7. Courier generates “Data for Payment to Payer”

The Courier uses software on the device for signing to create a “Data for Payment to Payer” on the device.

8. Courier Transmits Transaction to network

The Courier uses software on the device for signing to connect to the relevant network for the crypto-currency established in step (2) and transmits the data to the network via a connection such as, but not limited to an internet connection.

9. The Transaction is confirmed to have arrived on the network by the Payer and Courier

The Courier uses software on the device for signing to confirm the arrival of the transaction on the network via a connection such as, but not limited to an internet connection.