Beginning
Principles
Development
Repositories

BitDust Merchants

(draft proposal)

NOTE: The Merchant role is not implemented yet. This is an alternative to the Miner role described in the Roles and Coins draft.

Who ?

  • customer
  • supplier
  • merchant

How ?

Merchant

  • the customer finds a random merchant via DHT
  • the merchant receives BTC from the customer via BTCPay Server integrated with the BitDust software
  • the merchant pays the supplier from their BTC wallet integrated with the BitDust software
  • the customer's balance is "accounted" by the merchant - the customer must select one single merchant
  • suppliers of that customer can "claim" money from that "merchant" after the contract is completed

Contract

  • the customer and the supplier first agree on "contract conditions" before starting "the deal" with each other
  • the contract must define the duration and amount of storage
  • a contract can only be started when the customer has enough balance on their account (with a particular merchant)
  • a contract can only be started or completed when both the customer and the supplier are online at that moment and able to communicate p2p

Secret code A

  • the process is initiated by the supplier
  • the supplier prepares the contract details of the deal with the customer
  • first, secret code A is generated by the supplier and recorded locally
  • then the supplier encrypts code A with their own public key
  • the contract details are merged with the encrypted copy of A and signed with the supplier's private key
  • the signed contract info (with encrypted code A) is sent to the customer
  • the customer records code A locally - they do not know A, only the encrypted copy of A

Secret code B

  • now the customer generates a second secret code B and records it locally
  • then the customer encrypts code B with their own public key
  • the customer attaches the encrypted codes A and B to the contract description received from the supplier
  • the customer signs that merged info with their own private key and sends it to the supplier
  • the supplier verifies the signature with the customer's public key and records the second code B locally
  • the supplier does not know the original code B, only the encrypted copy of B

Proof of beginning

  • now both sides have proof that the "contract was started" - but only if they show the decrypted (original) codes
  • the supplier sends that info to the merchant, and the merchant records it locally and also remembers the moment in time
  • the merchant stores the contract description with encrypted codes A and B signed by both parties

Contract confirmation

  • the merchant verifies both signatures of the customer and the supplier and the contract conditions (current world time)
  • the merchant requests the original code A from the supplier
  • the merchant requests the original code B from the customer
  • once both codes are provided, the merchant can verify them against the encrypted codes received from the supplier earlier
  • the merchant uses the customer's public key to encrypt the original code B and compares it with the info received from the supplier
  • the merchant uses the supplier's public key to encrypt the original code A and compares it with the info received from the supplier
  • now the contract is confirmed by the merchant and begins - the merchant has received "the proof" from both sides that the contract has started

Contract fulfillment

  • the supplier must follow the contract and provide resources and services to the customer
  • both sides count time from the beginning of the contract
  • when the contract time has elapsed, the supplier again begins the process to complete the contract
  • a process similar to the one for codes A and B is triggered again between the customer and the supplier
  • it is again initiated by the supplier, who expects the customer to be online at that moment

Secret code C

  • a third secret code C is generated by the supplier and recorded locally
  • the supplier encrypts code C with their own public key and sends it to the customer
  • the customer records code C locally - they do not know C, only the encrypted copy of C

Secret code D

  • a fourth secret code D is generated by the customer and recorded locally
  • then the customer encrypts code D with their own public key
  • the customer attaches the encrypted codes C and D to the contract description
  • the customer signs that merged info with their own private key and sends it to the supplier
  • the supplier verifies the signature with the customer's public key and records code D locally
  • the supplier does not know the original code D, only the encrypted copy of D

Proof of completeness

  • now the supplier and the customer both possess true and equal, signed and verified contract info with encrypted codes A, B, C and D
  • effectively both sides have proof that the "contract was started and completed" - but only if they provide the original codes
  • the supplier sends the contract description with encrypted codes A, B, C and D to the merchant
  • the merchant stores the contract description with encrypted codes C and D signed by both parties

Contract completion

  • the merchant verifies both signatures of the customer and the supplier and the contract conditions (elapsed time)
  • the merchant requests the original code C from the supplier
  • the merchant requests the original code D from the customer
  • once both codes are provided, the merchant can verify them against the encrypted codes received from the supplier earlier
  • the merchant uses the customer's public key to encrypt the original code D and compares it with the info received from the supplier
  • the merchant uses the supplier's public key to encrypt the original code C and compares it with the info received from the supplier
  • now the contract is completed by the merchant - the merchant has received "the proof" from both parties that the contract is complete

