WO2019222313A1 - System for payment of a centrally minted digital coin - Google Patents

Abstract

System for payment of a centrally minted digital coin where the customers buy the coin from the mint, download it to their mobile device, then split the coin to make payment for any sum up to the sum of the coin, make such payment by directly transmitting the bits that comprise the coin to the receiving mobile device (the payee), using any method to transfer bits between devices, and accomplishing the transaction without real time intervention of any remote server, or any trading peers, thereby conducting such coin transfer by having two battery operated devices, and where mutual identification between the payer and the payee is optional.

Description

SYSTEM FOR PAYMENT OF A CENTRALLY MINTED DIGITAL COIN

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application under the Patent Cooperation Treaty (PCT) claims the benefit of United States Provisional Patent Application serial N° 62/671,421 filed on May 15, 2018; Provisional Patent Application N° 62/714,735 filed on Aug 5, 2018; Provisional Patent Application N° 62/782,301 filed on Dec 19, 2018 and Provisional Patent Application N° 62/805,369 filed on Feb 14, 2019.

TECHNICAL FIELD

[0002] BitMint is a payment solution based on a simple robust way to digitize and handle money. It is designed to serve as a global financial platform, and as such it is laden with a large variety of features relating to stability, versatility, flexibility and security. These many features will need to be brought to bear, examined and tested over time. What this design is focused on, is the essential idea of representing money as a series of financial bits where the identities of the bits is totally devoted to security, while the exchanged value is expressed by the cumulative aggregation of the value functions of these well-ordered financial bits.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The preferred embodiments of the invention will hereinafter be described in conjunction with the appended drawings provided to illustrate and not to limit the invention, in which:

[0004] FIG. 1 presents a schematic view showing the BitMint elements.

[0005] FIG. 2 presents a schematic view showing how the email server operates as BitMint Bank

[0006] FIG. 3 presents a schematic view showing the functional parts of the BitMint Module.

[0007] FIGS. 4 and 5 present respective diagrams showing the BitMint Dynamics.

[0008] FIG. 6 presents a diagram showing the BitMint Digital Coin comprised of a Capsule and Payload.

[0009] FIG. 7 presents a diagram showing the elements comprising the BitMint coin.

[0010] FIG. 8 presents a diagram showing the Payload Installer.

[0011] FIG. 9 presents a diagram showing how the fbit (financial bits) accounting works.

[0012] FIG. 10 presents a diagram showing the core-repository-negotiator. [0013] FIG. 11 presents a diagram showing Bank and Sub-Bank Centered Payment Configuration.

[0014] FIG. 12 presents a diagram showing the BitMint Mobile App Configuration; and

[0015] FIG. 13 presents a diagram showing the BitMint Coin Dynamics.

BRIEF DESCRIPTION OF THE PRESENT INVENTION

[0016] BitMint is a payment solution based on a simple robust way to digitize and handle money. It is designed to serve as a global financial platform, and as such it is laden with a large variety of features relating to stability, versatility, flexibility and security. These many features will need to be brought to bear, examined and tested over time. What this design is focused on, is the essential idea of representing money as a series of financial bits where the identities of the bits is totally devoted to security, while the exchanged value is expressed by the cumulative aggregation of the values of these financial bits.

[0017] We present here a 'skeleton' mode, where all non-essential aspects are left unaddressed, and focus is totally reserved for the fundamental process of minting BitMint money, distributing BitMint money, trading BitMint money, purchasing BitMint money and redeeming BitMint money.

[0018] The players in this phase are the Mint (to be constructed), the Bank for which mint- interface will have to be established, and selected traders.

[0019] System: Modules, Interactions:This basic system is comprised of four players: (i) the bank (B), (ii) the BitMint mint, (M), (iii) the BitMint buying trader, (T_b), and (iv) the BitMint redeeming trader (T_r), and their interactions (See fig-l) We mark interactions between X and Y as: < X|Y>, or: < Y|X >, These components, B, M, T_b, T_r represent computing modules associated with these functions.

[0020] The Bank: The bank requires no special capabilities. It operates by managing regular accounts for the participating traders, and for BitMint. The effect of Phase I will be shuffling of money between these accounts. The bank will treat BitMint as a merchant. The merchandise will be BitMint coins, but that is no concern for the bank. When a coin buyer purchases a BitMint coin, he or she use their regular payment device to pay for it. Their bank account is debited by the prescribed amount, and the money is transferred to BitMint operating account with the same bank— just like a regular merchant. And much as a regular merchant may accept returns of its merchandise so is the case with BitMint, only more often. Eventually every 'sold BitMint coin' is returned, although, not necessarily by the same trader. Upon such return the bank debits the BitMint operating account, and credits the account of the coin redeemer. BitMint will have at least two accounts with the bank, it business account and its operating account. The business account will carry money owned by BitMint, and the operating account will carry money owned by the traders, which is in temporary custody of BitMint.

[0021] BitMint Bank: Managing BitMint Coins: This capability is optional, and not part of the essential set of capabilities The BitMint bank is any organization that holds BitMint coins on behalf ot their owners. The security of the BitMint coin may be built into the coin itself (tethering), and this very fact allows for organizations with less than perfect security to operate like a bank.

[0022] Much as people may choose to deposit their money in a bank account rather than carry it in a stuffed leather wallet, so people may be given the freedom to keep their BitMint coins not on their communication device (e.g. the smart phone) but rather deposit it in the hands of a custodian, to be called a bank, a BitMint bank. In a regular deposit account the money credit is expressed as a carefully managed number. In a BitMint Bank account the money will be represented as BitMint coins. The coins can be associated as cash with the owner of the account, or they may be tethered to their owner, and need not be placed in a dedicated account.

[0023] This option will (i) serve to create a legacy continuity relative to the familiar deposit accounts, will (ii) serve users who are uncomfortable carrying large amounts of money on their communication device, will (iii) allow for bank-centered payment procedures, (iv) establish an extra accounting leg for financial auditing, (v) offer a new security dimension due to the BitMint way of representing money and (vi) will allow any organization regardless of its security arrangements to serve as account custodian to some specific community.

