CN112655008A - System for payment of centre cast digital currency - Google Patents

Abstract

A system for payment of center cast digital currency in which customers purchase currency from a core coin core, download the currency to their mobile device, and then split the currency to pay any amount up to the sum of the currency by: transmitting the bits constituting the coin directly to the receiving mobile device (payee), using any method to transfer the bits between the devices, and completing the transaction without any remote server or real-time intervention of any transaction peer, such coin transfer being performed by a device with two battery operations; and in this system the mutual identification between the payer and the payee is optional.

Description

System for payment of centre cast digital currency

Cross Reference to Related Applications

This application claims the benefit of the following patent applications according to the Patent Cooperation Treaty (PCT): U.S. provisional patent application serial No. N ° 62/671,421 filed on 2018, 5, month 15; provisional patent application N ° 62/714,735 filed on 5.8.8.2018; provisional patent application N ° 62/782,301 filed on 19.12.2018 and provisional patent application N ° 62/805,369 filed on 14.2.2019.

Technical Field

The BitMint is a payment solution based on a simple and robust method for digitizing and processing money. It is designed to be used as a global financial platform and therefore it has a variety of features related to stability, versatility, flexibility and security. Over time, these many features will need to be undertaken, inspected and tested. The design focuses on the following basic ideas: the money is represented as a series of financial bits, where the identification of the bits fully addresses security, and the exchanged value is expressed by a cumulative aggregation of the value functions of these well-ordered financial bits.

Drawings

Preferred embodiments of the present invention will hereinafter be described in conjunction with the appended drawings, which are provided to illustrate and not to limit the present invention, wherein:

fig. 1 presents a schematic view showing the BitMint element.

Fig. 2 presents a schematic view showing how the email server operates as a BitMint bank.

Fig. 3 presents a schematic view showing the functional parts of the BitMint module.

Fig. 4 and 5 present corresponding diagrams illustrating the BitMint dynamics.

Figure 6 presents a diagram showing BitMint digital currency including Capsule (Capsule) and payload.

Fig. 7 presents a diagram showing elements constituting a BitMint coin.

Fig. 8 presents a diagram illustrating a payload installer.

Fig. 9 presents a diagram showing how fbit (financial bit) accounting works.

Fig. 10 presents a diagram illustrating a core store negotiator.

Fig. 11 presents a diagram showing a bank and sub-bank centric payment configuration.

Figure 12 presents a diagram showing a BitMint mobile application configuration; and

FIG. 13 presents a diagram showing BitMint coin dynamics.

Detailed Description

The BitMint is a payment solution based on a simple and robust method for digitizing and processing money. It is designed to be used as a global financial platform and therefore it has a variety of features related to stability, versatility, flexibility and security. Over time, these many features will need to be undertaken, inspected and tested. The design focuses on the following basic ideas: the money is represented as a series of financial bits, where the identification of the bits is fully devoted to security, and the exchanged value is expressed by a cumulative aggregation of the values of these financial bits.

We propose a "skeleton" model here in which all unnecessary aspects are left unresolved, with the focus being left entirely to the basic process of casting BitMint notes, distributing BitMint notes, trading BitMint notes, purchasing (purchasese) BitMint notes, and redeeming BitMint notes.

The participants at this stage are: coin core (Mint) (to be constructed); the bank, which is to establish a coinage nuclear interface; and the selected trader.

The system comprises the following steps: module, interaction: the basic system includes four participants: (i) bank (B), (ii) BitMint coin core (M), (iii) BitMint purchase trader (T)_b) And (iv) the BitMint redemption trader (T)_r) And their interaction (see figure 1). We label the interaction between X and Y as<X|Y>Or<Y|X>These areComponent B, M, T_b、T_rRepresenting the computing modules associated with these functions.

Bank: the bank does not require special capabilities. It operates by managing the regular accounts of the participating traders and the regular account of the BitMint. The result of phase I will be the exchange of money between these accounts. The bank will consider the BitMint as a merchant. The goods will be BitMint's currency, but this is not critical to the bank. When the coin purchaser purchases the BitMint coin, he or she uses their conventional payment device to pay for it. Their bank account is debited by the amount specified and then the currency is transferred to the BitMint business account of the same bank-just like a conventional merchant. And just as a conventional merchant may accept their return of merchandise, the same is true of the BitMint case, but more commonly. Finally, each sold BitMint coin is returned, although not necessarily by the same trader. Upon such return, the bank debits the BitMint business account and credits the account of the currency redeemer. The BitMint will have at least two accounts at the bank-its business account and its business account. The business account will carry the money that the BitMint owns, while the business account will carry the money that the trader owns that is temporarily held by the BitMint.

BitMint Bank: managing the BitMint coins: this capability is optional and not part of the requisite set of capabilities. The BitMint Bank is any organization that holds BitMint coins on behalf of its owner. The security of the BitMint coin can be built into the coin itself (tethering) and this fact enables less secure organizations to operate like banks.

Just as people might choose to deposit their money in a bank account instead of carrying it in a stuffed leather purse, people are free to keep their BitMint note not on their communication device (e.g. smart phone), but in the hands of custodians, called banks, BitMint banks. In a conventional deposit account, money credits are represented as carefully managed numbers. In the BitMint bank account, the money item will be denoted as BitMint money. The coins may be associated with the account's owner as cash, or the coins may be tethered to their owner without having to be placed in a dedicated account.

This option will be used (i) to create old-fashioned continuity with respect to the familiar savings account; will (ii) serve users who are uncomfortable carrying a large number of coins on their communication devices; (ii) will (iii) allow bank-centric payment procedures; (iv) establishing an additional accounting subsection for financial auditing; (v) a new security dimension is provided due to the way the BitMint represents money; and (vi) will allow any organization, regardless of its security arrangement, to act as an account custodian for some particular community.

The BitMint Bank alternative embodiment will be used to study the two expected directions of the money and payment layout. One is to migrate a nominal bank account to a BitMint account, and the other is to develop a virtual bank for holding money deposits (e.g., each email account would be accompanied by a wallet).

