Processing a Bitcoin Payment Request

Payments can be made from charity worker to beneficiary, beneficiary to merchant, or merchant to merchant. Merchants could use an existing Bitcoin address, registered and associated with a short Merchant ID by the BPS, used instead of P hP/ P hR in transactions. The SMS payment message flow of the scheme is shown in Figure 8.3 and the notation used in the following descriptions is shown in Table8.2. The security credentials for each entity are shown in Table8.3and the content of each SMS messages used is shown in Table8.4. For simplicity of exposition, the following description shows

Figure 8.3: SMS Payment Message Flow the Head Office (HQ) providing the second Bitcoin key.

Stage 1: Payment Request: The Payer (P) types an SMS which includes payment instructions (PayReq SMS ) in order to make a payment and sends it to the local phone number provided by the charity. The same phone number is used by all the charity workers, beneficiaries and merchants in the geographical area. When the GSM network receives an SMS payment request, it is forwarded to the charity’s BPS via the SMS-Gateway.

Once the message is received, the BPS retrieves Bitcoin wallets for both Payer and Recipient. Following this the BPS checks whether the TrAmt is not greater than BALP, pseudo-randomly generates a three-digit number, unique TrNo and requests for the Payer’s OTP by sending AuthReq SMS.

To generate the OTP, the Payer presses a button on the OTP token. Following this, the Payer sends the Auth SMS containing the newly generated OTP to authorise

Table 8.2: Notation used in Proposed SMS Payment Scheme Notation Description

Addr_X Bitcoin Multi-signature Address for entity X

BPS / P h_X Bitcoin Payment Server(entity) Phone Number of entity X BALX Bitcoin balance in Account ACX for entity X

E_K(Z) Encryption of data Z with key K X→Y Message sent from X to Y

HQ / HQB Head Quarters (entity) / Head Quarters Backup Location (en-tity)

LO / P / R Local Office (entity) / Payer(entity) / Recipient(entity) OT PX One Time Password generated by entity X

P K_X/ SK_X Public/ Secret Key pair of entity X

S_X / TrHash Bitcoin Private Key of entity X (signing key) / Transaction Hash

TrAmt / TrNo Transaction Amount / Transaction Number

TXID Unique Transaction ID of a transaction recorded in the blockchain. Also referred to as the Transaction Hash (TrHash) (Z)Sign_K Signature on data Z with signature key K

TrFee Transaction Fee paid to the Bitcoin miner RawTr Raw Transaction created for signing

ParTr Partial Signed Transaction created after signing RawTr ComTr Complete Signed Transaction created after signing ParTr ReSc Full Redeem Script used for the Bitcoin multi-signature address RSKHash Rootstock Transaction Hash

RSK-Add_SC RSK Smart Contract Address, unique for the contract and never changes

RSK-Add_X−Y RSK public key (RSK address) of entity X kept securely with entity Y

SRSK−X−Y RSK private key of entity X kept securely with entity Y Gas Transaction fee paid to execute instructions on the smart

con-tract

the transaction.

Once the message is received by the BPS, it checks the TrNo to be correct and gen-erates the OT PBP S and compares to the received OT PP. If the two OTPs match, then the BPS checks that the transaction amount TrAmt is not greater than the Payer’s balance BAL_P. If any the above mentioned checks fail, TransDenied SMS is sent to the Payer declining the transaction. If all checks are passed then the BPS proceeds to making a Bitcoin payment, using one of the two proposed options.

Stage 2: Bitcoin Transaction Processing

• Option 1: Multi-signature Process: We now discuss the first method how a

Table 8.3: Credentials Used in Proposed SMS Payment Scheme

Entity Keys and Other Assets

Payer/ Recipient No keys, PIN for phone, HOTP token (no PIN) for making payments

BPS S_{P −BP S},Addr_{P −BP S}, Addr_{R−BP S}, P K_LO, P h_X, OT P_X

HQ S_{P −HQ}, S_RSK−HQ, ReSc

HQB S_{P −HQB}, S_RSK−HQB, ReSc

LO SK_LO, Physical OTP tokens, phone numbers (pay-ers/recipients), plus registration details/ OTP allocation de-tails

Donor SDonor/ VDonor

Donor Platform AddrP roject

Table 8.4: SMS Payment Messages

Message Content

PayReq SMS P h_P, TrAmt, P h_R

