Open transactions

open transactions - это... Что такое open transactions?

open transactions
  1. открытые сделки


открытые сделки Сделки без фиксированного срока, с возможностью завершения операции или переоформления ее условий или ежедневной заменой обеспечения.[Глоссарий терминов, используемых в платежных и расчетных системах. Комитет по платежным и расчетным системам Банка международных расчетов. Базель, Швейцария, март 2003 г.]


  • платежные и расчетные системы


Англо-русский словарь нормативно-технической терминологии. 2015.

  • open software
  • Open Systems

Смотреть что такое "open transactions" в других словарях:

  • open transactions management — The process of managing open term transactions that are affected by corporate actions giving rise to market claims, transformations and buyer protection processing. Euroclear Clearing and Settlement glossary …   Financial and business terms

  • open transactions management — The process of managing open term transactions that are affected by corporate actions giving rise to market claims, transformations and buyer protection processing …   Euroclear glossary

  • Open interest — (also known as open contracts or open commitments) refers to the total number of derivative contracts, like futures and options, that have not been settled in the immediately previous time period for a specific underlying security. A large open… …   Wikipedia

  • open account — Trading on the basis that payment will be debited to the customer s account and settled on the basis of the payment terms applicable to that account. Easyform Glossary of Law Terms. UK law terms. open account n. (1) An unsettl …   Law dictionary

  • Open market operations — (also known as OMO) is the buying and selling of government bonds on the open market by a central bank. It is the primary means of implementing monetary policy by a central bank. The usual aim of open market operations is to control the short… …   Wikipedia

  • Open Dental — Practice Management Software Original author(s) Dr. Jordan Sparks …   Wikipedia

  • Open Buy Back — Open Buy Back, OBB, is a discountable securities traded in the Nigerian Inter Bank financial market. An Open Buy Back is a money market instrument used to raise short term capital. It is a form of borrowing using Nigerian Government Securities as …   Wikipedia

  • OPEN — Period (OPEN) The period that defines when the trading service is opened. London Stock Exchange Glossary * * * ▪ I. open open 1 [ˈəʊpən ǁ ˈoʊ ] adjective [not before a noun] 1. COMMERCE if a shop, bank, restaurant etc is open, it is allowing… …   Financial and business terms

  • Open source software development — is the process by which open source software (or similar software whose source code is publicly available) is developed. These are software products “available with its source code and under an open source license to study, change, and improve… …   Wikipedia

  • Open business — represents a concept of doing business in a transparent way by intimately integrating an ecosystem of participants, collaborating in public space. Open business structures make contributors and non contributors visible such that the business… …   Wikipedia

  • Open peer review — describes a scientific literature concept and process, central to which is the various transparency and disclosure of the identities of those reviewing scientific publications. The concept thus represents a departure from, and an alternative to,… …   Wikipedia

Vulnerabilities - Open Transactions

Since it's important to keep all the potential vulnerabilities in the forefront, this page will help us keep track of those.

Transaction server might inflate the currency

Solution: This is prevented through auditing, which must be utilized, either by the issuer directly, or by the other members of the voting pool.

While the transaction server cannot lie on your receipts, it can potentially inflate the currency itself by using dummy accounts.But the inflated funds cannot be spent without flowing into other accounts, where they will show on an audit.This crime is also permanently detectable until the funds are removed again from circulation.

If the issuer has directly issued the currency onto the transaction server, then he must also conduct the audit.Whereas if the currency is BTC, or if the issuer has used colored coins, then the coins should be uploaded into a voting pool so that the transaction server cannot steal them. In this case, the pool members must audit each other.

Transaction server falsifies an account balance, or a transaction amount

Solution: Falsified balances are prevented by the use of triple-signed receipts. (The OT server cannot do this sort of falsification.)

Every receipt is first signed by the client side, and then counter-signed by the server. Since the server cannot forge your signature, it cannot forge any receipt. Moreover, since your account balance itself appears on every receipt, the server cannot change your account balance. And since the receipt also contains a list of all valid transaction numbers for your Nym, neither can previously valid (and validly signed) instruments be used twice.

Transaction server refuses to process your transactions

Solution: Use a different transaction server. If necessary, have your funds re-issued onto a different transaction server, by going through the issuer or the voting pool (whichever is appropriate in your case.)

Vulnerabilities in web browser