E-mail bank: the bank may offer free email accounts to the public (as Google does) and set up an "email bank" -a repository for the BitMint coins tied to these email accounts. This would allow instant payment from one email holder to another. It would be attractive to merchants posting proposals for goods. An e-mail account holder will see a report of available credits associated with the account. They will be able to email money directly to any homogeneous account holder.

BitMint coin core: the BitMint coinage core { [ φ ] } is the core of the BitMint system and operation.

It comprises three parts:

BitMint negotiator { [ φ ] N }

This module communicates with the necessary three parties to perform the BitMint operation:

bank { }

Coin buyer T_b

Coin redeeming party T_r

It collects money from the buyer, credits it to the redemption party, and accounts in three related banks: funds are transferred between the coinage check account, the buyer account, and the redeemer account.

A BitMint core { [ φ ] C }, which is accepting casting requests and responding with cast BitMint coins.

The BitMint currency repository { [ φ ] R }, which records the foundry currency-its status and history.

We write: { [ phi ] } { [ phi ] N } + { [ phi ] C } + { [ phi ] R }

These three modules are managed via a coinage core control unit MCU, which also undertakes many accounting and management tasks.

BitMint negotiator { [ φ ] N }

This module communicates with the necessary three parties to perform the BitMint operation:

bank { } coin buyer T_bCoin redeeming party T_r

It collects money from the buyer, credits it to the redemption party, and accounts in three related banks: funds are transferred between the coinage check account, the buyer account, and the redeemer account. Internally, the negotiator module communicates with the core in two types of conversations:

request casting (R2M), after the correct payment for the coin, the negotiator will prompt a check to cast the coin in the amount quoted and pass the coin to the negotiator for further passing to the purchase trader.

Request validation redemption (R2A), the negotiator will pass to the core the currency or currency split (coin-split) submitted for redemption by the redemption trader, and expect one of the following three answers: (i) agreed-to redemption (OK), (ii) redemption-the coin is counterfeit (NC), or (iii) redemption-the coin has been redeemed (NR).

BitMint core: the BitMint core performs two tasks:

coinage requested. The negotiator will pass the coin request to the core, which will respond with a freshly cast coin.

Validating or rejecting the currency presented for redemption or split currency.

The request also comes from the negotiator and responds with one of three options: (i) agreed to redemption, (ii) counterfeit currency, (iii) the currency has been redeemed.

The overall scheme is as follows: RNG: the random number generator, BitMint coin builder this submodule accepts requests for coins and completes them. This is achieved by requesting a random bit string from a Random Number Generator (RNG). The module is divided into two smaller modules: (i) the capsule builder and (ii) the coin "charger", also known as the "payload installation program".

The BitMint digital currency includes two parts: capsule and payload.

The coin request is first processed by the capsule builder. The built capsule is then passed to a payload installation program to install the random bits into the coin (payload). The capsule (the prepared coin) with the payload installed is then passed back to the negotiator requesting it, and its image is passed to the repository. See fig. 4.

BitMint capsule builder: the BitMint capsule builder will build coins according to the schematic depicted in fig. 7.

The header and trailer are two unique symbolic (optional) designs for marking the beginning and end of the BitMint digital currency. When the capsule is fully assembled, it may be filled with dummy payload bits that will be replaced by the "payload installer" module. The built capsule will be transferred to the "payload installer" module.

BitMint coin header/tail: this is two unique symbols designed to identify the beginning and end of the BitMint digital currency. These tags may be upgraded to include split tags for identifying split coins.

BitMint Id: the identification section includes:

coin check mark: markers designed to fully identify the core of the coinage and the item. This is important because the transfer of the BitMint digital currency in the cloud will leave a trace, and one should be able to trace back the currency and identify it as a product of the coin core long after it is no longer "live" and the coin core has been turned off.

Coin identification: this is a unique coin identifier. There should be only one tuple of coinage core id-coin id. The strength of the BitMint is that the value and identity of the coin are inseparable. Thus, id is as important as value. The currency will retain its unique id even after redemption and expiration. When in this setting, what is important is the uniqueness of the Coin Id (CID), which at a later stage will be completely randomized, so that if the coin is traded on a blockchain platform and identified only by its CID, there will be no leakage of information about coin value, casting time, etc. At this stage, the coin ID will be incremented in the order of casting.

The valuation function: this function determines the monetary value of each fbit (financial bit) in the coin based on the position of each fbit in the payload string and the data captured in the fbit. The basic design will operate with one unified BitMint estimation function that will work for all coins cast at this stage. Nevertheless, an evaluation function will be assigned to each coinage to achieve independent evaluation. See below for details of the evaluation function setup.

State: a label for indicating the status of the coin. Selecting: (i) prepared (not born), (ii) present and good, (iii) present but sick, (iv) dead, not buried, (v) dead and buried. When the capsule is ready and before it is loaded with payload, it is set to the state 'not born'.

Split identification data specifying a sub-section of the BitMint coin. The beginning and ending fbit, or either of them and the bit length comprising the split payload section, will typically be identified. At the time of casting, the split flag will be 1 to | P | where | P | is the fbit count P of the payload. The trader who split his currency then sets a different value.

Timestamp: stamp with desired temporal resolution: date, date + hour, or even minute resolution.

Payload installation program: the payload installer receives the capsule from the capsule builder and reads from its contents the number of bits required to 'recharge' (or 'instrument') the coin. The payload installer then requests the required number of random bits from the RNG and fits them into the capsule, and then the payload installer sets the state of the coin from "not born" to "present". Next, the payload installer makes an exact copy of the presence token, forwards one copy back to the negotiator and one copy back to the store. See fig. 8.