[0024] The BitMint bank optional implementation will serve to study two prospective directions for this money and payment layouts. One to migrate nominal bank accounts to BitMint accounts, and two, to develop virtual banks to hold money deposits (e.g. every email account will come with a wallet).

[0025] Email Banks: The bank may offer free email accounts to the public (like Google does), and build an "HmallBank"— a repository for BitMint coins tethered to those email accounts. This will allow for instant payment from one email holder to another. Will be attractive to merchants mailing merchandise proposals. Email account holders will see a report of available credit associated with that account. They will be able to directly email money to any fellow account holder.

[0026] The BitMint Mint: The BitMint mint, { [ F] } , is the heart of the BitMint system and operation. It is comprised of three parts:

• The BitMint Negotiator, {[ F]N}

This module communicates with the three essential partners to the BitMint operation:

• The Bank, {¥ }

• The Coin Buyer, Tb

• The Coin Redeemer, T_r

[0027] It collects money from the Buyer, credits money to the Redeemer, and shifts funds among the three pertaining bank accounts: the Mint account, the buyer's account, the redeemer's account.

[0028] · The BitMint Core, {[ $]C} The BitMint core is accepting minting requests and responds with minted BitMint coins.

[0029] · The BitMint Coin Repository, This module keeps track of minted coins— their

status and history.

We write:

These three modules are managed via a Mint Control Unit, MCU, which also assumes a host of accounting and management tasks.

[0030] The BitMint Negotiato

[0031] This module communicates with the three essential partners to the BitMint operation:

• The Bank,

The Coin Buyer

The Coin Redeemer, T_r

It collects money from the Buyer, credits money to the Redeemer, and shifts funds among the three pertaining bank accounts: the Mint account, the buyer's account, the redeemer's account. Internally the Negotiator module communicates with the Core, in two types of conversations:

• Request to Mint (R2M) Having been properly paid for a coin, the Negotiator will prompt the core to mint a coin for the denominated amount, and communicate this coin to the Negotiator, to further it to the buying trader.

• Request to Authenticate Redemption (R2A) The Negotiator will pass to the core a coin, or a coin-split submitted for redemption by a redeeming trader, and expect one of three answers: (i) OK to redeem, (OK), (ii) Redemption Denied— Coin is counterfeit (NC), or (iii) Redemption Denied— coin has been redeemed already (NR).

The BitMint Core: The BitMint core carries out two tasks:

• Minting requested coins The Negotiator will pass coin requests to the Core, to which the Core will respond with a freshly minted coin.

• Authenticating or Rejecting a Coin or a Split-Coin Presented for Redemption.

This request also comes from the Negotiator and is responded with one of three options: (i) OK to redeem, (ii) counterfeit coin, (iii) coin already redeemed.

[0032] Overall scheme: RNG: Random Numbers Generator, The BitMint Coin Builder

This sub-module accepts requests for coin, and fulfills them. It does so by requesting a random bit string from a random number generator (RNG). This module is divided to two smaller modules: (i) the capsule builder, and (ii) the coin "charger" also called the "payload installer".

The BitMint digital coin is comprised of two parts: the capsule and the payload.

The coin request is first handled by the capsule builder. The built capsule is then passed to the payload installer to install the random bits into the coin, (the payload). The payload-installed capsule (the ready coin) is then passed back to the Negotiator who requested it, and a mirror- image thereto is passed to the repository. See Fig. -4

[0033] The BitMint Capsule Builder: The BitMint Capsule Builder will build the coin according to the schematics depicted in fig. -7.

[0034] The Header and the Trailer are two unique symbols (optionally) design to mark the beginning and the end of a BitMint digital coin. When the capsule is fully assembled, it can be filled with dummy payload bits, which will be replaced by the "payload installer" module. The built up capsule will be communicated to the "payload installer" module.

[0035] The BitMint Coin Header/Trailer: These are two unique symbols designed to identify the start and end of a BitMint digital coin. These tags may be upgraded to include split tags to identify a split coin.

[0036] BitMint Coin Id: The identification section is comprised of:

• Mint Identification: A mark that is designed to fully identify the mint and the project. It is important because the communication of BitMint digital coins in the cloud will leave tracks, and one should be able to trace and identify the coin as a product of this mint, for a long time after the coins are no longer "live" and the mint has closed down. • Coin Identification: This is a unique coin identifier. There should be only one tuple of Mint-id — Coin-id. The power of BitMint is in the inseparability of the value and the identity of the coin. Hence the id is as important as the value. Coins will retain their unique id even after been redeemed and out of play. While in this setting, all that matters is the uniqueness of the coin-ID (CID), in future phases, the CID will be fully randomized so that if the coin is traded in a blockchain platform, and identified only by its CID, there will be no information leakage as to the coin value, time minted, etc. In this phase the coin id will be incremented by the order of minting.

• Valuation Function The function that determines the monetary value of each fbit (financial bit) in the coin based on its position in the payload string, and on data captured in the fbit. The basic design will operate with one unified BitMint valuation function that would apply for all the coins minted in this phase. Despite that the valuation function will be specified on every minted coin, to allow for independent evaluation. See below the details of the valuation function setting.

• Status A tag to indicate the status of the coin. Options: (i) ready (unborn), (ii) live and well, (iii) live and sick, (iv) dead, not buried, (v) dead and buried. When the capsule is prepared, and before it is being loaded with the payload, it is set to status 'unborn'.

• Split Identification Data to specify the subsection of the BitMint coin. Would normally identify the starting fbit and the ending fbit, or either one of them and the bit length of the payload section that comprises this split. When minted the split identification will be 1 to |p| where |p| is the fbit count of the payload, P. Different values are subsequently set up by traders who split their coins.

• Time Stamp A stamp with desired time resolution: date, date + hour, or even a minute-wise resolution.

[0037] Payload Installer: The Payload installer receives the capsule from the capsule builder, and reads from its content the number of bits required to 'charge the coin' (or 'arm the coin'). The Payload Installer then requests the RNG the required number of random bits, and fits them into the capsule, and then it sets the status of the coin from "unborn" to "live". Next the Payload Installer makes an exact copy of the live coin, forwards one copy back to the Negotiator and one copy to the Repository. See Fig. -8.

