Interfungible bearer asset transaction system

Abstract

A cryptographic protocol system where plural images are held on behalf of plural parties by plural respective providers includes the following steps, choosing a first subset of providers by a first party; choosing a second subset of providers by a second party; storing images under control of a first party held by the first subset of the providers; storing images under control a second party held by the second subset of providers; choosing first ratios by a first party between providers of the first set; choosing second ratios by a second party between providers of the second set; and transferring images from control of the first party to control of the second party by decreasing those under control of the first party substantially according to the first ratios and increasing the images under control of the second party substantially according to the second ratios.

Description

[0001] Interfungible Bearer Asset Transaction System FIELD OF THE INVENTION Cryptographic protocols for novel transfer arrangements are disclosed. BACKGROUND OF THE INVENTION Transactions for goods and services are a crucial part of everyday life for most people today. Security in such transactions is crucial and cryptographic techniques are apparently necessary to solve significant technical problems in this area. Other major attributes of the technical means for the financial aspect of such transactions differ at the macroeconomic and microeconomic levels. Desirable attributes at the macro-level include: quick finality and resistance to systemic risk. At the micro-level, from the perspective of individual users, desiderata include: reduced costs and risks. There is, however, substantial room for improvement in prior-art payment systems, at both the macro- and micro-levels. The novel system disclosed here significantly improves these major attributes at both levels. It does this in part by allowing portfolios made up of multiple different assets to be held by each user with direct transactions between portfolios, while essentially preserving desired ratios in the respective portfolios. This is believed fundamentally impractical with prior-art systems, and yet is efficiently realized by inventive cryptographic protocols disclosed here. Transactions for goods and services today are most often accomplished by intermediaries, under the direction of users. From a macro perspective, this can introduce systemic risk, as these intermediaries are structured to take risks in their own investments in order to maximize their own profits. Also, such intermediation can technically introduce latency delay to the finalization of transactions, because transactions must be processed by a series of entities. From a micro perspective, it is generally believed that current intermediated payment systems consume an average of about 2% of transaction values in fees, with the poor paying the lion’s share of these high costs. Furthermore, consumers generally have to hold a single asset type in order to be able to conduct transactions; however, those particular assets are typically not good investments, being subject to low if any interest yield and even to inflationary devaluation that has in some cases become extreme. To address the macro issues, an innovative aspect lets asset ownership and control be provided directly to users. For instance, instead of an institution holding a portfolio that it manages and the institution offering accounts to users in a single national currency with risk of default by that institution, users select and hold, at least in terms of an aspect of control, the underlying asset portfolio themselves. This not only technically reduces systemic risk fundamentally but also latency to finality. From the perspective of micro- issues, the novel approach here both removes a level of intermediation, at least technically, and lets users hold a portfolio of assets, instead of the single national currency option typically needed for transacting today. This addresses the micro issues, by letting disintermediation reduce costs and allowing diversification across a portfolio reduce financial risk to the user. It also allows individuals the ability to manage a portfolio of investments at reduced cost. The cost reduction comes at least in significant part from making additional use of otherwise needed transactions to maintain or rebalance the investment portfolio. The prior art has not been able to provide such solutions, which at least is at least not contradicted by such systems not having been offered. Moreover, technical problems in offering such systems are believed fundamental to the prior art payment technology. For one thing, multiple accounts per user fundamentally makes transaction latency and risk rise to the level of the worst case of the total number and the combinations used. For another, the financial risk to users posed by the intermediary institutions are fundamentally not addressed. Furthermore, a linear increase in the number of asset types per transaction would not only increase fees and exacerbate incomparability, but make for further delay and potential errors. Credit is an important kind of financial services product, and being able to offer it in an agreed basket of currencies, as for example is done by the World Bank, reduces the risk that the values will diverge come repayment time. This makes such loans more attractive and thereby contributes to economic growth and stability. Prior art systems have not provided such loans at the consumer level, fundamentally it is believed because of the increase in transaction costs, incompatibility issues, and delays. The novel systems disclosed here allow such loans to be constructed whenever desired, efficiently, quickly and cost effectively, thereby facilitating credit and economic growth. Mutually agreed baskets can even be used for whatever agreement with future payments, such as supply chain, offering the advantages of baskets already mentioned for credit to these transactions as well. The innovative system disclosed can also provide atomic swaps between counterparties. These allow direct realization of futures contracts, which are known to be an important part of the real economy. Atomic swaps give the ability to create custody-free markets that even allow participants to prevent information asymmetry, which is inherent in prior art markets and can allow all manner of hidden manipulation. A further feature of the novel system is privacy, which is Increasingly being recognized as an important attribute of payments both retail and wholesale. Most prior art systems are believed to have a “trust us” sort of approach, where users must trust their privacy to the institution(s) realizing the system. With the innovative approach introduced here, the user-controlled privacy options of other digital systems can be brought to bear. Yet further features of the inventive system disclosed relate to auditability and security. Distributed ledger prior-art technology has provided transparency of the cumulative total amount of a particular digital currency that has been issued at each point in time. This high standard has not been met by prior-art centralized systems. The digital bearer instrument approach used here is also able to meet it. Moreover, it meets this standard in a novel way including multiple parties each issuing their own digital asset, and without requiring the heavy computational burden of redundant computation as in blockchains. Technical cryptographic protocol problems, beyond the techniques for security in such transactions known in the art, that are not solved by the prior art are solved by inventive technical cryptographic protocol aspects of the present disclosure. One example of such a technical problem and technical solution is realizing high performance and robust real-time systems that are based on separate entities, where each such entity provides custody of cryptographic images, and yet the central system allows transactions in effect transferring such images between the separate entities to be brought forward in real-time to an irrevocable state, but without real-time involvement of the separate entities, as has already been briefly summarized and will be described further for instance with reference to Figures 5, 6, 7 and 8, as well as also particularly Figure 11. Even in a system where only a single provider entity is involved per transaction, waiting for a provider to respond, as in prior art systems, would make the real-time system at least potentially some of the time as slow as the worst case response time of the worst performing provider, or even unresponsive if some provider does not respond. Furthermore, when a transaction involves a source provider and a destination provider, the real-time requirement is even more poorly addressed by prior art solutions: a delay or failure of any transaction could be caused by either of the two providers involved in the transaction. When a transaction involves more than one source provider and more than one destination provider, as is believed advantageous more generally and as mentioned in summary already for the innovative systems disclosed here, it is believed that the real-time requirement expands in difficulty dramatically and cannot be met robustly by prior art systems. The above requirement becomes even more out of reach for prior art systems in view of the further advantageous property achieved by the inventive cryptographic technical solutions of the present disclosure: assets owners are ensured that they can maintain a digital signature capability related to ownership of a published asset definition, a kind of digital control of assets transparently under provider custody, that is cryptographically secure and avoids technical risk. Moreover, this control can be maintained in effect continuously through periods involving multiple transactions. Also, inventive cryptographic protocol techniques, as disclosed for instance with reference to Figures 5, 6, 7 ,8, and 11to be described, ensure that a cryptographic unlocking can be controlled by the respective users, in a way that is verifiable by the users. And the techniques further ensure that user custody of value is unlocked only by users when one custody is replaced by another custody. As another example of a technical problem not solved by the prior art that is solved by an inventive cryptographic protocol aspect disclosed here, a first transaction enables a second transaction during a single real-time time window, by locking value ephemerally during the transaction until non-real-time settlement is later accomplished, as disclosed for instance particularly with reference to Figure 1l. The security of the techniques in some embodiments is based in part on the believed strong irrevocability of published information, something afforded by digital signature techniques and online posting. Furthermore, parties to the transaction are believed incentivized, by held back value resulting from the protocols, to complete the transactions. Yet another example of a technical problem not solved by the prior art that is solved by an inventive aspect of cryptographic protocols detailed in the present disclosure, such as for instance with reference to Figure 10, is atomic swapping of value, where either value transfers in both directions or value does not transfer. Neither user party to the swap can, without breaking properties provided by the cryptographic protocol, obtain value from a counterparty without the counterparty being able to obtain the swapped value. The solution solves the more challenging need for the two transactions to become irrevocable in real-time and be subject to incentivized settlement later. It has been disclosed elsewhere by the present applicant that such swaps are enabling for realizing markets where the user maintains custody of the assets and also metadata information related to their trades. Yet still another example of a technical problem not solved by the prior art that is solved by an inventive aspect of cryptographic protocols detailed in the present disclosure, such as for instance with reference to Figure 12, is a transaction between two offline parties including two additional potentially offline providers, where the amount of transfer is determined at the time of transaction. The information from the source party and the information from the destination party are only approximately accurate in terms of the amount of the transaction. However, the source and destination would each in some examples be prepared to cover a range. The source amount would typically be higher and the destination amount typically lower in its fixed portion with enough variability to cover the range. In some examples, as will be appreciated, the “net” amounts for the source and destinations may differ from a single amount. BRIEF SUMMARY OF THE INVENTION The inventive aspect related to providing real-time transactions by a central issuer entity, as already mentioned, are described here first in brief non-limiting summary, as will be appreciated. Transactions are based on separate custody by separate provider entities and, as mentioned, transactions can involve more than one such provider entity, such as for instance will be described with reference to Figure 11. Each provider entity, in the exemplary embodiments, has two buffers that can be said to be shared with the issuer. One buffer, called here a commodity-buffer_i (or buffer_j for short), contains images corresponding to the asset held in custody by provider_i. The other buffer, called here a liquidity-buffer_i, contains images corresponding to the assets of the issuer. The commodity-buffer_i is, in the exemplary embodiments, realized and controlled by provider_i and the liquidity-buffer is realized and controlled by the issuer. Control over the images representing value in the respective buffers can be by the provider and / or other entities, based on cryptographic keys created in forming the images. The issuer can mark entries in a buffer, in the exemplary embodiments as will be described in more detail, and such a marked entry should not be accepted as the source of a transfer unless and until it is unmarked, such as will be described with reference to Figure 2. The marking is in the examples by a separate mechanism that need not have other access to the images that can be marked. Also, the issuer can in such embodiments create new value in the liquidity buffer by injecting new value into that buffer; however, this can alternatively be by unlocking already previously created valid images. Transactions transferring from one provider to another provider include the issuer locking buffer entries and then allowing the unlocking according to pre-arranged subsequent conditions, including agreement by users involved in the transaction and / or by the issuer. BRIEF SUMMARY OF THE DRAWING FIGURES Figure 1 is an overall block and schematic plan view of an exemplary system in accordance with aspects of the invention. Figure 2A-D is an exemplary overall block diagram of exemplary systems in accordance with the teachings of the invention. Figure 2A is a peer-to-peer example with users and providers only in an exemplary system in accordance with the teachings of the invention. Figure 2B includes the issuer in an exemplary system in accordance with the teachings of the invention. Figure 2C includes the buffers per provider in an exemplary system in accordance with the teachings of the invention. Figure 2D includes the locking. Figure 3AB is an exemplary overall combination block, flow and cryptographic protocol diagram in accordance with aspects of the teaching of invention. Figure 3A is an exemplary transaction where user_a transfers i_money to provider_i in exchange for c_money from provider_i. Figure 3B is an exemplary transaction where user_b transfers c_money to provider_j in exchange for j_money from provider_j. Figure 4 is an exemplary overall combination flowchart and block diagram in accordance with aspects of the teaching of invention. Figure 5 is an exemplary combination sequence and cryptographic protocol summary diagram of a transaction from a provider commodity to an issuer commodity in accordance with aspects of the teaching of invention. Figure 6 is an exemplary combination sequence and cryptographic protocol summary diagram of a transaction from an issuer commodity to a provider commodity in accordance with aspects of the teaching of invention. Figure 7 is an exemplary combination sequence and cryptographic protocol diagram of a transaction from a provider commodity to an issuer commodity in accordance with aspects of the teaching of invention. Figure 8 is an exemplary combination sequence and cryptographic protocol summary diagram of a transaction from an issuer commodity to a provider commodity is shown in accordance with aspects of the teaching of invention. Figure 9ABC is an exemplary single direct transfer and an atomic pair of oppositely- directed such transfers, not relying on real-time interaction with providers, are shown in combination block, flow and cryptographic schematic in accordance with inventive aspects of the system. Figure 9A is an exemplary transfer directly from user A to user B in accordance with inventive aspects of the system. Figure 9B is an exemplary combination sequence and flow diagram of a transfer directly from user A to user B in accordance with inventive aspects of the system. Figure 9C is an exemplary combination sequence and flow diagram of a transfer directly from user A to user B in accordance with inventive aspects of the system. Figure 10 is an exemplary multiplicity diagram of various system components to illustrate some exemplary configurations in accordance with the teachings of the present invention. Figure 11 is an exemplary combination timing and block diagram of a transaction window in accordance with the teachings of the present invention. Figures 12A and 12B are exemplary combination sequence and cryptographic protocol diagrams of a transaction from a provider commodity to an issuer commodity with net amounts settable at transaction time in accordance with aspects of the teaching of invention, with Figure 12A being an exemplary view of the diagram in the already- explained style of Figures 5 and 6 and Figure 12B being an exemplary view of the diagram in the already-explained style of Figures 7 and 8. DETAILED DESCRIPTION Turning now to Figure 1, an overall block and schematic plan view of an exemplary system in accordance with aspects of the invention is described. Two users, a payer and a payee, are shown in a transaction that also includes tokens and value held by three providers along with an issuer. While the present figure shows exemplary portions in a single overview, the transaction operation and parties will be described further with reference to the remaining figures, as will be appreciated. In operation, an example transaction is initiated by a payer with payee. The payee party 87 (using payee phone 88) provides an optional request 29 to the payer party 85 (using payer phone 86), such as describing the value of and optionally the obscured authorization for, transfer onward 1b that is sought by the payee. Then the payer authorizes, ideally through authorizing signature 30, in the proportions of shares 21 and 22, at least to an approximation that can optionally include a probabilistic aspect, as will be described related to the payer commodity providers 42, the value store 3 of providers generally, and the particular portions 17. The signature authorization from the payer arrives at the issuer 50 shown as a dotted hexagon. The issuer is shown providing protection barrier 12 for the payee meta information, such as the payee share proportion(s) 23 and identity of the payee commodity providers 14. The protection of the information is, for example, from being learned by parties such as the payer. An example way to protect such information is by combining transactions in what is made public, as will be understood. The issuer also protects 13 the payer meta information, such as for instance ratios and identities of payer commodity providers 42, from being learned by the payee. Such protection can, for example, be by combining transactions in what is made public. Moreover, the issuer is shown potentially protecting transfer information 14 from third parties (such third parties not shown for clarity), in cooperation with payer and payee, such as the identity of the payer and / or payee and / or amount of value transferred 1a. The value and authorization 1b is transferred to the payee. The value is divided according to the ratios(s) 23, in this instance only one division is described for clarity. This commodity is realized by the payee commodity(s) provider(s) 44, again only one in the example for clarity. The key(s) 7, again one in the example, ideally chosen and / or exclusively known to the payee, are able to further transfer the value, once the value and authorization transfer 1b is received by the payee and the transaction is settled, as will be described. The providers, examples of which are shown as providers 42 and provider 44, store value 3 denominated in their respective commodities. For instance, user 85 has selected two example commodities 42 from the commodities set 10 and user 87 has selected in the example for clarity a single payee commodity 44. Each commodity in the commodities set has, as will be understood, in the example, a respective one of the providers 40. However, portions of such stored value are ideally owned and / or controlled at least in part by various users, such as portion 17 shown as associated with digital token images 62 and owned and / or controlled at least in part through key 6b of payer 85. Liquidity buffer(s) 35 and commodity buffer(s) 37 are shown for each respective provider 42 and 42. The buffers are for purposes at least including transactions being divided between parts that can be handled in real-time and parts that can be handled and settled later. These buffers ideally have buffer tokens 33 for the respective values they contain, and these tokens are ideally publicly visible. In some examples, the issuer party is able to lock portions of value and / or tokens within these buffers at the time of a transaction and provide the ability to unlock once aspects of the transactions have been settled, such locking information posted by the issuer not shown for clarity (however, it is shown for instance in Figure 2). The payer party and payee party are shown differently with respect to depictions of smartphones or the like. In the first example, the keys and share ratios and transactions are shown being performed in the smartphone on behalf of the user; in the second example, the keys and share ratios, for instance, are shown outside the phone, such as could for instance be in a separate secure storage device and / or remotely in a secure network protocol. This illustrates that various system configurations of user hardware and associated software are anticipated, with various configurations anticipated, between all in the phone and fully hosted. Turning now to Figure 2A-D, exemplary overall combination block, flow and cryptographic protocol overview diagrams are shown for various embodiments in accordance with aspects of the teaching of invention. Figure 2A is a peer-to-peer example with users and providers only; Figure 2B includes the issuer; Figure 2C includes the buffers per provider; and Figure 2D includes the locking. These four block diagrams are meant to illustrate some example points in the space of anticipated configurations of the inventive system. They are cumulative, in the sense that each figure includes everything in earlier figures. It will be appreciated with reference to Figure 2A, for instance, that some embodiments of the invention can operate without an issuer party and simply with providers and users. Also, with reference to Figure 2B, an issuer can be included but without buffers, such as when transaction responses from providers are provided in time, as will be mentioned with reference to Figure 11. As will further be appreciated, Figure 2C includes buffers but not locking, as in Figure 1 for clarity. But figure 2D is the full example, adding locking, which is shown able to mark each image in the pool; however, the marking rectangle is not shown for each buffer for clarity. Turning now to Figure 3A-B, an exemplary overall combination block, flow and cryptographic protocol overview diagram is shown in accordance with aspects of the teaching of invention. Figure 3A is a transaction where user_a transfers i_money to provider_i in exchange for c_money from provider_i; Figure 3B is a transaction where user_b transfers c_money to the issuer in exchange for j_money from provider_j. The common notation used for these two figures 3A and 3B is, as will be appreciated, believed to provide an overview level for clarity; more detailed descriptions of preferred cryptographic protocol embodiments will be provided with reference to Figures 4-7 and Figure 9B. Each of figures 3A and 3B is split into an upper and lower portion separated by a pair of wavy lines. The upper portion is what is to be performed by the issuer party without requiring real-time involvement of the various providers; the lower portion, as indicated by an hourglass icon, and is what is at least ideally performed at least at one or more later times when in the examples certain unlocking is accomplished. The overall transaction is shown with two bold transaction arrows between the parties in the upper section for each respective portion; the various pools and buffers of the various entities are shown in rectangles in the lower section for each respective portion. The icon symbols are provided for clarity, as will be appreciated, common to both figures 3A and 3B. A single circle shape represents c_money; a single rounded-corner square shape represents i_money and a single hexagon shape represents j_money. When the shapes are doubled, one nested concentrically inside the other, then they represent the same money but in the respective buffer. These are called buffer_i and buffer_j for the respective commodity buffers and liquidity-buffer_i and liquidity_buffer_j for the respective liquidity buffers. In some cases, for clarity, which liquidity buffer or commodity buffer is not indicated explicitly but is, as will be understood, that corresponding to the particular provider in the transaction. Cryptography is indicated for clarity by key, lock, and signature icons. The key icons represent informational keys, such as preimages of the images that are posted by the issuer representing value and / or for locking, as will be understood. For instance, without limitation, in the exemplary embodiments, these can be images are under so-called “one- way functions.” Anticipated are variations, such as for instance threshold schemes and / or as private keys with the images that are verifiably in correspondence with public keys and / or preimages that are related within a tree structure. The key icons show oriented bitting-down for locking or locked and bitting-up for unlocking or unlocked. The signature icon indicates a public key digital signature or the like, such as will be understood, used here to mean authentication of an image by whatever means. Examples of such signatures include asymmetric public key systems and so-called Winternitz signatures and / or where the image, or whatever preimage of it, corresponds to whatever type of public key. Referring now more particularly to Figure 3A, user_a is shown proffering i_money to provider_i and receiving c_money in exchange. It will be appreciated that one use of such transactions is for user_a to provide ready-to-spend c_money to the issuer for use in a subsequent transfer out from c_money to j_money or another currency. When two such transactions, or at least their real-time portions, are completed in a single time slot or window, because in part the c_money is known to the issuer to be ready-to-spend, the pair of transactions can typically for instance be used to in effect to transfer i_money held by one user to j_money to be held by another user in that same single time window. After such a pair of transactions, j_money may not be ready to spend, but sufficient confidence that it will soon be spendable is believed afforded user_b. The upper real-time portion in its upper section shows, in a first arrow, the proffering of authentication such as a signature by user_a related to the specific provider_i value and related to the recipient of that value being provider_i. More specifically, in the example, the left-side source of the arrow shows user_a sending a digital signature authenticating ownership of the particular i_money image in the commodity pool of provider_i, pool_i, and the signature ideally also indicating that the recipient of the value is released to issuer_i. That the particular image is in the pool can in the example be verified by the issuer in real-time, as will be appreciated, in a way that is proof against what is called “double spending,” meaning two instances of the same image both being verified, because all such spending must be at that nexus and excludes other spending by provider_i. The right-side destination of the first arrow indicates that the issuer posts a locking image corresponding to that entry in the i_pool; the locking is by the issuer posting an image, as already described, and can be unlocked with the corresponding preimage, which can optionally be a signature. The second arrow of the real-time portion in the upper section shows the corresponding transfer of c_money from provider_i in favor of user_a. The right-side source is c_money in the liquidity buffer of provider_i, as indicated by the double-circle as already described. The left-side destination of this second arrow is shown as c_money, which in the example is represented by an image in the c_pool. This image is shown in dotted lines as contrasted with solid lines, which is intended to cover two different cases, only one of which may apply: the image is created anew but effectively owned by user_a; or the image is not actually created by the issuer because it will shortly, such as in the same time window, be spent by user_a as the source for a subsequent transaction, as already mentioned. The lower section for this upper portion of Figure 3A shows four rectangles, each in the exemplary embodiment a collection of published images. Each image shown in the upper section corresponds to a respective image in a different rectangle in the lower section of the upper portion, as will be appreciated is indicated unambiguously visually by the corresponding shapes. In particular, the c_money is in the c pool; the locked liquidity buffer of commodity_i and the locked commodity buffer of provider_i are in the respective buffers, buffer_i and liquidity-buffer_i; and the i_money is in pool_i of provider_i. After completion of the upper portion by user_a and the issuer, without active participation being required of provider_i, the state of the various published images advantageously includes ready-to-spend c_money. This is, as mentioned, either controlled by and / or held in favor of user_a by issuer_i. It allows, in some examples as already mentioned, some immediately subsequent or “window-paired” transfers to be described with reference to Figure 3B that, as will be appreciated, do not require waiting for the lower portion of Figure 3A to complete. The two instances of the icon of this ready-spend value are shown dotted-line to indicate that they are freshly added to the c_pool in this transaction, again as mentioned. They are connected by a line for clarity and emphasis. The other three ends of the arrows of the upper section and the respective icons in the buffers and pools, as already described, are also shown twice: once in the upper section and once in the lower section. It will again be understood that the value that user_a has in effect transferred irrevocably to provider_i by the signature releasing the value, as shown in the upper leftmost icon, which the issuer can verify both as a valid transfer and as not being spent more than once at least during the current window, together with the issuer’s ability to lock images in the pool of provider_i, let’s the issuer obtain the ready- to-spend shown as the circle icon as the left-side destination of the second arrow. The locking of entries in the buffers and pools is, in the example, believed advantageously accomplished by the issuer posting images as locks, ideally in a way that only the issuer can post them and no party can remove them at least until they are unlocked. For instance, only the issuer would have so-called “write access” to the storage medium used for the posting or a blockchain could ensure that the data is not deleted. Such posting is, as will be understood, to be unambiguous as far as which image in a buffer or pool maintained by a provider such a lock corresponds to. To accomplish this, as one example, the locking images can be posted by the issuer each paired with a unique identifier of a buffer or pool image. As another example, the position of the images and / or pointers to them can correspond with positions in the respective buffers or pools. All manner of ways to ensure such correspondences are anticipated so that locking by the issuer can be readily recognized by those entities that seek such information. When locking is wanted by the issuer, the corresponding image is posted; when unlocking is wanted, it may be desired in some examples to post a preimage (e.g., the value that was the input to the one-way function that produced the image), that unlocks an image or images. It is anticipated that the posting of preimages can be by the issuer, even though the image may have been supplied to the issuer by a party such as a user that maintains the preimage as a secret until the party agrees to unlocking. It is also anticipated that the unlocking preimages can be a signature. Two unlocking keys are shown in both portions in the example. In the upper real-time portion, the keys are shown bitting-down as locking buffers and a pool; in the lower portion, as will be described more fully below, the same keys are shown, related to the same buffer and pool entries, however they are shown bitting-up, to indicate, as mentioned earlier, that they are indicating unlocking. In the example, for clarity and without limitation, simple division of keys between the issuer and counterparty are illustrated, as will be appreciated. In this present example: user_a is shown controlling the preimage for the lock on the entry in pool_i as well as that for the entry in the commodity buffer of the provider involved; the issuer is shown controlling the liquidity buffer lock. It will be understood, however, that various combination of joint control, thresholds, other parties, and even locking part or more than the value, and so forth are anticipated. The lower portion, still referring to Figure 3A, more specifically, again shows four icons in its upper section adjacent to arrows and the corresponding four in its lower section within rectangles. The first arrow shows the signature as the left-side source and the i_money canceled from the pool of provider_i as the right-side destination. It will be understood that such a cancellation of value in the pool of provider_i represents a diminution of liabilities for provider_i; this balances the transfer of c_money to the issuer by provider_i achieved through a cancellation of provider_i liquidity buffer value, as indicated as the right-side source of the second arrow. Thus, value can be considered to have gone around a cycle: from user_a to provider_i, then from provider_i to the issuer, and then from there back to user_a—the value has in the process been transformed from ready-to-spend i_money to ready-to-spend c_money. Accordingly, it can be said that, netnet, after settlement, i_money value has been exchanged for c_money value. As an example of a potential variant, instead of in effect canceling, what is sometimes called “burning,” value from the liquidity buffer to affect a value transfer from provider_i to the issuer, c_money could be paid using other means by provider_i to the issuer. Referring next more particularly to Figure 3B, user_b is shown proffering c_money to provider_j and receiving j_money in exchange. The upper portion again can advantageously be performed by the issuer without real-time cooperation of provider_j. The lower portion completes and finalizes the transaction. As already mentioned, if a transaction from commodity_i to commodity_j can yield ready-to-spend c_money in a first part of the two-part transaction, then the present transaction can in the second part of the two-part transaction convert the ready-to-spend c_money into i_money. Such a two-part transaction can, it is believed, be accomplished effectively as will be understood in a single real-time time window. In some examples when such a two-part transaction in a single window is accomplished it is believed that the posting of an actual image for the c_money can be omitted, with the c_money value being transferred what can be called here “ephemerally,” by the issuer from the first part to the second part of the transaction. More specifically, the left-side source of the arrow of Figure 3B shows c_money ready- to-spend, such as in the example indicated as authentication of ownership combined with authentication of the transaction. For instance, such authentication can be a signature on all manner of transaction details that can only be made using the preimage information corresponding to the image in the c_pool, as will be understood. The corresponding right-side destination shows the value being locked in the liquidity buffer of provider_j, in accordance with the nested-double-shape notation already mentioned. The liquidity buffer image is shown dotted line to indicate, as already mentioned, that this is a new or fresh image that can become a complete image in that buffer when unlocked. For instance, as just one example, provider_j can have supplied the images for this in advance, such as by posting them as future slots in the liquidity buffer and where the issuer marking such a slot as locked validates that the unlocking will yield a valid value in that buffer. The second arrow of the real-time portion, again in the upper section, shows the corresponding locked potential transfer of value from the commodity buffer of provider_j, as the right-side source of the arrow, to a potential fresh j_money image, as the left-side destination of that arrow. The image on the left-side is in the example freshly issued but chosen by user_b so that user_b has for instance exclusive ability to authenticate transfer of the value it will represent. It can, in some examples, be said to be owned and / or controlled by user_b, as will be understood. Again, this image for user_b is shown dotted-line to indicate that it is new and still not necessarily going to become a valid image in the j_pool after settlement in the second portion of the transaction. The image on the right-side source of the arrow, indicates an existing portion of the commodity buffer of provider_j that is locked in this transaction. Again, the nested double shape indicates that the image is in the buffer and the icon inside this shape that it is locked. This locking can be understood as a kind of escrow: when the transaction is properly settled in the second portion to be described, the escrow will be released and the provider_j will have the commodity buffer portion that it had before the transaction began. The net effect of the escrow thus does not change the value held by any party; however, it ensures that the parties cooperate to complete the transaction through to the release of the escrow. The lower section for this upper portion of Figure 3B shows four rectangles, each in the exemplary embodiment a collection of published images. Each image shown in the upper section, again, corresponds to a respective image in a different rectangle in the lower section of the upper portion and the correspondence is, again, indicated by repetition of the respective shapes. After completion of the upper portion by user_b and the issuer, without active participation being required of provider_j, the state of the various published images is believed advantageously adequate for user_b to obtain essentially adequate certainty that the fresh j_money value will be ready-to-spend once the second portion completes and, because of the escrow of commodity buffer already mentioned, some securitization of the value and basis to ensure that the second portion will complete. Moreover, because there is a second what can be called a hold-back for the transaction, that of value in the liquidity buffer of provider_j, there is extra incentive for provider_j to complete the second portion promptly, especially for instance if the releasing from escrow and of the hold-back include some contingency of one to the other. The other three ends of the arrows of the upper section and the respective icons in the buffers and pools, as already described, are also again shown twice in this lower portion: once in the upper section and once in the rectangles of the lower section. The bitting- upwards key icons indicate the example the final unlocking relative to the two buffers: user_b in the example for concreteness and clarity provides the key to unlock the escrow of the j_buffer and the issuer has, as will be explained, and provides the key to unlock the new commodity buffer image. The lower settlement portion of Figure 3B, shown below the pair of wavy lines, more specifically, again shows four icons in its upper section adjacent to arrows and the corresponding four in its lower section within rectangles. The first arrow shows the signature as the left-side source, but this time the icon is marked as canceled, as will readily be recognized by the addition of the slash diagonal line, to indicate that the value is no longer spendable or transferable and also, as can be a consideration in some embodiments, that it is no longer to be considered a part of the value of the buffer or pool. The key icons are shown bitting-up, indicating that when settled these preimages are released and the marking in effect removed and / or canceled ideally corroborated by the preimages as mentioned. The right-side source icon indicates that the lock on the held- back liquidity buffer value has been opened and thus released; similarly, the right-side j_pool icon is also shown as unlocked, indicating that the value is no longer subject to escrow already mentioned. These represent the final exemplary state after the completion of the settlement described with reference to the lower portion. The fresh image obtained by user_b from the j_pool has in effect been paid for by the cancellation of the c_money obtained from user_b yielding value that the issuer then in effect transfers to provider_j by allowing creation of a fresh entry on its liquidity buffer. Thus, value can again be considered to have gone around a cycle: from user_b to the issuer and then from the issuer to provider_j and then back to user_b—but it has in the process the value has been transformed from c_money to j_money. The j_buffer image is locked as a kind of escrow in the real-time upper portion but then unlocked again in the lower settlement portion, without net effect as mentioned. Accordingly, it can be said that, net net, after settlement, c_money value has been exchanged for j_money value. As an example of a potential variant, instead of in effect increasing the commodity buffer to transfer value from the issuer to provider_j, c_money can be issued by the issuer to provider_j. Turning now to Figure 4, an exemplary overall combination flowchart and block diagram in accordance with aspects of the teaching of invention. Each flowchart box will be described separately. In box 410 it is said “storing value at least on behalf of the payer as plural payer commodities selected from a commodity set” to mean that the payer has one or more assets that are at least roughly fungible within their respective asset types. In box 420 it is said “storing value at least on behalf of the payee as plural payee commodities selected from the commodity set” to mean that the payee has one or more assets that are at least roughly fungible within their respective asset types. In box 430 it is said “assigning at least on behalf of the payer of a predefined payer ratio between each of the commodities selected from the commodity set at least on behalf of the payer” to mean that between the commodities of the payer, at least for making of the particular payment, an at least preferred relative weighting is known to at least the payer entity, whether chosen by that entity or on behalf of that entity, in whatever way. In box 440 it is said “assigning at least on behalf of the payee of a predefined payee ratio between each of the commodities selected from the commodity set at least on behalf of the payee” to mean that between the commodities of the payer, at least for receipt of the particular payment, an at least preferred relative weighting is known to at least the payee entity, whether chosen by that entity or on behalf of that entity, in whatever way. In box 450 it is said “transferring of value from the payer in favor of the payee by decreasing the payer commodities at least approximately according to the payer ratios” to mean that the payer commodities are decreased ideally at least approximately according to the proportions mentioned with reference to Box 430 above. It will be understood that in some variants, a probabilistic element can be introduced so that the amounts are not determined but can vary; ideally such a mechanism can be verifiably fair to both counterparties, such as having it be based on a mutually random value as will be understood at least by those of skill in the cryptographic arts. In box 460 it is said “increasing the payee commodities at least approximately according to the payee ratios” to mean that the payee commodities are increased ideally at least approximately according to the proportions mentioned with reference to Box 440 above. Turning now to Figure 5, an exemplary combination sequence and cryptographic protocol summary diagram of a transaction from a provider commodity to an issuer commodity is shown in accordance with aspects of the teaching of invention. A typical so-called “sequence diagram” format is well-known in the art and used as will be appreciated here for clarity, with entities labeling vertical columns and messages shown as labeled horizontal arrows from sender to recipient. Vertical lines with circles at each end, what can be called “dumbbells,” bracket sets of messages to indicate that they can be in any order and even simultaneously. Within such a set, messages that are to remain in a fixed order are shown grouped with “I-beams,” vertical lines with short cap and footer lines. Numbers in square brackets “[n]” are used to provide indication for repeated messages. They are defined with equal signs “=” and then instantiated as “[]:” with defining text repeated for clarity. As already described with reference to Figure 3A- B, the pair of horizontal wavy lines separates the figures into an upper real-time portion and a lower settlement portion. The entities listed across the top, from left to right, are: “A” for user_a; “C” for the issuer; “c” for the entity(s) posting the c_money images on behalf of the issuer; “m” for the entity(s) posting the marks on behalf of the issuer; “i” for the entity posting pool_i images for provider_i; and “I” for provider_i. Referring specifically to the upper portion of the figure, the first three messages are grouped by the vertical dumbbell line, as mentioned, so they can be in whatever temporal relationship and / or they can be combined. All three are messages sent from “A” to “C,” and are accordingly sent by user_a in column labeled “A” and received by the issuer in column labeled “C.” The first message shown, as text on a horizontal line, is: “[1] = signed i_money payment in favor of provider_i using {image = [5]}” This is intended to mean a digital signature or other informational authentication as already mentioned that includes ideally an indication of the beneficiary, which in this case is provider_i. The symbol [1] is also defined in the message to be a copy of the rest of the message. The suffix “using image 5.1” is, as will be understood, to indicate the particular image that the payment refers to in pool_i. The second of the three messages is: “[2] = image for receiving c_money” to mean that “A” is supplying an image, with shorthand [2], that presumably “A” can authenticate ownership of, such as by producing a preimage or the like as mentioned. The third of the three messages is: “[3] = image for locking c_buffer_i and for marking pool_i” is a single image, with shorthand [3], that can in the example be used to lock two items; accordingly, either both would not be unlocked by it or both would simultaneously be unlocked by it. The second set of messages grouped by a dumbbell has four horizontal lines, the first three of which are simply those received by the issuer “C” from user_a: [1], [2], and [3]. The fourth is defined in the example for clarity as an image generated by the issuer from a random secret-key-like seed, as will be understood and described further below. It is the image to be used to lock the liquidity buffer entry, “liquidity-buffer_i,” as already described with reference to Figure 3. The first of the four messages in the set are from the issuer: the first to provider_i; the next to the place the c_money images are posted; and the last two to the place where the locking marks are posted. The first three messages have already been defined in the above set of three and are shown, respectively, as: “[1]: signed i_money payment to provider_i”; “[2]: image for receiving c_money”; and “[3]: image for locking c-buffer_i and for marking pool_i.” The fourth message, “[4] = image for locking liquidity- buffer_i,” is as mentioned, in some examples, the hash image of a random key-like value chosen by the issuer that is used to lock value in the liquidity buffer of provider_i and where the issuer can then use the preimage it created to if desired unlock this later. Referring now to the lower portion of the figure, the first message, “cancel image [5] in pool_i,” shows provider_i requesting the entity posting the images for pool_i to at least indicate as cancelled and / or delete or later delete, the image [5] defined in the first message of the upper portion already described. The second message, “[6] = preimages for {[4]:unlocking c-buffer_i and for marking pool_i},” sent from user_a to the issuer “C,” reveals the preimage corresponding, in the example, to the images that were used in the example for locking in the buffer_i and the pool_i. The remaining four messages are shown as bracketed by a single dumbbell. However, the first two messages shown are further grouped by I-beam’s into an upper pair and lower pair. The relative order of each pair is thus ideally that shown as from top to bottom with the I-beam pair; however, the order of the two pairs can be flexible as per the dumbbell. The first of the four messages, is from provider_i to its posting entity for liquidity- buffer_, shown in the example for clarity as “i”, is: “cancel image in liquidity-buffer_i.” The second of the four, from issuer to the issuer’s mark posting entity, is “preimage for unlocking liquidity-buffer_i,” which in effect unlocks, as already described, the earlier described locking of a portion of the liquidity-buffer_i. The third of the four, from provider_i to the provider’s posting entity, is “cancel image [5],” to indicate as already described the canceling the i_money, as defined by the corresponding image as already mentioned. The fourth and final of the four messages, shown from issuer to the issuer’s mark posting entity, is “unlock locks on c-buffer_k and pool_i using preimage received [6],” is a single preimage for unlocking two the two marks as already described. Turning now to Figure 6, an exemplary combination sequence and cryptographic protocol summary diagram of a transaction from an issuer commodity to a provider commodity is shown in accordance with aspects of the teaching of invention. The entities listed across the top, from left to right, are: “B” for user_b; “C” for the issuer; “c” for the entity(s) posting the c_money images on behalf of the issuer; “m” for the entity(s) posting the marks on behalf of the issuer; “j” for the entity posting pool_j images for provider_j; and “J” for provider_j. Referring specifically to the upper portion of the figure, the first message is shown as a from provider_j to the issuer. It is shown dashed-line to indicate that it can be done well in advance or incrementally as desired, as will be appreciated. What is sent are images that can be used in future by the issuer, but for which provider_j knows preimages. It is shown as: “

