You are on page 1of 9

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.

You might also like