[0038] The BitMint Coin Authenticator: The Coin Authenticator accepts a request to authenticate from the Negotiator. It then queries the Repository for the requested coin ID. The response from the Repository may be: (i) forwarding the requested coin with its current redemption status marked, as (1) "Live and Healthy", or its current redemption status marked "Live and Sick". In the latter case, the case will be halted and human (manual) intervention will be requested. The other response from the Repository may be: (ii) "ID not found", which may be due to (a) said coin was redeemed long time ago, and is no longer stored in the active coin-search area in the repository, or it may be due to (b) corruption of the ID tag, or (c) the requested redemption is a counterfeit. Depending on the circumstances, the "ID not found" may be sufficient to reject the redemption request, or, perhaps the circumstances are such that it would be important to sort out between options (a), (b) and (c) above. In the latter case the Authenticator will so indicate to the Repository, to take action. In this Phase, a response of "ID not found" will be accepted at face value because of the limitation of scope, where all the minted coins will be stored in the active search area of the repository.

[0039] If the coin is found, and forwarded to the Coin Authenticator, then the authenticator will compare the requested redemption to the redemption status of the stored coin. If ALL the fbits (financial bits) put forth for redemption are unredeemed in the stored coin, and only in that case, would the response to the Negotiator be: "Ok to redeem". In that case the requested redemption of fbits will be marked on the copy of the coin which will be returned (updated!) to the Repository. If even one fbits requested in the redemption request has been previously redeemed then the request for redemption is denied, the coin status is updated from "Live and Healthy" to "Live and Sick", and returned to the Repository. See Fig. -9.

[0040] The BitMint RNG: The basic design would be limited to pseudo-randomness, potentially augmented with the BitMint randomness filter that throws out particularly non- randomized sequences. The simplest option is to rely on the built-in random number generator within the implementation language. It is recommended that any such built-in randomness generator will be combined with well chosen PRNG algorithms. The combination of randomness sources will be through successive XOR operations. The exact RNG configuration will be determined based on the level of demand. The design will have to be ready for a high-demand generated by occasions where many traders will request to buy BitMint coins at the very same time. Since one expects great variance in demand (daytime more busy than night time), it would be possible to pre-generate a stock of randomness to feed into the high demand situation. This strategy is normal being frowned upon since the pre-stored random bits may be compromised. Since the built-in RNG is usually quite fast, it would be possible to augment it with dedicated RNG with some intervals. Say XOR a group of p bits every q random bits generated by the fast source. Such part combination will increase the need for the randomness filter, but will accommodate any high-demand.

[0041] Randomness Filter: The BitMint Randomness Filter examines a stream of bits in groups of n bits at a time, where n is a design parameter that may change at will. Each string N comprised of n bits is given a randomness index p=p(N) based on its contents. If p(N) is above a threshold, T, then the string is forwarded as "passed". Otherwise the string is discarded.

[0042] The RI is computed based on the idea that randomness is the absence of symmetry. We consider several symmetry options, SOi, S0₂,...SO_t. A symmetry option is a symmetry test performed over a bit string. For example the string 0001000 is symmetrical with respect to rotation around the middle. The string 001001001001, is symmetrical with respect to cyclical shift by 3 bits. Given an arbitrary n-bits string we check if it complies with any of the t symmetry options test. If it does we declare the string to be of zero-randomness, and bel00% symmetrical. If it does not then we decompose the string the smallest number of string which are all symmetrical. We agree to declare a 1 bit string as inherently symmetrical, and therefore every n- bits string will be composed of some x symmetric strings, where 1 < x < n. There may be several way to so decompose the n-bits string, N, so there may be various values for x. We assign s = Xmin . And then compute, raw randomness

[0043] Obviously different N strings comprised of n bits each are associated with a different s(N) value. One of these s values will be the highest s_max. We therefore can compute effective randomness index as:

for which, tOO 0 < p < 1. We shall set a threshold limit 0 < T < 1, and admit only strings N for which p(N) > T. For a stream of r=in bits per seconds, coming into the filter, the filter will evaluate i input strings, discard d strings, and admit o strings, resulting in an effective randomness flow of on/sec bits. If the ratio o/i is too small, the filter will invoke a self-regulating logic to decrease the value of T, and bring up the effective flow of randomness.

[0044] The BitMint Repository: The Repository is the part of the mint that requires the most serious security measures. However, in this phase, we focus on the fundamental payment dynamics, so the various security devices will not be used. We shall not use the Integrity Guard, the Oracle, nor the write-once device. Also, this implementation will have no archive. All the coins issued within this Phase will be kept in a live random access database, indexed by the coin- ID. Security will be limited to the standard database security offered by the database manager.

[0045] The Repository operates in two categories: (i) coin related exchange with the mint Core:

(a) accepting newly minted coins from the Coin Builder, and (b) conversing with the Coin Authenticator, and (ii) running accounting processing communicated to the mint Negotiator. All these operation are standard database primitives. See Fig-lO.

[0046] Buying Trader: The Buying Trader buys BitMint coins through a dedicated BitMint phone app, using standard purchasing procedures effected through dedicated apps for any other product. All security protocols will be the same. The product will be BitMint money stored on the trader's phone. The relationship with the bank will be standard in terms of using the trader's payment protocol to buy the BitMint coins. In the basic design the buying trader will indicate the requested sum, exercise a regular payment for the nominal sum plus a nominal purchasing fee. No tethering information of any kind will be specified. The BitMint mint will respond, by sending down to the trader the fully constructed coin. The coin coming down to the trader's phone as if it were a song or other digital goods, will then be taken up by the BitMint app for storage toward payment or redemption.

[0047] Redeeming Trader: There are two classes of redeeming trader:

• Exchange Redeemer: This redeemer sends to the BitMint mint any coin in its possession, and exchanges it with an equal coin of same value but a different identity. This procedure is carried out after a trader is being paid a coin from a paying trader, and wishes to insure that the payer will not pay the same coin to a third trader who will rush to redeem the coin. The exchange act provides the trader with a freshly minted coin that alleviates the fear of double spending.

• Terminal Redeemer: The terminal redeemer exchanges his or her BitMint coin with legacy money. The terminal redeemer exercises a protocol identical to normal return merchandise protocol.

[0048] BitMint, The Heart: Public Payment: The entire BitMint apparatus is designed and constructed for one purpose: to allow the public to effect payment in order to run its business and lives. The trader to trader payment is the heart of the BitMint design. It can be carried out through imaginative and private means between any two traders. It comes down to passing information regarding a bit string. BitMint payment is as basic as can be. It may be carried out between two strangers, with no Internet connection, even with no battery power. A BitMint coin is comprised of some n bits. That string may be passed from its holder to its recipient in any form, including a printed bar-code or a QR stamp; perhaps in Base64, or many other forms. Given some t traders such that each of them is aware of the bit identity of a BitMint coin, x, then the trader who came to this knowledge the last, is considered the owner of x. And to actuate this principle, traders will redeem any coin coming to their awareness as it happens. Redemption against a newly minted coin of same value, will protect the redeeming trader from the risk that one of the (t-l) traders who is aware of the coin, will abuse this awareness. But to the extent that such abuse is not a concern, redemption is not necessary. The BitMint eco system accounts for a monetary steady state where an amount of value is shared and communicated among the community of traders. In this phase, traders will be encouraged to innovate ways to pass BitMint coins to each other, but we also will provide a phone-based application (BitMint Mobile App) to perform the following tasks:

[0049] BitMint Mobile App - Functions

[0050] We list the following functions: 1. store value in the operating device 2. display stored value in the operating device 3. buy BitMint digital coins from the BitMint mint 4. exchange- redeem BitMint coins from the BitMint mint 5. terminate-redeem BitMint coins from the BitMint mint 6. pass a BitMint coin to another trader 7. accept a BitMint coin from another trader 8. report BitMint payment history 9. special operations 10. Wake-up and Sleep Routines.

[0051] BitMint Mobile App: Store, Display, Report: The BitMint Mobile App (BMA) will claim three permanent memories on the app device. The critical ones are the memory to hold the money, and the 'security memory' that holds security keys to secure the money. A secondary memory will hold the payment history. Upon activation the BMA exercise access to the security memory, and with its data it accesses the money memory and then displays the 'wallet'— the total amount of money stored in the device on the device's display screen. Upon user demand, the BMA displays the payment history. That history is readily uploadable to any other app on the device.

[0052] The security memory: This memory contains permanent data secured by whatever security means provided by the operating system of the device plus a forgettable activation key entered by the user in the BMA wake-up routine. Combined this data is used by the BMA to decrypt the money in the wallet memory (where the coins reside). [0053] The money memory (the wallet): The coins in the memory are few enough so that they can be stored sequentially, alleviating any requirement for structure, which in turn may be leverages by hackers. Say then, the BitMint wallet, W, is constructed as a sequence of BitMint coins W =Ci || C₂,..· || C_w, which is automatically summarized to display a total on the device display. There is no need to breakdown the individual coins with any of their parameters and values. The user is concerned not with how the total money at her disposal is built up, but only in its total. In subsequent phases, users will have visibility into particular ingredient coins.

[0054] The Payment History Memory : This memory accumulates the per coin dynamics. It traces every coin in and every coin out, including time of transactions and identity of payment partner. This history does not feature the payload bits, to reduce its secrecy requirement.

[0055] Buy Redeem: We present ahead the basic transactions of buying and redeeming coins.

[0056] Buying BitMint Coins: Upon selecting this option from the BMA action menu, the 'buy' routine will display a 'buy screen' comprising: 1. window to enter the desired amount of BitMint money to buy 2. windows to enter payment data to allow the BitMint mint to charge the user for the purchased coin. The routine will have allowance and reasonability checks on the entered data, and will prompt the user to correct her entries if any of these checks fail. Otherwise the routine will activate a 'BUY' button. Upon clicking this button the purchase request will be communicated to the BitMint mint to execution. The response from the mint might be either (i) purchase could not be executed, followed by a list of reasons for this reply, or (ii) 'purchase successfully accomplished' note, with a prompt to click 'OK' and return to the main BMA screen comprised of the 'available money' and a menu.

[0057] Redemption: Upon selection of the 'redemption' option from the menu, the user will be presented with the 'redemption screen' showing option selection: redeem-exchange, or redeem- terminate.

[0058] If the user selects 'redeem-exchange' then a 'do it!' button shows, and upon clicking it, the entire wallet is sent to the BitMint mint, and a newly minted coin for the total is being delivered to the user. If the uploaded coins have a problem and only some money is good for redemption then it is a matter of policy whether to return a message stating 'irregularities' inviting the trader to connect personally to the mint and submit an incident number that is being displayed with the note, or whether any coin that is OK is redeemed and a message of regularities is also added. [0059] Redeem-exchange also called 'refresh' may be exercised often. In fact, high values wallets may be associated with a built-in refreshing routine that would refresh the money as often as desired, so that any theft of money will be readily discovered.

[0060] Traders' Exchange: That is, as indicated above, the heart of the BitMint platform. We identify:

[0061] 1. remote payment 2. proximity identified payment 3. proximity unidentified payment.

[0062] The BMA will keep record of all transactions, including details of the transacted coins, but without the payload bits. After each payment the paid coin will have its payload bits erased for security reasons and fraud concerns. In the following, the term coin regards also to any split coin identified through the first ant last fbit.

[0063] remote payment: Remote payment requires remote transmission of BitMint coin. We distinguish between: - Internet Transmission and - Non-Intemet Transmission. Non-Intemet communication involve a variety of technologies, like regular mail, fax transmission, and direct modulated electromagnetic radiation. Traders are free to initiate any of these, at their will.

[0064] The majority and nominal remote transmission of BitMint coin is Internet-based. It is therefore subject to the Man-in-the-Middle attack.