[0010] n = future-image_j”, where the “n” indicates that there may be more than one such image supplied in advance and this is the particular one uniquely used here. The next two messages are grouped with a barbell as already introduced with reference to Figure 5. The first is signed c_money being sent from user_b to the issuer. What is shown is: “

[0012] = signed c_money in favor of C for j_money authenticating {

[0013] = image;

[0014] = image for B to own j_money}”. The signature is what may be called “endorsed” over to provider_j, as shown by including this information in what is authenticated by user_b in showing ownership of the c_money, as already described. Also shown additionally authenticated is the image

[0014] that the user_b is requesting that the issuer use in issuing the new c_money to user_b. The second of the two messages is

[0014] , the image user_b sends the issuer for use in locking buffer_j: “

[0014] = image for locking buffer_j”. Next a dumbbell of four messages from the issuer is shown, with the first and third to the issuers pool posting entity “c” and the second and fourth to the issuer’s mark posting entity “M”. The first such message is the cancelation of the c_money sent as just described. In this example the posting entity is instructed to cancel the image

[0013] and the spending signature

[0012] is also sent for posting in this example to illustrate a corroboration of the validity of the cancellation, as will be understood. The second message is the request from the issuer to post locking image

[0015] received from user_b to lock the buffer_j entry for the j_money that will be obtained: “