AuthReq SMS TrNo, AuthReq

Auth SMS P hP, TrNo, OT PP

TransDenied SMS P hP, TrNo, P hR, Denied

PayConf SMS TrNo,TrAmt, P hR, BALP, TXID RecConf SMS TrNo,TrAmt, P hP, BALR, TXID PayConfRSK SMS TrNo,TrAmt, P hR, BALP, RskHash RecConfRSK SMS TrNo,TrAmt, P h_P, BAL_R, RskHash

Bitcoin transaction in our proposed payment scheme can be processed. To pro-cess the payment request using multi-signature propro-cess, the BPS first constructs a Raw Transaction (RawTr ). The RawTr includes the Full Redeem Script (ReSc), the receiver’s multi-signature address where the payment is going to, TrAmt and TrFee. At least two key holding entities needs to sign the RawTr before a valid transaction to be broadcast to the peer to peer network can be generated. The RawTr is first signed by the BPS using the corresponding Payer’s private key S_P to generate the partially signed transaction (ParTr ). The (ParTr ) is then forwarded to the to the HQ for signing.

BPS→HQ: ParTr = (ReSc,Addr_R,TrAmt,TrFee)Sign_SP

Before authorising the payment request, the ParTr is first verified by the HQ to validate whether the payment amount and the number of signatures needed is correct. After these checks are successfully validated by the HQ, it signs the ParTr using the private Bitcoin key S_{P −HQ} to generate the Complete Signed

Transaction ComTr, which is then sends this back to the BPS.

HQ→BPS: ComTr =(ParTr )Sign_SP−HQ

Once the message is receive, the BPS broadcast the ComTr to the Bitcoin peer to peer network. Once broadcast, in order to trace the particular transaction on the blockchain a unique transaction-id (TXID) can be used. The broadcast transaction is then received by the network of Bitcoin miners and the first miner that published the valid block in the Bitcoin blockchain which also includes the transaction also gets paid the specified transaction fees TrFee for the payment.

The first block that gets added to the blockchain is the first confirmation of the transaction. Before sending the confirmation SMSs, the BPS waits for the transaction to be confirmed in the agreed number of blocks.

• Option 2: Smart Contract Process: The second method to process a Bitcoin transaction in our proposed scheme is by using a smart contract. Here, we extend the capability of the proposed system to show how the Bitcoin multi-signature transaction process can be replaced by a Smart Contract for Bitcoin transac-tion processing. The BPS calls the Smart Contract and authorises the TrAmt and the fee for executing the transaction also called Gas is paid by using the SRSK−P −BP S.

BPS→RSK: RSK-Add_SC,RSK-Add_P,RSK-Add_R,TrAmt,Gas

After the message being broadcast in the RSK network, the HQ or the HQB calls the smart contract. This acts as the second set of instructions needed by the smart contract to execute the transaction. The paid amount TrAmt and the transaction fee Gas is authorised by the HQ/HQB by using the SRSK−P −HQ/HQB.

HQ/HQB→RSK: RSK-Add_SC,RSK-Add_{P −HQ},RSK-Add_R,TrAmt,Gas

The smart contract after successfully receiving instructions from both BPS and HQ/HQB, executes the transaction to transfer the value TrAmt to the recipient.

As a result, unique transaction details related to the transaction are recorded instantly on the RSK blockchain in the format of a hash (RskHash). Transactions are recorded in the RSK blockchain instantly, therefore, the BPS does not need to wait for a transaction confirmation.

Stage 3: Payment Finalisation: Following successful processing of the Bitcoin transaction using one of the methods we discussed above, the BPS updates the payer and the recipient balances. Then the BPS sends confirmation messages via the SMS-Gateway: PayConf SMS or PayConfRSK SMS to the Payer and RecConf SMS or RecConfRSK SMS to the Recipient. Included in the confirmation SMSs are the unique IDs: TXID or RskHash that can be used to trace the transaction on the Bitcoin or the RSK blockchains.

8.6 Analysis

In Section8.5.3we discussed how the proposed SMS-based payment scheme can be used by the charity to provision donations and how it can be used by the beneficiaries to carry out friction-less day-to-day payment transactions in a disconnected environment.

In this Section, we discuss SMS security and analyse the proposed SMS-based payment scheme against the security requirements identified in Section 8.5.2.

A summary of targets that adversaries may attack along with suggested counter-measures is shown in Table8.5.