Editing P2p mobile carriers (section)

= 7. Preventing non-delivery of services =

Payment and usage restrictions. Once authenticated, there is no way to restrict how much credit a buyer can use. Likewise, a buyer cannot easily prove that a seller is being dishonest. The question becomes how can anyone trust a seller to provide services if they can’t be verified

<span id="option-1---micropayment-channels"></span>
== 7.1. Option 1 - Micropayment channels ==

Instead of buying all the needed credit outright, a user can send micro-payments over time. E.g. every minute or so. That way, the maximum amount of money that can be lost is limited to a small chunk. The requirements for this to work properly are a locked down service.

International calling, roaming, premium text, and premium calling should be disabled at the account/operator level. If possible, group calls should also be disabled. This is all to ensure that the amount of credit a buyer can use is predictable for billing usage within a payment channel.

<span id="option-2---double-sided-deposits"></span>
== 7.2. Option 2 - Double-sided deposits ==

It’s unrealistic to assume that every service can be locked down. So another option is to use something called a “double-sided deposit.”

How this contract works is simple. It creates a joint escrow account between a buyer and seller, where each side deposits an equivalent amount of money. Either side is then able to destroy the group sum of money at any time which creates a strong incentive to work together.

This idea may sound a little extreme at first, but it’s not without precedent in the real world. Collateral is routinely used in real-estate to prevent damage to property, and its common to have previsions in contracts where an early cancellation results in a penalty. The difference is, these contracts only protect one side. The double-sided deposit protects both.

<span id="option-3---secret-contracts"></span>
== 7.3. Option 3 - Se͡c̦̲̺͍̜̀ͅr͉̲̞è̜̝ͅt ̖c̮̝͠o̟͔̫͖͡n͏̖͎̲̞̱t̤̬̦̘̞ŕ̰͚̬͇͔a̯̠͠c̙̘t͕̱̫͝s ==

Enigma introduced the idea of “secret contracts” [secret-contracts]. What these are, is special programs that encapsulate secret information and allow programs to interact with them through special interfaces without anyone being able to extract the secrets inside.

To illustrate this point in detail, consider the following program:

<pre>program(s): return sha256(s + &quot;my ultra secret info&quot;);</pre>
With a secret contract it’s possible to give out this program to anyone without fear that the string “my ultra secret info” will be extracted. Enigma even makes it possible for programs to receive secrets dynamically, and do other complex computations without fear of leaking information.

Once this concept is understood the original naive protocol can be changed to offer better security:

<pre>// Pretend variables marked &quot;secret&quot; use 1337 crypto magic
// that prevents people from seeing them in an active contract.
decentralized_mobile_service_provider():
    store_sim_key(secret sim_key):
        secret.sim_key = sim_key;
        
    compute_integrity_key(secret challenge):
        // For example -- XOR is not how its done on 2/3/4/5g.
        secret.integrity_key = secret.sim_key XOR challenge;

   compute_cipher_key(secret challenge):
        // Again -- not how it's done but as an example.
       return sha256(&quot;satoshi&quot; + challenge + secret.sim_key);
        
    compute_msg_integrity(secret msg):
        if msg != for a standard call:
            return
        
        return hmac(msg, secret.integrity_key)</pre>
'''The protocol then becomes this:'''

# Seller calls store_sim_key(sim_key) and gives T-IMSI to buyer.
# Buyer requests auth against the T-IMSI from the MsC.
# MsC returns challenge to buyer.
# Buyer calls compute_cipher_key(challenge) and uses key to encrypt challenge for an authentication response.
# Response is given back to MsC.
# Buyer calls compute_integrity_key(challenge).

Now the buyer doesn’t need to receive an integrity key. The seller can make it accessible through a secret contract interface that only returns a valid IV for certain message types. Integrity checks are required for 3G, 4G, and 5G [msg-integrity]. Thus, the seller can restrict a buyer with secret contracts and they don’t need to learn a buyers session keys, either.

<span id="redirecting-inbound-phone-calls"></span>