[0065] Internet Transmission Remote Payment: This payment mode is divided to: » Key- Sharing Traders » Non Key Sharing Traders. In this phase we shall not implement key-sharing mode, only non-key sharing mode. We shall consider: » » Email based payment » » Messaging Based System.

[0066] Internet Based Payment Security Between Strangers: Two online strangers may exchange a BitMint coin while relying on the nominal security supplied by their browsers. It should suffice for small denominations. This mode security will be enhanced by auxiliary protocols:

» » verified required exchange-redemption

[0067] In this protocol the payer notifies the mint on the payment transaction, and sets a tine interval At beyond which, if the coin is not redeemed, the coin remains in the possession of the payer. This requires the payee to refresh/redeem exchange the coin right away, possibly with supplying identification.

[0068] » » registered payer protocol: This applies for a registered payer, sharing a crypto key with the mint. The payer will encrypt the the coin using that key. The payee will send the coin an block to the mint for refreshing, disclosing the identity of the payer for the mint to know how to decrypt and check the coin.

[0069] » » Mutli-Factor Transmission Security: Using two or more payment modes where an encrypted coin is transferred through one channel, and its decryption data is transmitted in another channel.

[0070] Email Based BitMint Payment: Email based BitMint Payment can be carried out in two modes:

» BitMint mobile app direct Paying directly from the BMA to a designated email address

» Manual Email based payment: Reducing the transacted coin to coded data, (printed BitMint coin) which is then placed in an email sent independently from the BMA.

The BitMint Dedicated Mail Address

[0071] A Bank Managed Financial Email: As a matter of policy the bank may wish to offer a bank management financial email in the form: username@BankServerName The direct email routine may be limited to emailing money to such financial email addresses. To be granted such an address the bank will issue requirements for identification of the user, and perhaps for having an account with the bank. This might drive many new customers to the bank. It will also help with security since all the recipients are known entities.

[0072] Email BitMint Money Direct: The direct email subroutine is activated by the BMA user from the main menu screen. It displays the email sending screen prompts the user to specify: 1. email address to send the money to.2. optionally a repeat entry for the recipient email address.

[0073] 3. value of money to be paid 4. Mode selections: "Easy", "Protected", "Verified".

[0074] The screen also puts up a warning: this payment is irreversible, are you sure you wish to make this payment? Based on the mode selection the proper sequence is executed: (i) easy mode, (ii) protected mode, and (iii) verified mode. The easy mode is a simple act of mailing the BitMint coin to the designated email address. Upon emailing the coin is erased from the wallet of the sender, alas, the sender could have sent a copy to himself to recover the money if the intended recipient did not get it. In the protected mode the payload bits are encrypted, and only when the recipient acknowledges receipt of the encrypted coin, does the sender pass over the encryption key for the recipient to decrypt the coin and use it. Only then the transmitter erases the coin. In the verified mode, one uses the protected protocol, then waits for the recipient to acknowledge receipt and exchange-redemption of it, before erasing the coin from the wallet. [0075] And the bottom of the screen will feature a "Pay!" buttons, to carry out the payment.

[0076] "easy" email payment mode: When the "Pay!" button is pressed, and the "easy" mode is indicated, the email-pay routine does: 1. it verifies that the wallet has enough a single coin valued exactly or more than the amount to be paid. Notice: the email routine will not aggregate coins. 2. if there is not enough money in a single coin, the subroutine issues a warning to that effect, and re-displays the payment page as above along with (i) the value of the highest coin the wallet, (ii) the total value of wallet, and (iii) a recommendation to refresh the wallet and get a freshly minted coin. 3. if there is enough money in the wallet, the routine generates a unique transaction number (UTN), then sends the coin to the recipient, and erases it from its wallet.