BitMint coin validator: the coin validator accepts validation requests from the negotiator. The coin validator then looks up the requested coin ID in the repository. The response from the repository may be: (i) the requested currency is forwarded with its current redemption status marked as (1) "present and healthy" or its current redemption status marked as "present but sick". In the latter case, the situation will be stopped and manual intervention will be requested. Other responses from the repository may be: (ii) "No ID found", possibly because (a) the currency was redeemed long ago and is no longer stored in a valid currency-search area in the repository, or (b) the ID tag is corrupted, or (c) the requested redemption is counterfeit. Depending on the circumstances, "no ID found" may be sufficient to deny the redemption request, or it may be that the circumstances make it important to sort between options (a), (b), and (c) above. In the latter case, the verifier will therefore instruct the repository to take action. In this phase, due to range limitations, a response to "not found ID" will be accepted in face value, where all coinage will be stored in the valid search area of the repository.

If a coin is found and forwarded to the coin validator, the validator will compare the requested redemption to the redemption status of the stored coin. If all fbits (financial bits) proposed to be redeemed in the stored currency have not been redeemed, then only in this case will the response to the negotiator be: "grant redemption". In this case, the requested redemption of fbit will be marked on a copy of the currency that will be returned (update!) to the repository. If even one fbit requested in the redemption request has been previously redeemed, the redemption request is rejected, the currency status is updated from "present and healthy" to "present but sick", and returned to the repository. See fig. 9.

BitMint RNG: the basic design will be limited to pseudo-randomness, possibly adding a BitMint randomness filter that discards especially non-random sequences. The simplest option is to rely on a built-in random number generator within a certain implementation language. It is proposed to combine any such built-in randomness generator with a well-chosen PRNG algorithm. The combination of the sources of randomness will be done by successive XOR operations. The exact RNG configuration will be determined based on the demand level. In the event that many traders will request simultaneous purchase of the BitMint coins, the design will have to be ready to cope with the high demand generated on site. Due to the large difference in demand one expects (busy day than night), it would be possible to generate a random inventory in advance to meet high demand situations. This strategy is generally disfavored because the pre-stored random bits may be corrupted. Since the built-in RNG is usually very fast, it will be possible to extend it with a dedicated RNG with some intervals. An XOR of a set of p bits is assumed for every q random bits generated by the fast source. Such a combination of parts will increase the requirements on the randomness filter but will accommodate any high demands.

A randomness filter: the BitMint random filter examines the bitstream in groups of n bits at a time, where n is a design parameter that can be changed at will. Each character string N including N bits is given a randomness index ρ ═ ρ (N) based on its content. If ρ (N) is above the threshold T, the string is forwarded as a "pass". Otherwise, the string is discarded.

RI is calculated based on the idea that randomness is a lack of symmetry. We consider several symmetry options, SO₁、SO₂、...SO_t. The symmetry option is a symmetry test performed on the string of bits. For example, the string 0001000 is symmetric about a rotation around the middle. String 001001001001 is symmetric about a cyclic shift of 3 bits. Given an arbitrary n-bit string, we check if it fits any of the t-symmetric options tests. If so, we claim that the string has zero randomness and l 00% pairsWeighing is carried out. If not, we break the string into a minimum number of strings that are all symmetric. We agree that a 1-bit string will be declared as inherently symmetric, and thus each n-bit string will include some x-symmetric strings, where 1 ≦ x ≦ n. There may be several ways to decompose the N-bit string N in this way, and thus there may be various values for x. We assign s ═ x_min. The original randomness is then calculated: ρ ═ N (s-1)/(N-1). It is clear that 0. ltoreq. rho. ltoreq.1.

It is apparent that different N character strings comprising N bits are each associated with a different s (N) value. One of these s values will be the highest s_max. Thus, we can calculate the effective randomness index as: rho (N) ═ s-1)/(s_max-1), for which also 0. ltoreq. p.ltoreq.1. We set the threshold limit to 0 ≦ T ≦ 1, and only allow strings N where ρ (N) ≧ T. For a stream of r in bits per second entering the filter, the filter will evaluate i input strings, discard d strings, and admit o strings, resulting in an efficient stream of on/sec bit randomness. If the ratio o/i is too small, the filter will invoke self-tuning logic to reduce the value of T and produce an effective random stream.

BitMint repository: the depository is the part of the coinage core that requires the most stringent security measures. However, at this stage we are concerned with the basic payment dynamics and therefore will not use various security devices. We will not use integrity guards, Oracle, nor a write-once device. Further, this embodiment will not be archived. All coins issued during this phase will be stored in the real-time random access database and indexed by coin ID. Security will be limited to the standard database security provided by the database manager.

The repository operates according to two categories: (i) coin-related exchanges with the coinage core: (a) accepting a newly cast coin from the coin builder, and (b) talking to the coin validator, and (ii) running an accounting process in communication with the coin core negotiator. All of these operations are standard database primitives. See fig. 10.

The purchase trader: the purchase trader purchases the BitMint coins through a dedicated BitMint telephony application using a standard purchase program implemented through a dedicated application for any other product. All security protocols will be the same. The product will be the BitMint coin stored on the trader's phone. The relationship with the bank will be standard in purchasing the BitMint coin using the trader's payment protocol. In the basic design, the purchase trader will indicate the requested amount and perform a conventional payment for the nominal amount plus the nominal purchase fee. No kind of tethering information will be specified. The BitMint coin core will respond by issuing the fully constructed coin to the trader. The coin falls onto the trader's phone as if it were a song or other digital good and will then be removed by the BitMint application for storage for payment or redemption.

Redemption traders: there are two categories of redemption traders:

exchange redemption party: the redeemer sends any currency under its ownership to the BitMint coinage core and exchanges it with an equivalent currency of the same value but identifying a different one. The procedure is performed after paying the currency from the payment transactor to the transactor, and it is desirable to ensure that the payer does not pay the same currency to a third transactor who will be eager to redeem the currency. The exchange action provides the trader with freshly cast coins, which alleviates the fear of repeated consumption.

Terminal redemption party: the redemption terminal exchanges his or her BitMint currency for the legacy currency. The redemption terminal executes the same protocol as the normal return merchandise protocol.