An attacker could inject code into a web page and take control of your wallet, or trick you into signing a malicious transaction.


  • The OT API runs on the client side, outside of the browser. For web apps, a Chrome/Firefox plugin can be used to send transaction requests to a local systray application, where the wallet is actually controlled. From here, the systray wallet can pop up a confirmation and a passphrase dialog.
  • A hardware wallet can additionally be used to prevent any attacks from gaining access to your private keys.

Vulnerabilities in C++ code

An attacker could potentially buffer-overflow the C++ code and gain access to execute their own code.


  • Static and dynamic analysis. Some of this has already been done -- more must be done.
  • Security audit of C++ code.
  • Data validation in C++ code.
  • Test scripts for data validation.
  • Penetration testing.

Phishing attacks

An attacker who gains access to your machine might pop up a fake passphrase dialog and trick you into entering your passphrase.


  • On setup, ask the user to select a passphrase image for his passphrase dialog. This way, his password dialog will look different than every other user's passphrase dialog, and an attacker will not be able to impersonate it.
  • A hardware wallet can serve as a 'brick wall' in defense of these attacks.

Attacker might intercept a message and send it twice (Re-play attacks)

Solution: Each message contains a "request number" which must increment with each message. This prevents re-play attacks.

Issuer holding gold might lie about the physical gold

An issuer might create digital units when he doesn't actually have the physical gold to back them up.


  • Users must be picky about issuers.
  • A physical audit of the issuer's physical gold is the only way to make sure he actually has the gold.
  • A basket currency on OT allows each Nym to distribute the risk of a currency across multiple issuers.

Issuer holding Bitcoins might lie about the actual Bitcoins


  • Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)
  • Store the BTC in a voting pool, so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)

Re-using previously valid instruments

If Alice signs a cheque and gives it to Bob, and he deposits it, what's to stop Bob from depositing the same cheque twice? (The signature is still valid...)

Solution: Each cheque must have a transaction number on it, which was previously signed-out by the cheque signer. Once the cheque is deposited, a chequeReceipt is placed in the cheque signer's inbox. The same cheque cannot be deposited twice at this point, because there would then be two chequeReceipts in the same inbox, each carrying the same transaction number. And once the cheque signer accepts the chequeReceipt from his inbox, a new balance agreement is signed, which includes the new balance as well as the new list of "valid transaction numbers" for that Nym. Since this new balance agreement removes the cheque's transaction number from the list of valid numbers for that Nym, any further deposits of the same cheque would be invalid, since it now carries an invalid transaction number (one that is no longer signed-out.)

This makes it possible to prove which instruments are valid, without storing any transaction history other than the last signed receipt. That receipt includes a list of the valid transaction numbers for its Nym. (All transactions inside OT use this same mechanism.)

Gold-based issuer lies about the number of units issued


  • Issue the currency as colored coins.
  • Make the issuer's last-signed receipt publicly available.
  • What if transaction server and issuer collude to lie about number of units? Make audit data publicly available.
  • How about users privacy? Use homomorphic amounts so that audits can be performed without revealing any account balances or transaction amounts.

Gold-based issuer is forced through coersion to not use certain transaction servers


  • Issue the currency first as colored coins, and let users decide when/whether to upload those coins to voting pools, which allow transaction processing but prevent transaction servers from stealing the coins. This way the issuer has no control over which transaction servers are used, and may not even be aware of their existence. He can no longer be coerced not to use them.

Opentxs - Open Transactions

Open-Transactions comes with a high-level command-line client, called opentxs

(FYI, You might want to make sure the opentxs-notary is running in another terminal, before playing with the client.)

Here is the output from running "opentxs help" using the high-level CLI:

> opentxs help Welcome to Open Transactions -- version 0.89.c Using as server: tBy5mL14qSQXCJK7Uz3WlTOKRP9M0JZksA3Eg7EnnQ1 Using as mynym: T1Q3wZWgeTUoaUvn9m1lzIK5tn5wITlzxzrGNI8qtaV Using as myacct: eMldMMiKfJRO8B8yJjzcezs9xvSt7dkdlWt50e8CDxn Using as mypurse: CvHGtfOOKzQKL5hFL7J4iF5yAodVKhS1rxPzME5R9XA Commands: Advanced utilities: addsignature add a signature to a contract without releasing others. decode OT-base64-decode out of armor. decrypt decrypt ciphertext using nym's private key. encode OT-base64-encode into armor. encrypt encrypt plaintext to a nym's public key. exchange exchange in/out of a basket currency. getboxreceipt downloads a box receipt based on transaction ID. getcontract download an asset or server contract by its ID. issueasset issue a currency contract onto an OT server. newasset create a new asset contract. newbasket create a new basket currency. newkey create a new symmetric key. newserver create a new server contract. pass_decrypt password-decrypt a ciphertext using a symmetric key. pass_encrypt password-encrypt a plaintext using a symmetric key. register register a nym onto an OT server. showbaskets show basket currencies issued on a particular server. showmint show a mint file for specific asset ID. Download if necessary. sign sign a contract, releasing all other signatures first. verifysig verify a signature on a contract. The user wallet: addasset paste an existing asset contract, import it into your wallet. addserver paste an existing server contract, import it into your wallet. changepw change the master passphrase for the wallet. editacct edit an asset account's label, as it appears in your wallet. editasset edit a currency contract's label, as it appears in your wallet. editnym edit the nym's label, as it appears in your wallet. editserver edit a server contract's label, as it appears in your wallet. exportcert export the OpenSSL cert (only) for a specific Nym. exportnym export an OT Nym as a single importable file. importcert import an OpenSSL cert and create a Nym based on it. importnym import an OT Nym that was previously exported. newnym create a new nym. refresh performs both refreshnym and refreshacct. refreshacct download latest intermediary files for myacct. refreshnym download latest intermediary files for mynym. showaccounts show the asset accounts in the wallet. showassets show the currency contracts in the wallet. showincoming show incoming payments for mynym+server and/or inbox for myacct. shownym show the statistics for a specific nym. shownyms show the nyms in the wallet. showpurse show contents of cash purse. showservers show the server contracts in the wallet. stat display wallet contents. verifyreceipt verify your intermediary files against the last signed receipt. Misc: clearrecords clear all archived records and receipts. records display contents of record box. Markets (bid/ask): canceloffer cancel a still-running, recurring market offer. getmarkets download the list of markets. getmyoffers download mynym's list of market offers. getoffers download the list of market offers. newoffer create a new market offer. paydividend dividend payout, sent to all shareholders (in voucher form.) showmarkets display the list of markets. showmyoffers show mynym's offers on a particular server and market. showoffers show all offers on a particular server and market. Asset accounts: acceptall accept all incoming transfers, receipts, payments, and invoices. acceptinbox accept all incoming transfers and receipts in MyAcct's inbox. acceptinvoices pay all invoices in MyNym's payments inbox. acceptmoney accept all incoming transfers and payments into MyAcct. acceptpayments accept all incoming payments in MyNym's payments inbox. acceptreceipts accept all receipts in MyAcct's inbox. accepttransfers accept all incoming transfers in MyAcct's inbox. balance display balance for a specific account. deposit deposit cash, cheque, voucher, or tokens. inbox display inbox of a particular account. newacct create a new asset account. outbox display outbox of a particular account. showacct show account stats for a single account. transfer send a transfer from myacct to hisacct. Dealing with other users: checknym download a nym's public key based on his ID. delmail delete an in-mail item. deloutmail delete an out-mail item. mail display in-mail for a particular nym. outmail display out-mail for a particular nym. outpayment display contents of outgoing payments box. payinvoice pay an invoice. payments display contents of incoming payments box. sendcash send cash from mypurse to recipient, withdraw if necessary. sendcheque write a cheque and then send it to the recipient. sendinvoice write an invoice and then send it to the recipient. sendmsg send a message to another nym's in-mail. sendvoucher withdraw a voucher and then send it to the recipient. showpayment show the details of an incoming payment in the payments inbox. Financial instruments: buyvoucher withdraw from myacct as a voucher (cashier's cheque.) cancelplan cancel a still-running, recurring payment plan. confirm confirm your agreement to a smart contract or payment plan. discard discard/cancel a not-yet-cashed, outgoing instrument. exportcash export a cash purse. importcash import a cash purse. propose as merchant, propose a payment plan to a customer. trigger trigger a clause on a running smart contract. withdraw withdraw cash. (From acct on server into local purse.) writecheque write a cheque and print it out to the screen. writeinvoice write an invoice and print it out to the screen.

Messaging - Open Transactions

Open Transactions is agnostic to transport. Meaning that libOTLib.a, the actual library (containing the bulk of the code), includes no transport code at all.

The OTMessage class, which OT uses for all of its messaging, simply serializes itself into string form, and then you can transport that string using whatever form of transport you wish. (OT operates on Request / Response model.) See this article on the OTX protocol.

The OT Server, Test Client, and API were written using the OT Library. These pieces do implement transport, via a callback function. The current callback is implemented using the ZeroMQ Library

Each OTMessage is encrypted in an OTEnvelope, to the public key located in the server contract, after which only the server can open it.