Contract claim

  • a "claim" must contain the contract description and 4 "secret" codes: A, B, C, D
  • at some point the supplier would like to "claim" their money from the merchants
  • they must contact each merchant individually
  • in the "claim" request the supplier includes their BTC address to receive the funds
  • the supplier provides the merchant with a list of contracts for which they would like to receive money
  • every single merchant verifies the corresponding contracts - they must not be "claimed" yet
  • the merchant must now send BTC to the supplier
  • the merchant marks those contracts as "claimed and paid" (potentially as a transaction on a blockchain)

Customer complaint

  • the customer can contact the merchant and "complain" about the supplier after the contract begins
  • in that case the customer can switch the contract to another supplier with no loss
  • the customer still must pay for the contract, but it can be another supplier - they both must complete STEP 6 again
  • when the customer complains for nothing while the current supplier is doing well - it is an accepted risk for the supplier
  • when the contract is switched to a new supplier, the old supplier receives nothing and the new supplier receives the whole amount

Chain of contracts

  • each customer and supplier can run many contracts with each other sequentially
  • this way customers can stay with the same suppliers and do not have to reconnect to new suppliers all the time
  • to make this happen, the customer and the supplier must periodically "renew" the current contract - just sign a new one for the future
  • each time, the contract duration must at least double
  • longer contracts are riskier for the supplier - because the customer can "complain" just before the end of the contract and the money will go to another supplier
  • shorter contracts are less effective for the customer - the data must be reconstructed on the new supplier and that "costs" money as well
  • the "contract chain" between the supplier and the customer is balanced at every moment in time: "risk" equals "effectiveness"
  • every next contract in the "chain" is a new "deal" between the customer and the supplier, and each can "decline" it with no loss

Communication flows

Contract begin

        STEP 1            STEP 2                STEP 3                STEP 4           STEP 5           STEP 6

Supplier -[A]-> Customer -[A+B]-> Supplier -[A+B+Contract]-> Merchant -[B?]-> Customer -{B}-> Merchant -[OK!]-> Customer 
                                                             Merchant -[A?]-> Supplier -{A}-> Merchant -[OK!]-> Supplier

Contract complete

         STEP 7           STEP 8                 STEP 9                   STEP 10         STEP 11          STEP 12

Supplier -[C]-> Customer -[C+D]-> Supplier -[A+B+C+D+Contract]-> Merchant -[D?]-> Customer -{D}-> Merchant -[OK!]-> Customer 
                                                                 Merchant -[C?]-> Supplier -{C}-> Merchant -[OK!]-> Supplier

Customer balance

         STEP 13            STEP 14
Customer -[BTC]-> Merchant -[OK!]-> Customer
                  Merchant -[transaction]-> blockchain

Supplier claim

          STEP 15             STEP 16
Supplier -[Claim]-> Merchant -[BTC]-> Supplier
                    Merchant -[transaction]-> blockchain

Why ?

What if the supplier is offline after the contract begins?

The customer can "complain" to the merchant and re-sign the contract with another supplier. The current supplier cannot "claim" anything.

What if the customer is offline after the contract begins?

The supplier is supposed to fulfill the contract until the end and then stop the service. If the customer never comes back to complete the contract, it is an accepted risk for the supplier.

What if the supplier does not provide the original code A to the merchant (STEP 5)?

The customer stops the relationship with that supplier with no loss.

What if the supplier does not provide the original code C to the merchant (STEP 11)?

No problem for the customer, because the supplier has already fulfilled the contract, but the supplier's "claim" for that contract will fail.

What if the customer does not provide the original code B to the merchant (STEP 5)?

The supplier stops the relationship with that customer with no loss.

What if the customer does not provide the original code D to the merchant (STEP 11)?

The merchant will pay BTC to the supplier, but will stop the relationship with that customer and put them on the blacklist. The merchant has actually already received BTC from that customer, so there is no big loss for the merchant.

How is the contract stored?

A contract is a small JSON file that describes the details of the deal between the customer and the supplier. First it is generated on the supplier's side, then the customer receives it, and finally the merchant. After the contract is completed and paid, it can be erased. Though merchants could potentially use another storage altogether to remember the history of all contracts in the network.

...