BitMint, core: public payment: the entire BitMint apparatus is designed and constructed for one purpose: the public is allowed to perform payments in order to run their business and life. The payment of the trader to the trader is the core of the BitMint design. It can be done by fictitious and private means between any two traders. Which comes down to conveying information about the bit string. The BitMint payment is the most basic. It can be done between two strangers, with no internet connection even without battery power. The BitMint chip includes about n bits. The string may be communicated from its holder to its recipient in any form, the string including a printed barcode or QR stamp; perhaps in Base64 or many other forms. Given approximately t traders, let each of them know the bit identification of the BitMint coin x, then the trader who eventually gains this knowledge is considered the owner of x. And in order to actuate this principle, the trader will redeem whatever currency they know at the time of its occurrence. Redemption of a newly cast currency redeeming the same value will protect the redemption trader from the following risks: one of the (t-1) traders who is aware of the coin will abuse this awareness. But to the extent such abuse is not of concern, redemption is not necessary. The BitMint ecosystem describes a currency steady state in which a certain amount of value is shared and communicated among a community of traders. At this stage, traders would be encouraged to innovate a method for passing the BitMint coins to each other, but we would also provide a phone-based application (BitMint mobile application) to perform the following tasks:

BitMint Mobile application-function

We list the following functions: 1. storing value in the operating equipment 2, displaying the stored value in the operating equipment 3, purchasing BitMint digital currency from the BitMint coinage core 4, exchanging-redeeming BitMint currency from the BitMint coinage core 5, terminating-redeeming BitMint currency from the BitMint coinage core 6, passing BitMint currency to another trader 7, accepting BitMint currency from another trader 8, reporting BitMint payment history 9, special operations 10, wake and sleep routines.

The BitMint mobile application: storing, displaying and reporting: the BitMint Mobile Application (BMA) will require three persistent memories on the application device. The key is the memory for holding the coin, and the 'secure memory' holding the security key for protecting the coin. The secondary memory will hold the payment history. Upon activation, the BMA accesses the secure memory and uses its data to access the coin memory, and then displays 'wallet' on the display screen of the device, the total amount of coins stored in the device. The BMA displays the payment history according to the user's needs. This history can be easily uploaded to any other application on the device.

A secure memory: the memory contains persistent data that is protected by any security means provided by the operating system of the device plus a memorable activation key entered by the user in the BMA wake-up routine. The BMA uses this combined data to decrypt the coin in the wallet memory (where the coin is located).

Coin store (wallet): the coins in the memory are sufficiently small that the coins can be stored in sequence, thereby alleviating any requirement for the structure, which in turn could be exploited by a hacker. Then, assume that the BitMint wallet W is constructed as the sequence of BitMint coins W ═ C₁||C₂、…||C_wIt automatically aggregates to display the total on the device display. There is no need to subdivide each coin using any of its parameters and values. The user does not care how the total coins she can allocate accumulate, but only their total. In a subsequent stage, the user will be able to see the coins that make up a particular component.

Payment history memory: the memory accumulates the dynamics of each coin. It tracks each coin in and each coin out, including the time of the transaction and the identity of the payer. The history does not feature payload bits to reduce its privacy requirements.

Purchase redemption: we propose in the foregoing a basic transaction for the purchase and redemption of currency.

Purchase of BitMint coins: after selecting this option from the BMA function menu, the 'purchase' routine will display a 'purchase screen', which includes: 1. a window for inputting a desired amount of BitMint coins to make a purchase; 2. a window for entering payment data to allow the BitMint coin core to charge the user for the purchased coins. The routine will perform permission and plausibility checks on the entered data and will prompt the user to correct her input if any of these checks fail. Otherwise, the routine will activate the 'buy' button. Upon clicking the button, the purchase request will be transmitted to the BitMint coin core for execution. The response from the coin core may be (i) a failure to perform the purchase, followed by a list of reasons for the reply, or (ii) a note of 'successful purchase completion', with a single click of 'agree' prompted and returned to the main BMA screen including 'available coins' and a menu.

And (4) redemption: upon selection of the 'redemption' option from the menu, the user will be presented with a 'redemption screen' showing option selections: redemption-exchange or redemption-termination.

If the user selects ' redeem-exchange ', then ' execute it | is displayed! ' button, and clicking on the button, the entire wallet is sent to the BitMint coin core, and the newly cast total coins are delivered to the user. If the uploaded currency is problematic and only some is benefited for redemption, then the following policy issues: whether a message is returned stating that the inviting trader is personally in contact with the coinage core's ' irregularity ' and whether a bookmarked event number is being presented, or whether any agreed upon coins are redeemed and a regularity message is also added.

Redemption-exchanges, also known as 'refreshes', can occur frequently. Indeed, the high value wallet may be associated with a built-in refresh routine that will frequently refresh the coin as needed so that any theft of the coin will be easily discovered.

Exchange of traders: as indicated above, it is the core of the BitMint platform. We determined that:

1. remote payment 2. close identification payment 3. close unidentified payment.

The BMA will keep a record of all transactions, including the details of the transaction currency, but without the payload bits. After each payment, the paid-out currency will have its payload bits erased for security reasons and fraud. Hereinafter, the term "coin" also considers any split coin identified by the first and last fbit.

Remote payment: remote payment requires the remote transmission of the BitMint currency. We distinguish between internet and non-internet transmissions. Non-internet communications involve a variety of technologies such as conventional mail, facsimile transmission, and directly modulated electromagnetic radiation. The trader is free to initiate any of these techniques at his or her discretion.

Most and nominal long-range transmissions of the BitMint currency are internet-based. Thus, it is subject to man-in-the-middle attacks.

Internet-transmitted remote payments: the payment mode is divided into: key-sharing trader < non key-sharing trader. At this stage, we will not implement the key sharing mode, but only the non-key sharing mode. We will consider: the "e-mail based payments" is based on a messaging system.

Internet-based payment security between strangers: two online strangers can exchange the BitMint coins while relying on the nominal security provided by their browsers. A small denomination should be sufficient. The security of this mode will be enhanced by the following auxiliary protocol:

the required exchange-redemption of the book of failure