[0015] : image for locking buffer_j

[0014] ”.The third message is also a locking request, but in this case it is for the liquidity buffer of provider_j and the issuer can create the image itself: “new liquidity- buffer_j image

[0011] ”. The third message is the creation of a new image in the liquidity buffer for issuer_j. The fourth message locks this image: “image for locking liquidity- buffer_j”. Referring now to the lower portion of the figure, that bellow the double wavy lines, the first message is from the issuer to provider_j to request the j_money image be posted “request for j_money with image

[0014] ”, even though that image has been pre-locked as mentioned. The image for this was supplied by user_b in the c_money payment to the issuer in the first message of the figure. The second message is from provider_j to its posting entity “j”: “j_money issued with image {

[0014] : image for B to own j_money}”. This is the requested j_money that will be owned by user_b as a result of this settlement portion. The third message, “

[0016] =preimage to unlock buffer_j”, is from user_b and in this example allows the user to ensure that the new j_money is satisfactory before providing this unlocking preimage. The fourth and fifth messages are in the final dumbbell and show the unlocking by the issuer by sending to the posting entity “M.” The first message is the

[0016] , the preimage received from user_b as just described: “

[0016] : preimage to unlock buffer_j”. The second message is the preimage known to the issuer, not shown for clarity, that was created before the locking image was created from it and sent as the last message of the first portion: “preimage to unlock liquidity-buffer_j”. Turning now to Figure 7, an exemplary combination sequence and cryptographic protocol diagram of a transaction from a provider commodity to an issuer commodity is shown in accordance with aspects of the teaching of invention. The column labeling, arrows and shorthand of the present figure correspond to those of the already described summary shown with reference to Figure 5. Instead of text defining and explaining of message content, the underlying cryptography is shown using a typical notation as will be understood by those of skill in the cryptographic protocol art. However, as will be appreciated, the corresponding descriptive messages and description provided with reference to Figure 5 can serve as a reference for and background to the present figure. The notation used in this (and again in Figure 8) emphasizes the “[n]” shorthand notation differently than earlier figures: when a value is in effect what is often called assigned or stored the “<-” operator is used. The curly braces “{}” notation as used earlier indicates a grouping for readability and disambiguation or clarification of evaluation order. Images are shown as the result of a simple one-way function “f” for clarity. Random key-like values created by an entity are shown as the result of the argument-less function “random.” The signature_x function denotes a public key digital signature or whatever related authentication technique for which entity “x” is able to form the authenticators; however, additional parameters can be included as authenticated in the signatures and so called “message recovery” property of the system is assumed. Text strings occur, for instance to indicate messages encoded suitably to posting entities, and will be shown with single quotes “‘’” as will be understood. Referring now specifically to the upper portion, the first three messages are from user_a to the issuer and are shown again grouped as a set with dumbbell notation already defined. The first of the three is “[1]<-signature_i([5]).” The shorthand [1] is defined to be assigned the value, as mentioned, that is a result of the signature_i function, also mentioned, applied to shorthand [5], which is as described with reference to Figure 5, the image of the i_money being signed over to provider_i. Encoded within the signature is a second parameter, ‘issuer_i’, indicating the transfer is to be made in favor of issuer_i. The second of the three, “[2]←f({[-1]←random}),” sets the shorthand [2] to the image under “f” of a random preimage that is, as will be understood from the notation, assigned a random key-like value, as already described. The preimage is shown as saved by user_a with shorthand [2.1]; however, since this is the preimage of value and not a lock, other parameters are believed likely to provide for in the preimage structure, such as the beneficiary as mentioned above, but not shown here for clarity. The third “[3]←f({[3.1]←random})” is the image from user_a for locking buffers as already described. The second set of messages are shown as four arrows from the issuer, the first to provider_i, the second to the issuer’s posting entity “c”, and the third and fourth to the issuer’s mark posting entity. The first three are simply the messages received from user_a, as already described, [1], [2], and [3]. The fourth is shown as “[4]←f({([4.1])←random}),” to indicate that this issuer creates an image [4] for locking the liquidity buffer, while saving its preimage as [4.1]. Referring now to the lower portion of the figure, the first message, “ ‘cancel image in pool_i’ [5]” is from provider_i requesting its posting entity for pool_i to cancel the image [5], as already described. The second message, “[3.1]” is sent from user_a to the issuer “C,” and reveals the preimage corresponding, in the example, to the images that were used in the example for locking in the buffer_i and the pool_i. Here, for illustration purposes, user_a releases this before the pool_i image is canceled by the provider, relying presumably on the issuer to check that before releasing it or the other unlocking preimage. The remaining four messages are again shown as bracketed by a dumbbell with the first two grouped by I-beam’s into an upper pair and a second I-beam grouping the lower pair. The first of the four messages is from provider_i to its posting entity for liquidity- buffer_i, is “‘cancel’; liquidity-buffer_i,” instructs the posting entity to change the posting of images in liquidity-buffer_i to canceled, so as to transfer value to the issuer, as already mentioned, as already described. The second of the four, responsively, as indicated by the I-beam, is where the issuer should provide the unlocking preimage, [3.1] as already described, to the marking posting entity, which entity can compute from its image [3] and with a kind of message recovery, the posting entity knows to remove the mark, with or without the option of posting the preimage as already described. In the lower pair of messages, the senders and recipients are the same as in the upper pair just described. The first message is “signed_i (‘cancel’, liquidity-buffer_i),” on a dotted arrow, which is intended to illustrate some example variation, as will be appreciated. For one, all messages to posting entities can be signed, as known in the art, or the whole channel authenticated, so this has been omitted above for clarity; however, here shown is an instance where such a message is signed. It is also an example of showing a provider giving a kind of notification to the issuer instead of the issuer check with the posting entity or being kept up to date by that entity. The final message of the two and of the four bracketed by the dumbbell is the issuer communicating to its marking entity that the locking mark on the commodity buffer and pool_i is to be removed: “ ‘unlock’ liquidity-buffer_i; [4.1].” Turning now to Figure 8, an exemplary combination sequence and cryptographic protocol summary diagram of a transaction from an issuer commodity to a provider commodity is shown in accordance with aspects of the teaching of invention. The column labeling, arrows and shorthand numbering of the present figure correspond, at least approximately, to those of the already described summary shown with reference to Figure 6. Again, as with Figure 7, instead of text defining and explaining of message content, the underlying cryptography is shown using a typical notation and, again, as will be appreciated, the corresponding descriptive messages and description provided with reference to Figure 6 can server as a reference for and background to the present figure. The first message, again shown dashed-line, is elaborated here to indicate the sequence of images that can be sent in advance and the construction of these images by the random key-like generation and saving of preimages already described. The message is shown as: “[10.1]<-f([11.1]<-random_1); [10.1]←f([11.2]←random_2);...[10.n]←f([11.n]←random_n)”. An ellipsis notation is used to define the whole sequence inductively form 1 to n. The notation [10.n] makes explicit the indexing of such shorthands that was implicit in the overview described with reference to Figure 6. Each image [10.n] accordingly has a preimage [11.n]. The transaction begins with two messages, shown as a dumbbell. The first is: “