When messaging the transaction server, a new user includes his public key in the message so that the server can verify his signature and also so it can encrypt its response to him.

If you look at the below “Check Server ID” message, you can see that the user has included his public key:

-----BEGIN SIGNED MESSAGE----- Hash: SAMY <?xml version="1.0"?> <OTmessage version="1.0"> <checkServerID nymID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz" serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"> <nymPublicKey> - -----BEGIN PUBLIC KEY----- LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlHZk1BMEdDU3FHU0liM0RRRUJB UVVBQTRHTkFEQ0JpUUtCZ1FEZThQMTg3aWkvanpuZ3Z6QmV1QisvYTJXMApQUFNK NVd0TTFJdTdMWEc1REp2Ly80ekJuUVJqQzd5TXd4Q3VwdFJwZ2JyTHpNbTdmYklF cXNFMDgvQW41OGtUCjYxK0JXRHpyUjBaVnZBeDNncUdtUXEybWtsZVpsb2FvdXE4 UXRwZHJoVEQwM2VxRDk5cVBRMHdRTWdHRy8rMFAKOEhsVHJtOGY1VFFtVkVuVHVR SURBUUFCCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo= - -----END PUBLIC KEY----- </nymPublicKey> </checkServerID> </OTmessage> -----BEGIN MESSAGE SIGNATURE----- Version: Open Transactions 0.40 Comment: y0c9qAp9xS7f9/r9HokY70ajoAO92/LhNXvDOqg1Td0TtsvndNX4+rfahat+w2Y5 fbFn9ZAZkFUOqjNE4zPwazRSm93W0SIj1rCyOjWkCYfSFLsGm+YS5oMwRColAqu1 FmdO3SSTMVzLnUGpt4BKGPSct0xr48Rh0l5o6Za0XDI= -----END MESSAGE SIGNATURE-----

The user registers his public key so that it can be stored on the server side. He might register with many different keys, depending on his level of paranoia. He might also go “cash only” and therefore not register at all, but this isn’t necessary for untraceability (only for anonymity), since even the pseudonymous accounts are unlinkable when you use cash.

Your public key is a pseudonym. You will see the words “User ID” and “Nym ID” and “Nym” and “pseudonym” used interchangeably in OT. They all mean the same thing: a public key, or an ID used to look it up.

Below is an example of an OTMessage where the user is requesting a copy of his inbox. Notice this message does not include a public key; once you have registered a public key with the server, it does not have to be passed back and forth anymore. Below, the message only includes the Nym ID this time, instead of the entire public key. The server will use the ID to look up the key, and then verify the signature on the message. Only messages signed by the appropriate key will be processed.

-----BEGIN SIGNED MESSAGE----- Hash: SAMY <?xml version="1.0"?> <OTmessage version="1.0"> <getInbox nymID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz" serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn" accountID="PhmhKernutijMa2XXxh2dZnTluIDQUVn1tifSOq9h5x" requestNum="269" > </getInbox> </OTmessage> -----BEGIN MESSAGE SIGNATURE----- Version: Open Transactions 0.40 Comment: mu6uLNV/OVL42bZbuD5lfUQLKfUcsLqyfy5dGfjPiQ3hzuhge4RXqzs1t0wnuS2F AarWXdxO5+wlu5ZUW/7uJj0IP5dMJcxjWYh/ZBRDInBTH8zXbg6ZvPp+0Ia4nJOx dsvwNyizqbSnidI5knjaJmusknFWA4r3Cp00fvZQWHg= -----END MESSAGE SIGNATURE-----

Notice a few things:

  1. The above message includes the ServerID. Why? To prevent the message being intercepted and sent to a different server, since the signature itself will verify.
  2. Notice also that the message above includes a “Request Number”. This number must increment with each message. Why? To prevent the message being intercepted and sent multiple times. Once a message has been used once, it can never work again, since the request number is now invalid.

If you send a "getInbox" request, the server replies with "@getInbox". Here is that reply:

-----BEGIN SIGNED MESSAGE----- Hash: SAMY <?xml version="1.0"?> <OTmessage version="1.0"> <@getInbox success="true" nymID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz" serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn" accountID="PhmhKernutijMa2XXxh2dZnTluIDQUVn1tifSOq9h5x" > <inboxLedger> eJx1UslyGjEQzXm+YoorhUf7QsWuAoMJXnDYTOAmqSUYswyBAUy+PiKkKskhukjd 6uW97lerxdNsd7q9dNjt9Nqt9Lnd6rQHF3ct+WL2i3o6bLxMk+Szca44bMpnD3O/ S49+t8+LzW0F36BKkpbnrb+t5BtbfETrd2i3Fb8lM8Ig67k0ygRnVbyo9cggcIpj hR0OgghhGShMERc+cMuDVoRbAdpTTj3CjHkHilrDNHUekWAlaMcw4cZZ4M54J50N QhuGnQSwkgaprQ0RzWHvdxcoErALQXAjg7fGmYjKmksgCI4o8UIQ5OMTB4a1wJZY Tw1wLkBpDCzELpaTyE1JhyQYjYMFpxkCowQnTDsrPLLUiOAlCBGEpUF5qxnX2HKo JBHI8YqFOccAOIop5sJEAooVkEcaTIiNgwOsNKUYIiUkQ6SEsQcltJDgMXE6BGCe OgISAQJpEIkoPVEoEAg4QECcM8qVUCy6bJCWSmBEawMCfCW9iyvN/tnpXVL7o4ar DH6JojEaD9pXQbxdt15PX7d+k452ZrM3royefYpuGErui/Xab8p6uijLbT3L5nm5 ONgbV6yzB79aFaeYcvQrv8suBWp/F8hO+TJPEvSl2s37s/OoaBSzZqe7P+Xs+zZn s37HnXqPclGEsDyf9dtq3pnMqos+bayXIrQWM9IcHc7LZMwnjU6+YtkLmQn5bT2Y PVQnyxV1Wf+o1U4Mz0/3LcdaTdT+Kp+Mqr7mfvremzbmp+Fb88d9QnjT4edpedjY 5UbNRsV8MP7QzU6m9h9sPXl/OBzL7PHVynx8e51Yu9f6z7ySTz8BFP0Cpw== </inboxLedger> </@getInbox> </OTmessage> -----BEGIN MESSAGE SIGNATURE----- Version: Open Transactions 0.40 Comment: 3Ly510ofsMjiaWZiid/5ekmfVHWbWmHZpY9u4T5QVViqCusw8NhGAZFDshrWtUWc CFJ+h2uFiS91kreHeqb9Qp7difWL4lBgxNn4I8pP0dKJmkUiS5R9dLAFonJMBZfg ybwAEUX6WxVYLEZpDxLFqojXgVP+nPrUcf9LVu89rHg= -----END MESSAGE SIGNATURE-----

As you can see, my inbox is attached to the above server reply. (In base64-encoded form.) Decoding it reveals it to be empty:

-----BEGIN SIGNED LEDGER----- Hash: SAMY <accountLedger version="1.0" type="inbox" accountID="PhmhKernutijMa2XXxh2dZnTluIDQUVn1tifSOq9h5x" userID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz" serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn" > </accountLedger> -----BEGIN LEDGER SIGNATURE----- Version: Open Transactions 0.40 Comment: 0H+IiQZyToAoZBGIswi4qpi4ZQGcwNJ7hoffkyy9VlgGWZ+hQ3Amk6fDhZ2BTuyk U5WAGil4/M2Z67XmRZF+Wkl3c/Qv98r6SyKCDc4DB0EP7Ka8+OieYjNYAgwSVBzC 25Bc1LYtunbkn8ZTogRUx9BG/8sx4mWjFuvt/JOb7iU= -----END LEDGER SIGNATURE-----

What about messages that involve transactions? Click here to read about transaction-specific messages on OT.

Open transactions report (CustTransOpenPerDate) [AX 2012]

Эта документация перемещена в архив и не поддерживается.

Updated: August 23, 2011

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Use this report to provide detailed information about the open transactions for each customer as of the date entered in the Open transactions per field. For each transaction, the report includes the date of the transaction, voucher number, amount in the transaction currency, balance in the transaction currency, subtotal amount in the accounting currency, due date, and collection letter code.

If no date is entered, the date is set to the maximum date, which is December 31, 2154.

When you generate this report, the following default parameters are displayed. You can use these parameters to filter the data that will be displayed on the report. For more information, see Фильтрация данных в отчете.



Open transactions per

Enter a date as of which transactions that are open will be included on the report.

If no date is entered, the date is set to the maximum date, but the date that was last used is proposed the next time that you access the report.

Billing classification

Select one or more billing classifications to include on the report.


This control is available only if the Public Sector configuration key is selected.

The following topics explain how to print a report and how to filter and sort the data on a report.