In this protocol, the payer notifies the coinage core of the payment transaction, and sets a time interval Δ t beyond which the currency remains under the payer's ownership if it is not redeemed. This requires the payee to immediately refresh/redeem the exchange of the currency, possibly requiring the provision of identification.

Book payer agreement: this applies to registered payers, sharing encryption keys with the coinage core. The payer will encrypt the currency using the key. The payee sends the coin piece to the coinage core for refurbishment and reveals the payer's identity to the coinage core to see how to decrypt and inspect the coin.

Multiple factor transmission security: two or more payment modes are used in which the encrypted currency is transmitted through one channel and its decrypted data is transmitted in another channel.

E-mail based BitMint payments: e-mail based BitMint payments can be performed in two modes:

BitMint mobile applications direct: direct payment from BMA to designated email address

Manual e-mail based payment: the currency of the transaction is reverted to the encoded data (printed BitMint currency) which is then put into an e-mail sent independently of the BMA.

BitMint private mail address

Bank-managed financial email: due to policy issues, banks may wish to provide bank management financial e-mail in the form of: username @ bank server name. The direct email routine may be limited to sending coins to such financial email addresses by email. To be granted such an address, the bank will issue a requirement to identify the user, and may require possession of the account in the bank. This may drive many new customers to the bank. Security will also be facilitated since all recipients are known entities.

E-mail BitMint currency is direct: the direct email subroutine is activated by the BMA user from the main menu screen. It displays an email send screen, prompting the user to specify: 1. the email address to which the coin was sent. 2. Optionally repeated entry of the recipient email address.

3. Dollar value to be paid 4. mode selection: "plain", "protected" and "certified".

The screen will also display a warning: the payment is irreversible, do you determine do you want to make this payment? Based on the mode selection, the appropriate sequence is performed: (i) a simple mode, (ii) a protected mode, and (iii) a verified mode. The easy mode is a simple action of mailing the BitMint coin to a specified email address. After sending the coin by e-mail, the coin is erased from the sender's wallet, unfortunately, if the intended recipient does not receive the coin, the sender may send a copy to himself to retrieve the coin. In the protected mode, the payload bits are encrypted and only if the recipient acknowledges receipt of the encrypted coin does the sender pass the encryption key to the recipient to decrypt the coin and use it. Only then will the conveyor erase the coin. In the underwriting mode, people use a protected protocol before wiping the currency from the wallet and then wait for the recipient to confirm receipt and exchange the redeemed currency.

And the bottom of the screen will be charged to! The "button" features to perform payment.

"easy" email payment mode: when pressing Payment! "button, and display" easy "mode, the email payment routine does the following: 1. it certifies that the wallet has enough individual coins that it is worth exactly or more than the amount to be paid. Note that: the e-mail routine will not aggregate coins. 2. If there is not enough money in a single coin, the subroutine would issue a warning to the result and redisplay the payment page as above and (i) the value of the highest coin in the wallet, (ii) the total value of the wallet, and (iii) a recommendation to refresh the wallet and obtain fresh coinage. 3. If there are enough coins in the wallet, the routine generates a Unique Transaction Number (UTN) and then sends the coin to the recipient and erases it from its wallet.

"protected" e-mail payment mode: when pressing Payment! A "button, and displaying a" protected "mode, the email payment routine performs the following: 1. it certifies that the wallet has enough individual coins that it is worth exactly or more than the amount to be paid. Note that: the e-mail routine will not aggregate coins. 2. If there is not enough money in a single coin, the subroutine would issue a warning to the result and redisplay the payment page as above and (i) the value of the highest coin in the wallet, (ii) the total value of the wallet, and (iii) a recommendation to refresh the wallet and obtain fresh coinage. 3. If there are enough coins in the wallet, the routine randomly selects a payment verification encryption key. (PV (Payload verification) key) 4. it applies the PV key to the transmitted Payload bits to generate an Encrypted Payload (EPL). 5. The routine generates a payment e-mail that is identified by a Unique Transaction Number (UTN) and then sends the currency through the e-mail using payload bits encrypted with the PV key. The email prompts the recipient to send a payment confirmation notification via email. At this stage, the transaction is in a pre-settlement mode. The currency is considered transmitted but in encrypted form. The BMA moves the paid out currency to a pre-paid out memory area so that it cannot be paid out again. The transmitter BMA enters a 'waiting' zone. No action can be performed on the payer side until the payee sends a confirmation of the coin transmission and a request for a decryption key via e-mail. When this happens, the transmitter sends the encryption key (encryption is symmetric, so the same key is used for both encryption and decryption). The key may be sent by email, or in any other channel. After transmitting the payment approval key (PV key), the transmitter will consider the payment to have ended, the request for the key will be treated as a receipt proof, and then the transmitter will erase the payload bits of the transaction currency to prevent any further payments by the owner of the device and any misuse by any hacker of the device.