[0012] ←signature_c(f({

[0013] ←f({

[0019] ←random}))”. This is the form of the signature from the issuer used in paying by user_b of c_money in favor of provider_j, as earlier described. The signature itself is shown as

[0012] and the image signed as

[0013] ; however a preimage

[0019] has been constructed from the result of key-like random generation of preimage and saved as a so-called “side-effect,” as will be understood. The second message is “

[0014] ←f({

[0015] ←random})”. This is the locking image

[0014] already described with reference to Figure 6 where the user keeps the key-like preimage

[0015] . Next a dumbbell of four messages from the issuer is shown, again alternately to the posting entity and lock posting entity, as already described with reference to Figure 6. The first contains the cancellation of the c_money image

[0013] to the c_money posting entity “c” but in this example it is corroborated with the actual signature

[0012] received from user_b. The second is the locking image

[0014] where the user has retained the key- like randomly generated preimage

[0015] as earlier mentioned. The fourth is the posting of an image for the liquidity-buffer of provider_c that was previously sent to the issuer, as mentioned with reference to the first message of the present figure. Referring now to the lower portion of the figure, shown below the double wavy lines, the first message is “‘request j_money with image’

[0014] ” sent from the issuer to provider_j. The response from provider_j is shown as the requested signature, or at least the image signed, being posted at the posting entity for j_money, “P”: “signature_j(

[0014] )”. It will be understood that posting the signature makes it available to “B” and “C,” although it can also be sent to those parties; nevertheless, the image posted and the preimage only known to user_b will be understood as value controlled by and in favor of user_b. The third message, presumably responsive to the second, is the unlocking preimage “

[0015] ,” described with reference to the third message of the present figure, being released by user_b to the issuer. The final two messages are shown as a dumbbell set. The first of the two, “

[0015] ,” is the sending by the issuer to the mark posting entity “M” of the preimage received from user_b. The second is the sending of the preimage saved when the lock for the liquidity- buffer was created by the issuer. Once these two messages are released, they unlock the final settlement of the transaction. Turning to Figure 9A-C, a single direct transfer and an atomic pair of oppositely- directed such transfers, not relying on real-time interaction with providers, are shown in combination block, flow, sequence and cryptographic schematic in accordance with inventive aspects of the system. Figure 9A is a transfer directly from user A to user B; Figure 9B is a combination sequence and flow diagram of a transfer directly from user A to user B; and Figure 9C is an atomic swap of i_money for j_money between users A and B, which is made up of two superimposed-in-time instances of the Figure 9A and Figure 9B, one in each direction. Referring now more specifically to Figure 9A, user A is shown transferring i_money directly to user B, without interacting with provider_i, and then, after a possible time delay in a second phase of the transaction, the transaction is settled with user B holding the i_money instead of user A holding it. More particularly, user A is shown sending an authorization for user B to obtain the i_money. In one step, the issuer “locks” the i_money transferred in pool_i and a corresponding amount of i_money in buffer_i. Later, shown below the double-wavy line, once provider_i has created the entry in the pool for the new image that A has sent, the preimage for the lock is shown being released by party A. This allows the locks to, in effect, as already explained with reference for instance to Figure 3 and Figure 5 and Figure 7, unlocked and removed. At that point, the i_money from the pool is removed so that the records are in effect cleaned up. Referring now more specifically to Figure 9B, a combination sequence and flow diagram of a transfer directly from user A to user B is shown. The first message is an optional request from B to A for a certain amount of i_money. This can, as will be described with reference to Figure 12, be an image that is both mix-wrapped and blinded. In other examples, instead of a message, for instance, the same information can be published for anyone wishing to pay B. The advantage of such information is that it can let A make a variable amount payment to B, as will be appreciated. The second message is shown as “signature related to request” to mean that as the wonder of the i_money in the example A is able to make a signature related to the image, based on the preimage that A created being a private key, as will be understood by those of skill in the cryptographic art. Such a signature or other authentication would, it is believed, ideally “bind in” the information of the request just described, at least as a matter of cryptographic good practice. The second message contains a second component, shown as “locking image,” since ideally B would be able to choose the preimage for this randomly and maintain it as a secret like a cryptographic key, until wishing to unlock, as will be described. The issuer, C in the figure, forwards the locking image received in the example to the lock posting entity “m.” At this point, both the buffer_i entry is locked as is the i_pool entry for the i_money sent by A above the wavy line. Below the wavy line, provider_i should update the published i_pool data. For one thing, the update should include the new signature, resulting from the effective withdrawal request, shown dotted-line. For another it should clean up the i_pool by removing the image that should now be canceled that was locked. Once these two things are accomplished, and optionally a signature is sent to B for the fresh i_money, as will be understood has resulted from the embedded withdrawal request, the preimage for the locks should be released by B, as is similar to the protocols described with reference to Figure 5 and Figure 6. The preimage, once received by the issuer, in the example, is shown being posted and removing the lock, when received by the locking entity “m.” In some variations, the locking preimage can be known to the issuer and / or the signature by provider_i on the blinded image can be considered an unlocking preimage for a portion of the locked items and the other portion can be controlled by a preimage only known to the issuer. Referring now more specifically to Figure 9C, i_money is again being transferred directly from user A to user B but also, atomically, j_money is being transferred directly from user B to user A. And again a “real-time phase” is shown above the double wavy line; a subsequent “settlement phase” below the line. If these two transactions are known to the issuer as linked atomically, the issuer can, in the same time window, try to complete the above-the-wavy-line portion. Turning to Figure 10, shows multiplicities of various system components to illustrate some exemplary configurations in accordance with the teachings of the present invention. A single organization, such as a bank or for instance another kind of financial institution, could in effect synthesize a system where its customers could each have accounts divided in certain ratios between multiple assets and / or asset categories, as will be understood. One strategy it could employ would be to manage its own portfolio with customer assets and in effect synthesize the product based wholly on indexes for the respective assets. It could then apply various hedging strategies for protection against changes in price that could affect it adversely; however, these could be expensive even if all risk is removed. A different strategy could be to hold at least some of the assets along with some additional inventory for each, to try to anticipate customer requests during the delay in its ability to change its holdings of the corresponding assets. A second bank might provide the same type of product to its customers. Transactions could be conducted between banks, one user counterparty could be a customer of the first bank and the other a customer of the second bank; provided, however the asset types that are common to both banks’ offerings. To accomplish any resulting transfer of value between the banks, at least on a netting basis, each bank could have a traditional corresponding account at the other bank, as is known in the financial services prior art. If there were more such banks, transactions could be between counterparties that are customers at two of the banks, provided that the banks have corresponding accounts or the like. When multiple systems each offer different asset sets, users may each be a customer of more than one such system so that they can access the union of the sets. An example configuration is a single issuer whose assets are offered by multiple banks, such as to complement each bank’s own set of assets offered. Another example is separate issuers or banks for separate asset classes. In various such settings, transactions between users would be divided between systems so that within each division both users have access to the asset classes involved; however, the decisions about how exactly to round and adjust the amounts of each asset would, it is believed, at least follow a common algorithm per user, which would access to the complete transaction amounts. This could ideally be on the user’s own equipment, at least for privacy of the details to the user. A bank might become, at least over time, and for portions of the assets, an issuer. This is believed to afford various advantages, at least to users. For one thing, users can gain actual custody of the underlying assets and not be subject to the risk of the failure of the institution. For another, privacy in holdings and transactions can result, as will be understood. For the bank, risk would be reduced. Multiple issuers offer further combinations. With two issuers having at least overlapping asset types, each of two counterparties could use a different one of the issuers for transactions within the overlap. The real-time inter-issuer transfers such transactions call for can be achieved by a pair of liquidity buffers, one per issuer. Turning to Figure 11, shown is an exemplary combination timing and block diagram of a transaction window in accordance with the teachings of the present invention. Time is shown horizontally, as denoted across the bottom of the figure. The horizontal ellipsis on left and right indicate that this time window, shown as a single instance for clarity, is one of many, such as part of a series and / or potentially overlapping intervals, as will be understood. The transaction window proper is set off by the solid vertical lines, whereas there is a pre-transaction period and a post transaction period, bounded by respective dashed lines. In the transaction window instance example multiple users are shown on the paying (left) side of the issuer and multiple on the payee side (right) of the issuer. Each user is shown with plural asset types (boxes) and these are shown traveling into the issuer “lane” for the particular pair of user counterparties, as will be understood. The amounts of the assets sent in payment—in the ratios for payment by the payer (which can differ from those set for payment into that same user)—are in effect converted to c_money, as will be understood serves as an ephemeral interchange medium of exchange in these examples. Similarly, the amounts of the assets sent out—in the ratios for receipts by the payee (which can differ from those set for payment out by that same user)—are in effect converted from c_money, as will be understood. During the pre-transaction interval, in some examples, the rates between the various assets, for determining amounts can be made known exactly for this nth transaction, by the issuer, in some examples; however, as will be described with reference to Figure 12, some inventive cryptographic protocols disclosed here do not require an exact value at this time, perhaps only an approximate value if it differs substantially from a longer- term approximation. During the post-transaction interval, in some examples, the various individual transactions can settle, as described more fully earlier at their own speeds. The jagged line marking the close of this interval is intended to suggest this timing for simplicity in explanation, as will be appreciated. Also, shown below the transactions that go through c_money, are direct transactions between pairs of users, such as have been described already with reference to Figure 9. Each of the providers is in effect handled directly and apparently separately; however, the grouping can allow the issuer to ensure that either all of the providers involved in the transaction complete the transaction, or none of them do. Also, these transactions can be unidirectional (left to right), like those above, or bidirectional, such as for atomic swaps as already described with reference for instance to Figure 9. Turning finally now to Figure 12AB, an exemplary combination sequence and cryptographic protocol diagram of a transaction from a provider commodity to an issuer commodity with net amounts settable at transaction time is shown in accordance with aspects of the teaching of invention. Figure 12A is the diagram in the already-explained style of Figure 5 and 6; Figure 12B is the diagram in the already-explained style of Figure 7 and 8. The payments made by the payer are for a slightly higher amount. What is returned is a variable refund amount that is in effect a withdrawal by that user. Similarly, a variable amount withdrawal by the payee (info for which was included in the payment request) is signed with the coin amounts for the approximation of the payment. Referring now to Figure 12A, and more particularly the first arrow, shown is “withdrawal request” information, as already described: the first component is the image prepared for mixing and the second component is the same image but blinded to receive a blind signature, as disclosed previously by the applicant. Each of these components is configured to receive a variable amount of value. For instance, the first component could be submitted to a choice of multiple mix batches, the particular choice being made to correspond to the particular amount; similarly, the blinded value can have multiple blinding factors so that it can receive various amounts of value encoded in the type of signature, as will be understood, and the non-funded factors can then be removed, also as is known in the art. The third is the sending of this received information by the payer “A” to the issuer. The third arrow is a message with the same communicants and form, but the payer “A” has in this case created the image, mix embedding, and blinding, for the purpose of receiving any net refund. The fourth arrow is from the issuer, “C” in these diagrams as above, to the provider_j, where a net amount of value set dynamically is made available to that provider for the benefit of the payee. And the fifth arrow is again from the issuer this time to the provider_i, where an amount of value set dynamically is made available to that provider for the benefit of the payer as a net refund. The amounts are here referred to as “net” to mean that whatever fees, and whether for instance value or transaction based, are deducted and / or added to the final amounts, potentially differently for the parties, as is known and will be understood. Referring now to Figure 12B, and more particularly the first arrow, shown as “[3]<- mix_enc([1]<-f({pre([2])<-random})); [4]<-[1]^a*b*c”. These are the same components as already described with reference to figure 12A in the style as mentioned of Figures 5 and 6, but like the other arrows, here in the style of Figures 7 and 8. So, the image is again formed from the random preimage here [2] using “f” and the image stored as [1]. This is shown with mix_enc applied, to denote embedding encryption for the various potential mixes this particular information can be supplied to. Similarly, the second component shows the image [1] again, this time “blinded in the exponent” in this example, as will be understood (however blinding in the base could also be used as is well known at this point) for three example signatures, those with the inverse of “a,” “b” or “c” as their secret exponents. The second arrow shows these two components being sent on by A to C as [3] and [4]. Also, the third arrow shows a similar pair but where instead A has chosen the primage [6] at random. And the fourth message is the first pair sent by C to issuer_j and the fifth is the second pair sent again by C but to provider_i. All manner of variations, extensions, substitutions and equivalents are anticipated. For instance, as just one example, so-called CBDC systems can comprise the providers.

Claims

What is claimed is:

1. A cryptographic protocol system where plural images are held on behalf of plural parties by plural respective providers, comprising: hoosing a first subset of providers by a first party; hoosing a second subset of providers by a second party; toring images under control of a first party held by the first subset of the providers; toring images under control a second party held by the second subset of providers; hoosing first ratios by a first party between providers of the first set; hoosing second ratios by a second party between providers of the second set; and ransferring images from control of the first party to control of the second party by ecreasing those under control of the first party substantially according to the first ratios nd increasing the images under control of the second party substantially according to he second ratios. In the cryptographic system of claim 1, comprising: so that the transfers of control ecome irreversible in a predefined time window independent of cooperation from the roviders.

3. In the cryptographic system of claim 1, comprising: at least one of the first and second parties having an authorizing digital signature capability based at least on cryptographic key information to authorize the transfer of at least one image from at least one provider. 4 In the cryptographic system of claim 3, comprising: a transfer of an image becoming rreversible substantially once a corresponding authorizing signature is released by the irst party and a corresponding digital signature capability is available to the second arty. In the cryptographic system of claim 3, comprising: at least one provider holding mages in a provider buffer. In the cryptographic system of claim 1, comprising: at least one issuer having the bility to place cryptographic locks associated with images in at least one provider uffer. In the cryptographic system of claim 6, comprising: a liquidity buffer corresponding o a provider and an issuer party wherein images are removed when images are ransferred to the provider. In the cryptographic system of claim 7, comprising: the issuer and at least one rovider each having at least some related partial custody of at least the liquidity buffer. In the cryptographic system of claim 8, comprising: access shared by the at least one rovider party and the issuer party to a buffer so that value can be locked when value is ransferred to the respective provider at least on behalf of the first party to a transfer andunlocked when a second party to the transfer accepts digital signature capability for the images received.

10. In the cryptographic system of claim 9, comprising: such that a transaction from at least one image controlled by a first provider to at least one image controlled by a second provider ensures that a party continuously has cryptographic custody of value ontrolled by at least one of the providers.

1. In the cryptographic system of claim 1, comprising: the digital images of a provider eing publicly visible.

2. In the cryptographic system of claim 1, comprising: information about the selection f providers by a one of the first and second parties protected from being learned by at east the other of the first and second parties.

3. In the cryptographic system of claim 1, comprising: information about the transfer of mages by at least one of the first and second parties protected from disclosure to third arties.

4. In the cryptographic system of claim 1, comprising: at least some information about he transfer of images protected from at least a provider party.

5. In the cryptographic system of claim 7, comprising: at least some information about he transfer of images protected from the issuer party.

16. In the cryptographic system of claim 1, comprising: a request from the second party to the first party including a request suitable for supply to a provider for at least one particular image to be transferred to cryptographic control of the second party.

17. The transaction of claim 1, comprising: so that the real-time processing of a first transaction supplying at least a value to a second transaction receiving substantially the alue so that the transaction is made irreversible during a substantially short predefined ime window.

8. In the cryptographic system of claim 17, comprising: where the first and the second ransaction can be completed in a single substantially short predefined time window.

9. In the cryptographic system of claim 1, comprising: the real-time processing of a irst transaction supplying certain images from a first party to a second party and a econd transaction supplying certain images from the second party to the first party; here either party can ensure that either both the first and the second transaction both omplete in some instances and both the first and the second transaction cancel in all ther instances.

0. In the cryptographic system of claim 7, comprising: the digital images of the issuer arty being publicly visible.

1. In the cryptographic system of claim 1, comprising: the digital images of at least ne provider party being publicly visible.

2. In the cryptographic system of claim 1, comprising: a request message from the first arty to the second party containing a withdrawal request by the second party.

23. In the cryptographic system of claim 7, comprising: in at least some instances of the transactions at least one provider sending authentication of irreversibility that is received in time by at least the issuer so that locking of respective buffers by the issuer can be skipped.

4. The cryptographic system of any of the preceding claims, comprising: transfer of alue held at multiple providers at least on behalf of the first party to substantially quivalent value held at least on behalf of the second party.

5. In the cryptographic system of claim 24, comprising: the amount of transfer etermined at the time of transfer and any excess net amount refunded to the source arty and the net amount for transfer adjustable to a net amount determined at time of ransfer.

6. In the cryptographic system of claim 25, comprising: a variable amount of transfer ccomplished by a variable amount of withdrawal for substantially the same request by t least a one of the first and second parties.

7. A system for transferring value from at least a first user, a payer, to at least a second ser, a payee, comprising: toring value at least on behalf of the payer as plural payer commodities selected from a ommodity set; toring value at least on behalf of the payee as plural payee commodities selected from he commodity set;assigning at least on behalf of the payer of a predefined payer ratio between each of the commodities selected from the commodity set at least on behalf of the payer; assigning at least on behalf of the payee of a predefined payee ratio between each of the commodities selected from the commodity set at least on behalf of the payee; and ransferring of value from the payer in favor of the payee by decreasing the payer ommodities substantially according to the payer ratios and increasing the payee ommodities substantially according to the payee ratios.

8. In the value transfer system of claim 27, comprising: at least one of the commodities f the commodity set held for at least one user by at least one commodity provider.

9. In the value transfer system of claim 27, comprising: an image being included in a et of images corresponding to units of value held in custody for at least one user by the t least one commodity provider.

0. In the value transfer system of claim 27, comprising: at least some information about he selection of payee commodities protected from being learned by at least the payer.

1. In the value transfer system of claim 27, comprising: at least some information about he selection of payer commodities protected from being learned by at least the payee.

2. In the value transfer system of claim 27, comprising: at least some information about he transfer of value from payer to payee protected from disclosure to third parties.

33. In the value transfer system of claim 27, comprising: at least some information about the transfer of value from payer to payee protected from the issuer party.

34. In the value transfer system of claim 27, comprising: at least some information about the transfer of value from payer to payee protected from at least one commodity provider.

5. In the value transfer system of claim 27, comprising: a request from a payee to a ayer including information for inclusion in the authorization to transfer value to be sent y the payer user to the payee user.

6. In the value transfer system of claim 27, comprising: the transaction transfers from lural providers in the commodity set on behalf of the payer to the issuer in a first phase nd from the issuer in favor of the payee at plural providers from the commodity set in a econd phase.

7. In the value transfer system of claim 27, comprising: the amount of value from the ayer and the amount of value to the payee determined substantially at the time of ransaction.

8. In the value transfer system of claim 27, comprising: substantially instant rrevocability of the transaction by the first party and the second party.

9. In the value transfer system of claim 27, comprising: in case provider response nformation received in time by issuer, the transaction completing in real-time.

40. In the value transfer system of claim 27, comprising: in case provider response information later than in time, the transaction completing after provider response information received.

41. In the value transfer system of claim 27, comprising: two instances of the transaction, each in opposite directions between the two parties, completing in one case oth completed and in all other cases the transactions being canceled.

Images