The following table explains where to find the report in the Application Object Tree (AOT) and how to navigate to the report in the Microsoft Dynamics AX client.



Name of report in the AOT


Location of report in the AOT

SSRS Reports\Reports\CustTransOpenPerDate

Menu item of the report


Navigation to the report

Click Accounts receivable > Reports > Transactions > Customer > Open transactions.

The data on this report comes from the following sources:


To determine where the data in the temp tables comes from, view the cross-references for the CustTransOpenPerDateDP.processReport class.

If you are a developer, you can learn more about where the data on a report comes from by using the following procedure.

  1. Open the AOT.

  2. Locate the report in the SSRS Reports\Reports node.

  3. Right-click the report and click Add-Ins > Cross-reference > Using (instant view).


To see known issues and recent fixes, use

Issue search


Microsoft Dynamics Lifecycle Services


Page not found · GitHub Pages

Page not found · GitHub Pages

File not found

The site configured at this address does not contain the requested file.

If this is your site, make sure that the filename case matches the URL.For root URLs (like you must provide an index.html file.

Read the full documentation for more information about using GitHub Pages.

Instruments - Open Transactions

Open Transactions supports different types of financial instruments...

  • account transfer (a signed message, given to the bank, asking to transfer funds to another account),
  • digital cheque (a signed message, given to the recipient, authorizing bank to transfer funds when presented),
  • digital vouchers (like a cashier's cheque. Funds are transferred to bank, who then issues a cheque. Bank becomes payer),
  • digital cash (Like a real cash withdrawal. Funds are transferred to bank, who then issues chaumian bearer certificates),
  • NEW: Now supporting markets (with trades) and payment plans.

Here's a little chart to show some of the differences between these instruments:

Can have a specific recipient: NO YES YES YES
Must have a specific recipient: NO YES NO NO
Can have a blank recipient: YES NO YES YES
Must have a blank recipient: YES NO NO NO
Can be cancelled by sender: NO YES^ YES^ YES^
Creating instrument removes funds: YES YES NO YES
Payer has "benefit of float": NO NO YES NO
Instrument might bounce: NO NO YES NO
Instrument might be already spent: YES NO YES YES
Guarantee of receipt: NO YES YES YES
Guarantee of funds (when good): YES YES NO YES
Instrument created online: YES YES NO YES
Payment must be online: NO YES NO NO
Instrument verified online: YES YES YES YES
Has an expiration date: YES NO YES YES
Money kept by bank upon expire: YES NO EXPIRY NO YES
Money kept by user upon expire: NO NO EXPIRY YES NO
Record created when instrument is: NO YES NO YES
Sending a payment creates a record: NO YES NO NO
Accepting a payment creates a record: YES^^^ YES YES YES
Unlinkable to recipient: YES NO NO YES^^
Unlinkable to ANYONE: YES NO NO NO

^ Assuming it is canceled before it’s accepted by the recipient. (Once a transfer is accepted, or a cheque is cashed, it cannot be canceled anymore.)

^^ Unlike digital cash, (which is unlinkable by anyone), digital vouchers are traceable by the bank, but the information is hidden from the recipient, who instead sees the bank as the sender, just like a cashier’s check. (In the case of a voucher, the recipient could serve the bank with a subpoena to find out the sender’s identity. But with cash, he could not—that becomes impossible.)

^ ^ ^ When you receive a digital cash payment, you will most likely want to deposit it immediately, or exchange it for a new token, just to make sure your money is safe. When you do this, the bank doesn't know where the token came from, and it has no way of knowing who you will eventually spend it to. It also has no way of knowing whether you just received this token, or whether you are just exchanging the same one over and over again (or whether you are exchanging a pre-existing token from your wallet that was about to expire.)

BUT the bank can still make a record that you exchanged a token, which is why I say here that a record could be created with cash, even though I also say that it is unlinkable. Remember, the tokens all have the same expiration dates, they all have the same denominations, and the bank cannot see where they came from, and the bank cannot see where they are going, and the bank cannot prove how much of them you actually have.

UPDATE But!!! the bank can provide a web interface over HTTPS for exchanging tokens, so that even people who are so paranoid they don't even want to even OPEN an account at all can STILL receive tokens, exchange them, and use them for payments. This easily satisfies the "bearer-only" crowd: as long as the https interface is operated by the same entity as the transaction processor, you don't have to open an account at all. (See main wiki page for a link to a diagram showing this "full-anonymous" mode.)

Here are some nice, graphical diagrams of some of the instruments (these diagrams are for the Ricardo transaction server).

Смотрите также