[0077] "protected" email payment mode: When the "Pay!" button is pressed, and the "protected" mode is indicated, the email-pay routine does: 1. it verifies that the wallet has enough a single coin valued exactly or more than the amount to be paid. Notice: the email routine will not aggregate coins. 2. if there is not enough money in a single coin, the subroutine issues a warning to that effect, and re-displays the payment page as above along with (i) the value of the highest coin the wallet, (ii) the total value of wallet, and (iii) a recommendation to refresh the wallet and get a freshly minted coin. 3. if there is enough money in the wallet, the routine randomly selects a payment verification encryption key. (PV key) 4. It applies the PV key to the transmitted payload bits to generate Encrypted Payload (EPL). 5. The routine generates a payment email, identified with a unique transaction number (UTN), then emails the coin with the payload bits encrypted with the PV key. The email prompts the recipient to email a payment acknowledgement notice. At this stage the transaction is in a pre-settled mode. The money is considered transmitted, but in an encrypted form. The BMA moves the paid coin to the -pre- settled memory zone, so that it cannot be re -paid. The transmitter BMA enters a 'wait' zone. Nothing is done on the payer side until the payee emails an acknowledgement of the money transmission and a request for the decryption key. When this happens the transmitter sends over the encryption key (The encryption is symmetric so the same key is used for both encryption and decryption). The key can be emailed, or sent in any other channel. Upon transference of the payment verification key (PV key), the transmitter would consider the payment concluded, the request for the key will be regarded as proof of receipt, and the transmitter would then erase the payload bits of the transacted coin to prevent any re-payment by the device owner, and any abuse by any hacker of that device. [0078] Payment Verification Encryption: Since the payload bits are highly randomized there is no need for any strong encryption with large keys. This task will be accomplished using a small numeric key that may be delivered by phone. The encryption key will have to be randomly selected for each emailed transmission. The proposed method is ultimate transposition where the key is an integer N of any size. The higher the amount transmitted, the larger the range 1— N from where the key K is to be randomly selected: 1 < K < N. For reference see: Equivoe-T: Transposition Equivocation Cryptography. (https://eprint.iacr.Org/20l5/5 l0.pdf)

[0079] "verified" email payment mode: The "verified" mode proceeds like the "protected" mode, but the coin is not erased until either the payee notifies back that the coin was well received and cleared with BitMint, or the payer verifies with BitMint that the transacted coin was claimed (refreshed) by the recipient.

[0080] Manual eMail Based Payment: This mode is akin to sending cash in regular mail. The coin is reduced to a document which is attached to an email. No encryption, no security. Anyone getting a hold of the coin can redeem it. Upon sending out the coin, its content is erased from the wallet.

[0081] Messaging Based System: There are many anonymous or semi-anonymous messaging environments which can be used by two strangers to exercise a BitMint coin transaction. Because of the increased security risks, this should be limited to small transactions over private chat rooms. Messaging payment will be based on "texting payment" resulting in a Base64 coin expression, which can then be copied into any messaging stream. As soon as the coin-text is formed, the coin is erased from the wallet.

[0082] Manual BitMint Payment: All the remote payment options feature a 'manual' category whereby the coin is reduced to documented data, which in turn is emailed, faxed, message- transmitted etc.

[0083] Non-Internet Transmission: Non-Internet communication involve a variety of technologies, like regular mail, fax transmission, and direct modulated electromagnetic radiation. Traders are free to initiate any of these, at their will.

[0084] Phone/Fax Payment: We distinguish two modes: » Direct payment from the BMA » Manual payment.

[0085] Direct Phone Payment: Will enable the wallet owner to send a BitMint coin as message tied to the recipient phone number. The message will be text-based (Base64). It will be activated from a phone-pay screen, displaying 1. window to enter the amount to be paid. 2. window to select a phone number to send the money to (selection from the phonebook) 3. window to type in a phone number to be paid to. 4. a warning about this payment being irreversible 5. a "pay" button. Upon clicking "pay" the routine will generate a Base64 string of the coin to be paid, and send this as a message to the indicated phone number. The routine will then void this coin from the wallet. And finally the routine will display a screen 'done' to the user, with a prompt to return to main menu.

[0086] Manual Payment: The user would request the BMA to generate a coin document which will then be message delivered to the intended phone number. Upon reducing the coin to a document, its contents will be erased from the wallet.

[0087] Proximity identified payment. This mode relates to payment transacted between parties who are physically close to each other and they mutually identify one to the other,. We distinguish between: · Electronic Proximity Payment and · Over-the-Counter Legacy Payment

[0088] Electronic payment relate to any use of active electronics to carry out the payment. Over the Counter Legacy (OTC legacy) payment relates to any payment which resembles the traditional mode where a payer throws some coins over the counter to the payee. Electronic Proximity Payment further divide to (i) Mint-in-the-Middle, (ii) Networked Payment, and (iii) Battery Operated Payment.

[0089] Electronic Proximity Payment: This mode is nominally outside the scope of this phase.

It is provided here to complete the list of options. It is divided to:

• Mint in the Middle Payment : This mode calls for the BitMint mint to be in contact for the transaction to take place. It provides for maximum security with some extra burden.

• Networked Payment: This mode exercises a network trust protocol where the community of traders vouches for every transaction, so that the BitMint mint does not have to be involved.

• Battery Operated Proximity Payment: In this mode two battery-operated devices carry out a transaction. Trust may be furnished via cryptographic trust certificates.

[0090] Over the Counter Legacy Payment: This mode is the most basic way of transmitting value. It can be carried out with or without mutual identification. We discuss the following options: · Screen Capture payment · Printing Money · Hybrid Coins [0091] The first two involve a routine to document the BitMint coin. Once documented it may displayed on the payer's screen, and read there by the payee's camera. Alternatively the document will be printed out, and handed over to the payee, who will use his device camera to read it. The third option involves a device where the coin itself is concealed in a way that it is easy to expose it, and use the data as money, however any such exposure will be clearly visible so that it would be virtually impossible to pass that coin as "virgin".

[0092] Proximity unidentified payment: This is the most basic mode where value is exchanged between two people who know practically nothing about each other. It also applies to situations where the one party knows the other, but the other does not know the first. Surprisingly this basic mode offers a host of modern applications. One such application is planned for this implementation phase. This is the Promotional BitMint Coins— Account Opening Inducement.

[0093] Promotional BitMint Coins - Account Opening Inducement.

[0094] This option is designed to illustrate the unique power of proximity unidentified payment.

The bank will use its promotional budget to print cards with a desired monetary value (say 200¥ ). The cards will be identified per their parameters, and their payload will be written down as a QR statement. The promotional experts in the bank will pick a crowd spot where the people are likely to be middle class wealthy, and openly distribute these printed money bills. For example, when passengers file out from a just landed plane, they are offered those money cards. The assumption is that the passengers have a solid financial foundation and as such are very attractive customers for the bank. The money card will indicate an expiration date, say two days ahead. The money expires after this date. The money card will also indicate that it is usable only by people who don't already have an account with the bank. This will motivate card holders who are already customers to pass the card along to someone who does not have an account with the bank. The card will guide its holder to download the BitMint app, and activate the "read money in" option. This option will use the device camera to read the face of the card. The app software will verify the contents of the card, and notify the user that this money will be credited to his bank account should he or she choose to open one. An account will be opened through the device and the money will be credited. It may be the most cost effective way to win over wealthy customers.

[0095] Printing and Texting BitMint coins: The essential feature of BitMint is the fact that the data per se is the money. And this very fact allows one to take BitMint money off from the customary set of numbers inside a computer address. BitMint money can be physically printed, or given as text message. This fundamental feature can be shown in this phase. We discuss: ·

Printing BitMint Coins · Texting BitMint Coins

[0096] Printing BitMint Coins: All payment methods offer a manual option where the payment is carried out by passing along a documented version of a BitMint coin, regarded as "printed BitMint coin". To effect this payment option, the system will include a coin printing routine that would take in a BitMint coin and generate a coin document. The coin document will have a textual part and a graphic part.

[0097] The Textual Part of the BitMint coin document: 1. BitMint icon: F 2. Coin Id 3.

Coin Value: 4. fbit identification 5. Split Identification: 6. valuation function: 7. date/time printed 8. printer id: 9. payee id:

The Graphic part of the BitMint coin: The prominent options are bar-code, QR

[0098] Texting BitMint Coins: The BMA will offer the feature of expressing a BitMint coin in a text— based on the Base64 alphabet. It will be effected through a Text Payment page featuring: 1. window to indicate the amount to be paid 2. window where the texted coin appears 3. a 'copy' button. Upon clicking it would copy the coin to the device active memory. 4. the 'copy' button will be tantamount to 'pay' and when pressed the coin will be erased from the wallet.

[0099] Accepting BitMint Coins: We discuss here the issue of accepting BitMint coins from fellow traders. It is separate from the issue of buying and redeeming BitMint coins. We distinguish between (i) built-in coin acceptance capability and (ii) manual acceptance of BitMint coins.

[00100] In manual mode a payer will send an email, a text, or a graphics to the payee's email account, phone account, or message center account. The delivered coin will then be copied from the location to which it was sent and it would then be pasted into the manual acceptance screen. That screen will also have a "verify yes/no" button where the user indicates whether to immediately verify/refresh the coin with the BitMint mint, or not. The screen will also feature "accept coin" button that upon clicking will have the acceptance routine interpret the pasted coin, followed by an indication of proper interpretation. If the "verify yes" button is clicked then the screen will show a message "waiting to validate/verify the coin", followed by the "coin validated/verified", if so, and "coin rejected" otherwise. In the built-in mode the BMA software will directly retrieve a marked email or text and take up its content. Also it will activate the device camera, and direct the user to point the camera at the graphics of the coin. Upon successful read, the screen will so indicate. Otherwise the screen will indicate failure.

[00101] Bank-Centered Payment: The BitMint payment solution allows for traders to consummate a transaction without real-time involvement of a third party. Yet, for reasons of continuity and habit, BitMint payment may be conducted in the traditional bank-in-the-center way. This may happen through BitMint bank accounts, which contain full fledged BitMint coins rather than just a number that signifies credit. We consider a configuration where both payer and the payee use personal devices which function as wallet and may contain BitMint coins, both have BitMint-accounts in a bank of their choice, and both have nominal accounts in a bank of their choice.

[00102] This leads to a payment matrix where the two payment modes which are contemplated for this phase are marked:

[00103] Special Operations

[00104] wallet recovery: The user is encouraged to memorize the wallet key, and not to commit it to writing. To that BitMint will allow a user who forgot his memorized wallet key to recover his money (at some cost). The wallet recovery operation will retrieve the encrypted wallet, and the permanent security memory and deliver it to the BitMint mint. The memorized wallet key will be limited to 4 or 5 digits, and thus would allow the mint to exercise a brute force cryptanalysis and retrieve the money. Only the mint can do so because only the mint knows the information in the encrypted coins.

[00105] Wake-up, Sleep Routines: The most important responsibility of the wake-up and sleep- routines is to serve security concerns. Upon activation the BMA will: 1. display the BMA welcome screen. 2. prompt the user to enter the memorized wallet security key (MSK) 3. Using the WSK and security data in the key security memory, the wake-up routine will decrypt the wallet memory. 4. The decrypted wallet memory will be processed to compute the total amount of money in the wallet, and display it on the BMA screen. 5. The wake-up routine will display the full menu of actions available to the user.

[00106] Money Encryption: BitMint money will be encrypted in a two tier scheme. First the payload bits will be encrypted to take advantage of their randomness, then the entire coin will be encrypted to deny any information leakage.

BMA Software Configuration

[00107] The BMA software is comprised of: · User Activated Routines · Background Routines.

[00108] It is also divided to: » Internal Processing » Device-Communication software

» Remote Communication software.

[00109] User Activated Routines: These routines are all click-activated off a central BitMint screen, to which they return upon completion. Some routines may remain in suspension marked by a comer icon; waiting for an external response e.g. payment verification.

BMA Background Routines

[00110] The BMA runs background routines. We present: · Book Keeping : The main background processing will be to keep track of payment events. This is necessary to sort out any unsettled payment situation, especially in the initial operating phase. · Coin Consolidation:

As a matter of routine work, the BMA will verify/consolidate the wallet into a single coin of same value. This consolidation will be complete at this phase because there is no tether. Once tether is implemented, only coins of exactly same tethering can be consolidated.

• "Waiting for Response" routines.

The BMA will be able to activate subroutine that wait for a party to send some expected piece of information.

[00111] Tri-Log Accounting: The term Tri-Log Accounting has been coined to express the new accounting leg provided by the BitMint coin. Nominal accounting has two legs: income and expense. The BitMint coin offers a third leg that must fit with the other two. In this phase the Tri-Log power is quite reduced, but nonetheless, the overall coin dynamics allows for the overall financial picture to be described in various cuts and views, which should all fit and agree. Since this phase is experimental, it is of great importance to track coin dynamics and extract from it its wealth of conclusions. The general picture of the Tri-Log accounting is presented below. It displays the life time of coins, their change of hands, and their split.

BitMint QR Payment

[00112] Passing a Redacted BitMint Coin via Information Limited QR Graphics

[00113] Typical BitMint coins are comprised of relatively large bit strings which exceed the information content of a bar-code or a QR depiction. It is possible then to pass a full coin via several QR drawings, but this solution is quite inconvenient. An alternative is to reduce the BitMint coin size such that it would fit into a QR drawing, and the reduced size will convince the BitMint mint of the coin transaction. The reduced (or say redacted) BitMint coin, unlike, a full size BitMint coin, cannot function as a further tradable coin, and must instead be redeemed or exchanged via the BitMint mint. This redacted-BitMint coin solution positions BitMint at par value with some prevailing payment systems— creating a very similar and very competitive user experience.

[00114] Introduction: QR became a popular communication channel for a variety of applications, among them payment. In China, for example, the two major consumer payment systems AliPay and WeChat offer the convenience of a payer, reading the payee QR, to identify him (her or it), so that she can order the central account manager to pass an indicated amount of money X (phone indicated normally) to the account represented by the QR. Merchants have their account QR marked on tables, on merchandise, on the wall, etc. and it is very convenient for the payer to capture the QR with her mobile camera, interpret it properly, and communicate the transactional details to the payment account manager. BitMint may be traded account-wise and then the very same procedure will apply to BitMint. However, BitMint may uniquely trade directly: the payer sending a bit string of monetary value to the payee. That money bit- string may be of size too large to fit into a QR expression. To overcome this size disparity it is possible to parcel out a coin to several QR displays. This is inconvenient, and when it comes to payment convenience is a prime factor. The alternative solution is derived from the possibility of the payee to immediately send the coin bit string to the mint for identification and redemption or exchange. Let the coin be of a large size L (in terms of bit count). When a payee presents L to the mint, the mint will verify the identities of all the bits in L, and recognize the payee's act as passing that coin back to the mint for redemption. We now ask the question: is it possible for the Payee to pass to the mint a shorter bit string, S < L, such that the passing of S will convince the mint that it could only be constructed by someone in possession of L? To so convince the mint one would necessarily have to resort to probability. S should be constructed in such a way to be derived and dependent on L so that the probability for someone to derive S without being of the possession of L will be negligible, at least in relation to the sum of money to be redeemed or exchanged. The larger that amount of money, the greater the probability should be that S can only be computed by someone in possession of L. The QR payments are consumer payments where the sums in general are quite small, so the probability that having S is proof for having L should not be too high. Based on this principle we devise a procedure to make BitMint payments via QR communication in ways which resemble the user experience in other consumer payment procedures.

[00115] Payload String Reduction: A BitMint coin is comprised of the capsule part (meta data), and the value part (the payload). The capsule is of fixed length that fit nicely in a QR expression. It is the size of the payload that presents the QR challenge. The size of the chosen QR (q comprised of |q| bits) must fit for the meta data (m) of a BitMint coin, and the reduced payload bits, r, that represent the pre-reduction full size payload, p. ( |r| < |p| ). |q| < |m| + |r| How would one reduce a payload p to a shorter string r to convince the BitMint mint that the deriver of r has possession of p? The natural way to do so is one of the many standards for hashing. The probabilities of fraud are well established. Hashing in the conventional way may come with a drawback for the case where a small number of payload bits come with flip identity as is called for in the procedure known as "data fingerprinting", see ["Fingerprinting Data" https://eprint.iacr.org/20l8/503.pdf]. Even if only one of the payload bits will be flipped, any standard hashing procedure will result in a completely different hash (r), which will make this solution non viable. This random flipping of bits may be overcome by reducing p to r using the interval method. I-method.

[00116] Interval Reduction of Payload: We consider a large bit string L comprised of 1 bits. We wish to reduce L to a shorter bit string S of size s bits, s < 1. To do so using the interval method one would agree on interval values Ii, I₂,... L-i, such that å h = |L|. and construct string S_u, from the first bit of L, and concatenate to it bit number l+Ii, to which one would concatenate bits l+Ii + I₂ , and then l+Ii + ...I_t... Then one would construct bit string S_d, by listing the last bit in L (bit number 1), and concatenate before it (left to it) bit l-I_s-i, then concatenate before it (left to the 2 bits string) bit 1-h - I_/-/, etc. Let t = floor(s/2), namely the largest integer not larger than s/2, one would then build S_u by repeating the concatenation until |S_U| = t, and correspondingly one would build S_d by repeating the concatenation until |S_d| = s-t. Then one concatenates S_u || S_d to create string S of size s. In this method if a proportion of a of bits was flipped in L then the proportion of flipped bits in S will asymptotically also be a. This is the reason why the Interval method will be viable when data fingerprinting is used. There are several obvious variations for interval based reduction method. E.g.: One could continue S_u and not build S_d, or vice versa. Illustration:

we wish to reduce L to S where

We agree on a fixed interval

We have

We have t = floor(5/2) = 2. We build S_u = 01, and S_d = 111, and concatenate:

[00117] QR Writing of BitMint Money: A payer wishes to pass to a payee the sum of $X in BitMint money. The respective payload is x bits. The transaction is to be based on a QR graphics, of maximum bit contents of q < x bits, The meta data for the BitMint coin is a fixed size string M comprised of m bits. The payer elects to use the interval method. She computes the size of fixed interval I (i) as i = floor( x / ( q-m )) + 1, to reduce the payload from x to less or equal to (q-m) bits. This will represent x payload bits as y < x bits, and such that q > m + y. The payer then generates the respective QR, which is subsequently read by the payee. The value of I is communicated in the QR. The payee interprets the QR graphics to a bit string, and passes the string to the BitMint mint for authentication. The metadata in the QR and in the transmission to the mint, includes information on the selected intervals. With this information the mint can verify the redacted coin, checking that it reflects the information in the un-redacted version in the mint database. If all is well, the mint marks this coin as paid, and credits the payee with said amount, through money to its account, or through a freshly minted BitMint coin.

Claims

What is claimed is:

1. A system for payment of a centrally minted digital coin where the customers buy the coin from the mint, download it to their mobile device, then split the coin to make payment for any sum up to the sum of the coin, make such payment by directly transmitting the bits that comprise the coin to the receiving mobile device (the payee), using any method to transfer bits between devices, and accomplishing the transaction without real time intervention of any remote server, or any trading peers, thereby conducting such coin transfer by having two battery operated devices, and where mutual identification between the payer and the payee is optional.

2. A system as in claim 1 where the minted digital coin, or any part thereof, may be transacted from one holder to another, again and again, until one holder decides to redeem the coin by passing it to the mint, and receiving in return the nominal value of the coin.

3. A method to transfer a digital coin as described in claim 1 through extracting from the bit string that represents the coin, a smaller string that functions like a hash such that its possession indicates with very great likelihood the possession of the larger bit string that comprises the coin, then representing the extracted smaller string as QR code on the screen of the mobile device of the coin holder, then exposing the QR drawing to the camera on the device of the payee, for the payee to read the extracted string, and then to pass it on to the mint, where the mint verifies that the extracted smaller string was extracted from the full string of the coin, and then the mint authenticates to the payee the transaction.