And (4) payment certificate encryption: since the payload bits are highly randomized, there is no need to use a large key for any strong encryption. This task will be done using a small digital key that the phone can deliver. The encryption key would have to be randomly selected for each e-mail transmission. The proposed method is a final transposition, where the key is an integer N of arbitrary size. The higher the amount of transmission, the larger the range 1 to N from which the key K is randomly selected: k is more than or equal to 1 and less than or equal to N. For reference, see:Equivoe-T： Transposition Equivocation Cryptography。(https://eprint.iacr.org/2015/510.pdf)

the "certified" email payment mode: the "certified" mode continues like the "protected" mode, but the coin is not erased until the payee returns a notification that the coin has been well received and removed by the BitMint, or the payer has claimed (refreshed) the coin as transacted with the BitMint certification.

E-mail based manual payment: this mode is similar to sending cash in regular mail. The coin is restored to the document attached to the e-mail. No encryption, no security. Anyone holding the currency can redeem it. After the coin is dispensed, its contents are erased from the wallet.

Messaging-based system: there are many anonymous or semi-anonymous messaging environments that two strangers can use to perform a BitMint currency transaction. This should be limited to small transactions on private chat rooms because of the increased security risk. The messaging payments will be based on "texting payments," resulting in a Base64 coin expression, which can then be copied into any messaging stream. Once the coin text is formed, the coin is erased from the purse.

Manual BitMint payment: all remote payment options feature a "manual" category whereby the currency is reverted to documented data, which in turn is sent by email, fax, messaging, etc.

Non-internet transmission: non-internet communications involve a variety of technologies such as conventional mail, facsimile transmission, and directly modulated electromagnetic radiation. The trader is free to initiate any of these techniques at his or her discretion.

Telephone/fax payment: we distinguish between two modes: payment manually from BMA direct payment.

Direct telephone payment: the wallet owner will be enabled to send the BitMint coin as a message bound to the recipient's phone number. The message will be text based (Base 64). It will be activated from the telephone payment screen, displaying 1. a window for entering the amount to be paid. 2. Window 3 for selecting the telephone number to which the coin is to be sent (selected from the phonebook), window for entering the telephone number to be paid. 4. A warning that the payment is irreversible. A "pay" button. On "pay" click, the routine will generate a Base64 string for the coin to be paid and send it as a message to the indicated phone number. The routine will then invalidate the coin from the wallet. And finally, the routine will display a screen 'done' to the user, with a prompt to return to the main menu.

Manual payment: the user will request that the BMA generate a coin document which will then be the message delivered to the indicated telephone number. After the currency is restored to a document, its contents are erased from the wallet.

The identification of proximity pays. This model involves payments being traded between two parties that are physically close to each other and that identify each other. We distinguish between: electronic proximity payment and over-the-counter payment

Electronic payment involves any use of active electronic devices to perform payment. Over-the-counter (OTC) payments involve any payment similar to the traditional mode in which a payer throws some coins over-the-counter to a payee. Electronic proximity payments are further divided into (i) coinage core in the middle, (ii) networked payments, and (iii) battery operated payments.

Electronic proximity payment: the pattern is nominally out of range of this phase. Where a list of completion options is provided. It is divided into:

payment of coinage check in the middle: the model requires a BitMint coin core to be associated with to have the transaction occur. It provides maximum security and carries some additional burden.

Networked payments: this mode implements a network trust protocol in which a community of traders vouches for each trade so that the BitMint coinage core is not involved.

Battery operated proximity payment: in this mode, two battery operated devices perform a transaction. Trust may be provided via an encrypted trust certificate.

Old payment on counter: this mode is the most basic method of transferring value. Which may be performed with or without mutual identification. We discuss the following options: screen capture pay-print-mixed currency.

The first two relate to the routines for documenting the BitMint coin. Once documented, it may be 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 read it using his device camera. A third option relates to a device in which the coin itself is hidden in a way that easily exposes it and uses the data as a coin, however, any such exposure will be clearly visible, so that it will be almost impossible to pass the coin "as is".

Close unidentified payments: this is the most basic model, where there is almost no known exchange of value between two people. This also applies to the case where one party recognizes the other party but the other party does not recognize the first party. Surprisingly, this basic model provides many modern applications. One such application is contemplated within this embodiment stage. This is a promotional BitMint-account opening inducement.

Promotional BitMint-account inducement.

This option is designed to set forth the unique ability of close unidentified payments. The bank will use its promotional budget to print a card with the desired monetary value (say 200). The card will be identified according to its parameters and its payload will be written down as a QR statement. The bank's sales promotion specialist will pick a place where people are likely to be middle-grade wealthy and publicly distribute these printed currency bills. For example, passengers may be provided with these currency cards when they are queued from a newly landed airplane. It is assumed that the passenger has a firm financial base and is therefore a very attractive customer for the bank. The coin card will display the expiration date, say two days in advance. The coin expires after that date. The debit card will also show that it is only usable by people who have not yet owned an account at the bank. This will encourage the card-holder, who is already a customer, to transfer the card to a person who does not own the account at the bank. The card will direct its holder to download the BitMint application and activate the "read coins" option. This option will use the device camera to read the front of the card. The application will verify the contents of the card and inform the user that the currency will be credited to his or her bank account he or she chooses to open. An account will be opened by the device and this coin will be credited. This may be the most cost effective way to win a wealthy of customers.

Printing and short message sending of BitMint coins: the essential feature of the BitMint is the fact that the data itself is a coin. And this fact enables one to extract the BitMint note from the usual set of numbers in the computer address. The BitMint notes may be physically printed or given as text messages. This basic feature may be shown at this stage. We discuss: printing BitMint coin and sending BitMint coin by short message

Printing a BitMint coin: all payment methods provide a manual option where payment is performed by forwarding a documented version of the BitMint coin, considered "printed BitMint coin". To implement this payment option, the system will include a coin printing routine that will receive the BitMint coin and generate a coin document. The coin document will have a text portion and a graphic portion.

Text section of the BitMint coin document: BitMint icon: φ 2, coin Id 3, Currency: fbit mark 5, split mark: 6. the valuation function: 7. date/time printed 8 printer id: 9. payee id:

graphic part of BitMint note: prominent options are bar code, QR

Sending a BitMint coin by short message: the BMA will provide the feature of expressing the BitMint note in text based on the Base64 letters. It will be implemented by a text payment page featuring: 1. window 2 for indicating the amount to be paid-window 3 for the appearance of a texted coin. Once clicked, it copies the coin to the device active memory. The 'copy' button will equal 'pay' and when pressed, the coin will be erased from the wallet.

Accept BitMint notes: we discuss here the problem of accepting the BitMint coin from a peer trader. It is separate from the problem of purchasing and redeeming the BitMint coin. We distinguish between (i) the inbuilt acceptance capability and (ii) the manual acceptance of the BitMint note.

In manual mode, the payer will send an email, text, or 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 then pasted into a manual acceptance screen. The screen will also have a "verify yes/no" button in which the user indicates whether the coin is to be verified/refreshed immediately with the BitMint coin. The screen will also feature an "accept coin" button, which when clicked will cause the acceptance routine to interpret the pasted coin, followed by an indication of the correct interpretation. If the "verify yes" button is clicked, the screen will display the message "wait for confirmation/verify coin", next if so, "coin confirmed/verified", and otherwise "coin rejected". In the built-in mode, the BMA software will retrieve the tagged email or text directly and receive its content. In addition, it will activate the device camera and point to the user the graphic that points the camera to the coin. After a successful read, the screen will so indicate. Otherwise, the screen will indicate failure.

Bank-centric payment: the BitMint payment solution allows the trader to complete the trade without the real-time involvement of a third party. However, for continuity and habitual reasons, the BitMint payments may be made in a traditional bank-centric manner. This may occur through the BitMint bank account, which contains the full BitMint note, not just the number representing the credit. We consider an arrangement in which both the payer and the payee use a personal device acting as a wallet and possibly containing a BitMint note, both have a BitMint account in their chosen bank and both have a nominal account in their chosen bank.

This results in a payment matrix in which the two payment modes envisaged within the phase are marked:

special handling

And (3) wallet recovery: the user is encouraged to remember the wallet key rather than write it down. To do this, the BitMint will allow a user who has forgotten his remembered wallet key to recover his currency (at some cost). The wallet recovery operation will retrieve the encrypted wallet and permanent secure memory and deliver it to the BitMint coinage core. The remembered wallet key will be limited to 4 or 5 digits and thus will allow the coin core to perform a brute force cryptanalysis and retrieve the coin. Only the coinage core may do so because only the coinage core knows the information in the encrypted coin.

Wake, sleep routines: the most important responsibility of the wake and sleep routines is to service security issues. Upon activation, the BMA will: 1. a BMA welcome screen is displayed. 2. The user is prompted to enter a remembered wallet security key (MSK)3. using the secure data in the key secure memory and the WSK, the wake routine will decrypt the wallet memory. 4. The decrypted wallet memory will be processed to calculate the total amount of money in the wallet and display it on the BMA screen. 5. The wake-up routine will display a complete menu of functions available to the user.

And (4) encrypting coins: the BitMint currency will be encrypted in a two-layer scheme. The payload bits will first be encrypted to exploit their randomness and then the whole banknote will be encrypted to reject any information leakage.

BMA software configuration

The BMA software includes: user activated routine background routine.

It is also divided into: internal processing device communication software remote communication software.

User activated routines: these routines, which are activated by a single click on the central BitMint screen, return to the central BitMint screen after completion. Some routines may remain paused through the corner iconic markers; waiting for an external response, such as payment verification.

BMA background routine

The BMA runs a background routine. We introduce: billing (Book keep): the main background process would be to record payment events. It is necessary to pick up any unprocessed payment cases, especially in the initial operational phase. Currency merging: as a routine work, the BMA will verify/consolidate the wallet into a single currency of the same value. Since there is no tie-down, the merge will be completed at this stage. Once the tie-down is achieved, only coins that are identical tie-downs may be consolidated.

Wait for response routine.

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

And (3) Tri-Log accounting: the term "Tri-Log accounting" was created to represent the new accounting subsection provided by the BitMint coin. There are two divisions of nominal billing: income and expense. The BitMint note provides a third division that must coincide with the other two. At this stage, the functionality of the Tri-Log is greatly reduced, but nevertheless the overall monetary dynamics allow the overall financial scenario to be described in various cut-back sections and perspectives, all of which should be agreed and agreed upon. Since this phase is experimental, it is important to track coin dynamics and extract a large number of conclusions from them. The general scenario for Tri-Log billing is presented below. It shows the lifetime of the coins, their handoffs and their disassembly.

BitMint QR Payment

Passing edited BitMint notes via information-constrained QR graphics

A typical BitMint note includes a relatively large string of bits that exceeds the informational content of the barcode or QR depiction. The complete coin can then be transferred via several QR drawings, but this solution is very inconvenient. An alternative is to reduce the BitMint coin size so that it will fit into the QR mapping, and the reduced size will validate the BitMint coin for coin transactions. Unlike full-size BitMint notes, the reduced (or presumably edited) BitMint notes cannot serve as other tradable notes, but must instead be redeemed or exchanged via the BitMint coin core. This edited BitMint coin solution locates the BitMint at nominal value using some popular payment systems-creating a very similar and highly competitive user experience.

Brief introduction: QR has become a popular communication channel for various applications in its payment. For example, in china, two major consumer payment systems pay for treasures and WeChat provide the following convenience: the payer reads the payee QR to identify him (s or it) so that she can order the central account manager to transfer the indicated money amount X (phone normal indication) to the account represented by QR. The merchant has their account QR marked on a table, merchandise, wall, etc., and this is very convenient for the payer to capture the QR with her mobile camera, interpret the QR correctly, and communicate the transaction details to the payment account manager. The BitMint may trade by account and then the exact same process will apply to the BitMint. However, the BitMint can directly and uniquely trade: the payer sends a bit string of monetary value to the payee. The size of the penny bit string may be too large to fit into the QR representation. To overcome this size difference, coins may be allocated to several QR displays. This is inconvenient and convenience is a major factor when dealing with payments. An alternative solution is derived from the possibility that the payee sends the coin bit string immediately to the coinage core for identification and redemption or exchange. The token is of a larger size L (in terms of bit count). When the payee presents L to the coinage core, the coinage core verifies the identity of all bits in L and recognizes the payee's action as passing the coin back to the coinage core for redemption. Now ask a question: is the payee available to pass a shorter bit string S < L to the coinage core, so that the passage of S will convince the coinage core that the shorter bit string can only be constructed by a person with ownership of L? To be sure of the core of the coin in this way, it would be necessary to resort to probabilities. S should be constructed in the following manner: derived from and dependent on L, such that at least with respect to the sum of coins to be redeemed or exchanged, the probability that someone gets S without ownership of L will be negligible. The greater the monetary amount, the greater the probability that S should be calculated only by a person having ownership of L. QR payments are consumer payments that generally sum very little, so the probability of having S a proof of having L should not be too high. Based on this principle, we have devised a program for making a BitMint payment via QR communication in a manner similar to the user experience in other consumer payment programs.

Payload string reduction: the BitMint coin includes a capsule part (metadata) and a value part (payload). The capsule is of a fixed length, which is well suited for QR expression. What poses a QR challenge is the size of the payload. The size of the selected QR (q comprises | q | bits) must fit into the metadata (m) of the BitMint coin and the reduced payload bits r, which represent the full size payload p before reduction. (| r | < | p |). | q | is less than or equal to | m | + | r |. How one would reduce the payload p to a shorter string r to assure the BitMint coinage core that the derivative of r has ownership of p? The natural way to do this is one of many standards of hashing. The probability of fraud is confirmed. Hashing in the conventional manner, see [ fingerprinting data "https:// epict. iacr. org/2018/503.pdf ], may have drawbacks for the case where a small number of payload bits are accompanied by a flip (flip) identification, as required in a process called" data fingerprinting ". Even if only one of the payload bits is to be flipped, any standard hashing procedure will result in a completely different hash (r), which will make this solution unfeasible. This random flipping of bits can be overcome by reducing p to r using a spacing method. And (I) a method.

Payload granularity reduction: we consider a large bit string L comprising L bits. We wish to reduce L to a shorter string S, S of bits of size S bits<l. To do so using the interval method, one would do so at an interval value I₁、I₂、…I_s-1Are made coincident so that ∑ I_iL |. And constructs a string S starting from the first bit of L_uAnd will have bit number 1+ I₁To which it is tied, bit 1+ I₁+I₂Then 1+ I₁+…I_t… to the bit number 1+ I₁. The bit string S will then be constructed by listing the last bit (bit number L) in L_dAnd concatenates bits l-I before (to the left of) the last bit_s-1Then concatenates bits l-I before it (to the left of the 2-bit string)_l-I_l-1And the like. Let t be floor (S/2), i.e. the largest integer no greater than S/2, then one will tie up by repeating until | S_uConstructing S | ═ t_uAnd accordingly will be tied by repeating until | S_dConstruction of S | ═ S-t_d. Then the person will S_u||S_dAre concatenated to create a string S of size S. In this approach, if the bits of the α proportion in L are flipped, then the flipped bit proportion in S will also be asymptotically α. This is why the spacing approach would be feasible when using data fingerprinting. There are several obvious variations of the interval-based reduction method. For example: one can continue with S_uWithout constructing S_dOr one may continue with S_dWithout constructing S_u. Exemplifying: let L0111000111010011, | L | 16, we wish to reduce L to S, where | S | 5. At a fixed interval I₁＝I₂＝....I₄3 and I₅Agreement is reached on 4. For I ═ l, 2,. 5, we have Σ I_i3 x 4+4 x 16L. We have t-floor (5/2) -2. We constructed S_u01, and S_d111, then tie: s ═ S_u||S_d＝01111。

QR writing of BitMint coins: the payer wishes to pass the $ X sum of the BitMint coin to the payee. The corresponding payload is x bits. The transaction will be based on a QR graph with the largest bits satisfying q < x bits. The metadata of the BitMint coin is a fixed-size character string M including M bits. The payer chooses to use the interval method. She calculates the size of the fixed interval i (i) as i floor (x/(q-m)) +1 to reduce the payload from x to less than or equal to (q-m) bits. This will represent the x payload bits as y < x bits and let q ≧ m + y. The payer then generates a corresponding QR, which is then read by the payee. The value of I is conveyed in QR. The payee interprets the QR graphic as a string of bits and passes the string to the BitMint coinage core for verification. The metadata in the QR and in the transmission to the coinage core includes information about the selected interval. With this information, the coinage core may verify the edited coin, checking whether it reflects information in the unedited version of the coinage core database. If everything is ok, the coinage core marks the coin as paid out and credits the amount to the payee either in the coin to its account or by the newly cast BitMint coin.

Claims (3)

1. A system for payment of centre cast digital currency, in which the currency is structured as a fairly ordered string of bits and the identity of the bits is unable to determine the value of the currency such that the position of the bits in the string determines their value regardless of their identity, and in which a currency trader is able to extract a sub-string from the string of currency and pass it to another currency trader as a payment together with a value level associated with each bit in the sub-string depending on its position in the sub-string, wherein the value of each bit in the extracted sub-string is derived from the position of the extracted sub-string in the pre-extracted string; and in the system, currency traders purchase the currency from a coinage core, download the currency to their mobile device, and then extract substrings from the currency string to pay any amount up to the sum of the currency, such payment being made by: transmitting the bits constituting said extracted substring directly to the receiving mobile device (payee), using any method to transfer bits between devices, and completing the transaction without real-time intervention of any remote server or any transaction peer, such coin transfer being performed by a device with two battery operations; and in the system, the mutual identification between the payer and the payee is optional.

2. A system as claimed in claim 1 in which a recipient of a coin in the form of a sub-string of centre cast digital currency is also able to extract a sub-string from the received sub-string and pass it to a further transactor as a payment together with a value level associated with each bit in the extracted sub-string according to its position in the extracted sub-string, wherein the value of each bit in the extracted sub-string is derived from its position in a pre-extracted sub-string that has been paid to the extracting transactor; such substring extraction can be iteratively repeated as long as there are bits to be extracted; and in the system, each holder of the original coin or any substring thereof is able to forward such bit strings to the coinage core to redeem the coin as indicated by the value associated with the respective bit in the redeemed substring.

3. A method for transferring the digital currency according to claim 1, the method transferring the digital currency by: extracting a smaller string from the bit string representing the token, the smaller string acting like a hash such that ownership thereof indicates with a very high probability ownership of the larger bit string constituting the token; then representing the extracted smaller character string as a QR code on the screen of the coin holder's mobile device; the QR drawing is then exposed to a camera on the payee's device to cause the payee to read the extracted character string and then pass the extracted character string to the coinage core where the coinage core verifies that the extracted smaller character string was extracted from the full character string of the coin, and then the coinage core verifies the transaction to the payee.

Images