System and method for enabling trusted digital cryptography based payments betwe en 2 parties engaged in a commerce transaction for physical goods delivery. Crypto-currencies incur very small transaction costs and so are an attractive pa yment mechanism for the Payee. But Once they have paid for the goods, they cannot reverse the payment and so run the risk of the goods not arriving. Proposed solution whereby the multi-signatory features of digital crypto curr ency are used to enable an escrow.
System and method for enabling trusted digital cryptography based payments betwe en 2 parties engaged in a commerce transaction for physical goods delivery. Crypto-currencies incur very small transaction costs and so are an attractive pa yment mechanism for the Payee. But Once they have paid for the goods, they cannot reverse the payment and so run the risk of the goods not arriving. Proposed solution whereby the multi-signatory features of digital crypto curr ency are used to enable an escrow.
System and method for enabling trusted digital cryptography based payments betwe en 2 parties engaged in a commerce transaction for physical goods delivery. Crypto-currencies incur very small transaction costs and so are an attractive pa yment mechanism for the Payee. But Once they have paid for the goods, they cannot reverse the payment and so run the risk of the goods not arriving. Proposed solution whereby the multi-signatory features of digital crypto curr ency are used to enable an escrow.
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 betwe en 2 parties engaged in a commerce transaction for physical goods delivery ABSTRACT The present application describes systems and methods for enabling secure, trust ed 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 pa yment 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 th ere 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 spe cific identity and so there is no way to prove that the payment came from a cert ain actor to another certain actor, only that the actors involved held the corre ct cryptographic keys to enable the transaction. I propose a solution whereby the multi-signatory features of digital crypto curr ency 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 o f 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 delive ry. 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 tr ansmits the transaction to the digital cryptographic currency network. The relea se 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 correc tness of the goods, if at which point they are not satisfied, the transaction ca n go into arbitration or the funds can be rolled back to the Payer there and the n. Negotiation can occur directly between the Payer and Payee, or via the Courier C ompany (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 dispu te resolution. Current cash-on-delivery systems require the Courier to take on risk on behalf o f 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, incorre ct 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 se rvices. 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 b oth increased and reduced risks in the exchange of goods between two parties. Bi tcoin relies on a distributed peer-to-peer network to validate transactions and maintain a cryptographically secure decentralized Blockchain of transactions. Fu nds move between addresses which are not tied to any persons identity. If you are in possession of the cryptographic private key tied to the address, you have th e authority to spend any funds associated with the address. Transactions of this nature cannot be reversed, once said transactions are accepted into the Blockch ain it is cryptographically impossible to reverse back out. Bitcoin addresses are based on a public/private key pair used to authenticate th e address. The address itself is a string of characters for example, mwDCKFdWGpFohottqxk6g4 pqF6DFGKwUZb The address is generated from an algorithm performing a series of hashes and tra nsformations on the public key, such that the public key cannot be recovered fro m simply knowing the address. The private key associated with the public key use d 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 k ey 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, re quiring at least 2 digital signatures. Or it could be a 7 of 7 address, with 7 p ublic 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 seri es 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 t ransferred to the MultiSig address as a standard transaction in the Cryptographi c currency network such as but not limited to the Bitcoin network. At the time o f spending the funds associated with the MultiSig address the transaction must b e signed using the private keys of at least the number of signatories specified in the aforementioned parameter determining the number of digital signatures req uired on the transaction. When generating a MultiSig address for escrow purposes each participant in the e scrow 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 rel eased. The integrity of the public key exchange and agreement process is critical to th e functioning of MultiSig transactions and the level of trust between the partie s involved determines the steps in this process. The present application is conc erned with levels of trust from trustless to full trust and all combinations tha t could present themselves in all relationships between the parties. In the simplest example the Payer, Payee and Courier all have full-trust with ea ch 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 a ddress can be immediately accepted by the other parties as they all have full tr ust. An example of full-trust might be, but is not limited to, a Consumer purcha sing 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 shou ld they maliciously corrupt the key aggregation process could be enough to permi t the parties not to validate that the public keys of the other parties do indee d 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 pa rties 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 validat ed by 1 or many trusted authorities. Any proposal by the aggregator has to be va lidated 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 n o 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 valida tes his own key was the one he provided to the Payee, and contacts the Courier t o 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 fun ds 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 addr ess 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 P ayee and the Payer in an online purchase, the Payee provides a Courier, or a lis t of available Couriers who can support escrow. A multi-digital signature addres s is generated based on 3 public keys provided by the Payee, Payer and the Couri er. 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 c orrectness and condition of the goods can be validated by the Payer with the Cou rier present and if correct the Payer digitally signs a transaction which when s igned by another valid signatory and transmitted to the relevant payment network , will transfer funds from the multi-digital signature address to the Payee. Thi s indicates the Payer is happy with the goods and their condition. The Courier t ransfers the goods to the Payers ownership. The Courier then digitally signs the transaction confirming that the goods have been delivered and transmits the tran saction to the network. The funds are released to the Payee and the success of t he transaction is confirmed. Payee and Courier The Payer is not happy with the goods delivered and so will not digitally sign t he transaction on delivery. The Courier retains possession of the goods and the Payer digitally signs a transaction transferring the funds from the multi-digita l 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 wi th 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 provid es 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 part y 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 th at it has no-trust with, contacts a nominated trusted party and validates that t he proposed keys are genuine, if the keys are not genuine the proposal is reject ed 7. a. If any party rejects the proposal, the process stops b. If all parties ag ree 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 platf orm, 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 go ods 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 cry pto-currencies, such as Bitcoin. 3. Payer selects Courier option Payer selects from a list of Couriers which support the MSE method for the crypt o-currency selected in step (2). The Payee provides a total amount to pay includ ing 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 an d 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-1 6) and provided to the Payer in step (12). The Payer uses the payment network fo r the crypto-currency established as currency for payment in step (2). The transaction is executed from, but not limi ted 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 associat ed 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 rebr oadcast from node to node until it has propagated throughout the network. The tr ansaction 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 t he 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 e lectronically, 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 s teps (4)- (16), the currency of the transaction established in step (2), the amo unt of the transaction established in step (3), the address of the Payee to whic h the funds will be transferred in the event of a completed delivery. The addres s of the Payer to which the funds will be transferred in the event of a failed d elivery. 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) a nd 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 m ade available to the electronic hand held devices carried by the Couriers engage d 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 pers onnel or an application running on a smartphone or tablet device. The handheld d evice requires software able to generate the correct transaction formats to be b roadcast 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. Th e handheld device requires the ability to communicate with another device via protocols such as but not limited to, NFC, Bluetooth, Infra-Red, Mobi le 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 n ot limited to a QR code. The code contains the details of the transaction to rel ease funds from the multi- signatory address established in steps (4)-(16) toget her 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 i n 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 dev ice 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 co mmunicate with other devices via protocols such as but not limited to, NFC, Blue tooth, Infra-Red, Mobile networks, wireless networks. The signing device require s software with the ability to generate and digitally sign transactions in the c orrect format for transmission to networks such as, but not limited to, the Bitc oin 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 smar tphone or tablet device. The signing device requires access to the private key a ssociated 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 co mmunicate with other devices via protocols such as but not limited to, NFC, Blue tooth, Infra-Red, Mobile networks, wireless networks. The signing device require s 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 component s. The transaction to be hashed for signing takes the form of, but is not limited t o: 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 th e 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 th e 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 Payees server via a network connection on th e signing device such as but not limited to the internet. The Data for Payment a nd Data for Signing are loaded onto the respective Device for Signing, the detai ls are confirmed. Method 2 The Payer and Courier connect to the Couriers 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 det ails are confirmed. Method 3 The Courier connects to the Couriers server via a network connection on the signi ng 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 t o 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 a nd Data for Signing are loaded onto the Payers Device for Signing, the details ar e 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 Q R 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 S igning 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 s igning to create a Data for Signing Funds over to Payee on the device. The softwar e 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 pr ivate key to generate a digital signature of the Data for Signing Funds over to P ayee. 4. Payer Transmits Digital signature to Courier The digital signature of the Data for Signing Funds over to Payee is then transfer red to the Couriers Device for Signing using a protocol such as but not limited t o 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 D ata 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 remot e 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 DF SS 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 n etwork 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 th e transaction on the network via a connection such as, but not limited to an int ernet 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 Fu nds over to Payer on the device. The software loads the private key associated wi th 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 signa ture 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 transfer red to the Couriers Device for Signing using a protocol such as but not limited t o 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 D ata 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 remot e 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 Dat a for Signing Funds over to Payer with said private key to generate a digital sig nature 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 n etwork 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 th e transaction on the network via a connection such as, but not limited to an int ernet connection.