Skip to content

Latest commit

 

History

History
232 lines (138 loc) · 9.97 KB

merchants.md

File metadata and controls

232 lines (138 loc) · 9.97 KB

BitDust Merchants

(draft proposal)

Who ?

  • customer
  • supplier
  • merchant

How ?

Merchant

  • customer finds random merchant via DHT
  • merchant will receive BTC from customer via BTCPayServer integrated with BitDust software
  • merchant will pay to supplier from his BTC wallet integrated with BitDust software
  • customer's balance is "accounted" by merchant - he must select one single merchant
  • suppliers of that customer can "claim" money from that "merchant" after contract completed

Contract

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

Secret code A

  • process is initiated by the supplier
  • supplier prepare contract details about the deal with customer
  • first secret code A is generated by the supplier and he record it locally
  • then supplier encrypt code A with own public key
  • contract details are merged together with encrypted copy of A and signed with private key of supplier
  • signed contract info (with encrypted code A) is sent to the customer
  • customer records code A locally, he does not know A, only encrypted copy of A

Secret code B

  • now customer generate second secret code B and record it locally
  • then customer encrypt code B with own public key
  • customer attach the encrypted codes A and B to the contract description he receved from supplier
  • customer signs that merged info with own private key and send to the supplier
  • supplier verify the signature with customer's public key and records the second code B locally
  • supplier does not know the original code B, only encrypted copy of B

Proof of beginning

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

Contract confirmation

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

Contract fulfillment

  • supplier must follow the contract and provide resources and services to the customer
  • both sides are couting time from the beginning of the contract
  • after the time elapsed since the end of the contract, the supplier will again begin the process to complete the contract
  • simmilar process for codes A and B triggers again between customer and supplier
  • it is initiated again by the supplier - he expects customer to be online at that moment

Secret code C

  • third secret code C is generated by the supplier and he record it locally
  • supplier encrypt code C with own public key and send it to the customer
  • customer records the code C locally, he does not know C, only encrypted copy of C

Secret code D

  • fourth secret code D is generated by the customer and he record it locally
  • then customer encrypt code D with own public key
  • customer attach the encrypted codes C and D to the contract description
  • customer signs that merged info with own private key and send to the supplier
  • supplier verify the signature with customer's public key and records the second code D locally
  • supplier does not know the original code D, only encrypted copy of D

Proof of completeness

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

Contract completion

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

Contract claim

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

Customer complain

  • customer can contact the merchant and "complain" about the supplier after contract begins
  • in that case he can switch contract to another supplier with no lose
  • customer still must pay for the contract, but it can be another supplier - they both must finish STEP 6 again
  • when customer is "bitching" for nothing but current supplier is doing well - it is accepted risk for supplier
  • when switching contract to a new supplier, the old supplier receives nothing and 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 same suppliers and does not have to reconnect all the time to new supplier
  • to make it happen customer and supplier must periodically "renew" the current contract - just sign a new one to the future
  • every time contract duration must at least double or longer
  • longer contracts are more risky for supplier - because customer can "complain" just before the end of the contract and money will go to another supplier
  • shorter contracts are less effective for customer - the data must be reconstructed on the new supplier and that "costs" money as well
  • "contract chain" between supplier and customer at every moment in time is balanced : "risk" equals to "effectiveness"
  • every next contract in the "chain" is a new "deal" between customer and supplier and each can "decline" it with no loose

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 ?

if supplier is offline after contract begins ?

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

if customer is offline after contract begins ?

supplier suppose to fullfill the contract till the end and then stop the service if customer never comes back and complete the contract - it is accepted risk for supplier

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

customer stop relattion with that supplier with no loose

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

no problem for customer because supplier already fullfilled the contract but supplier will fail his "claim" for that contract

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

supplier stop relations with that customer with no loose

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

merchant will pay BTC to supplier but will stop relation with that customer and put it in the black list. merchant already received BTC from that customer actually, so not much loose for merchant.

how the contract is stored ?

contract is a small json file that describes the details of the deal between customer and supplier. at first it is generated on supplier side, then customer receives it and finally the merchant. after contract completed and paid it can be erased. thought merchants potentially can utilize another storage all together to remember the history of all contracts in the network.

...