Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
One other point with regard to Daniel Nagy's paper at http://www.epointsystem.org/~nagydani/ICETE2005.pdf A good way to organize papers like this is to first present the desired properties of systems like yours (and optionally show that other systems fail to meet one or more of these properties); then to present your system; and finally to go back through and show how your system meets each of the properties, perhaps better than any others. This paper is lacking that last step. It would be helpful to see the epoint system evaluated with regard to each of the listed properties. In particular I have concerns about the finality and irreversibility of payments, given that the issuer keeps track of each token as it progresses through the system. Whenever one token is exchanged for a new one, the issuer records and publishes the linkage between the new token and the old one. This public record is what lets people know that the issuer is not forging tokens at will, but it does let the issuer, and possibly others, track payments as they flow through the system. This could be grounds for reversibility in some cases, although the details depend on how the system is implemented. It would be good to see a critical analysis of how epoints would maintain irreversibility, as part of the paper. CP
On Fri, Oct 28, 2005 at 02:18:43PM -0700, cyphrpunk wrote:
In particular I have concerns about the finality and irreversibility of payments, given that the issuer keeps track of each token as it progresses through the system. Whenever one token is exchanged for a new one, the issuer records and publishes the linkage between the new token and the old one. This public record is what lets people know that the issuer is not forging tokens at will, but it does let the issuer, and possibly others, track payments as they flow through the system. This could be grounds for reversibility in some cases, although the details depend on how the system is implemented. It would be good to see a critical analysis of how epoints would maintain irreversibility, as part of the paper.
I agree, this discussion is missing, indeed. I will definitely include it, should I write another paper on the subject. Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others. In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da->Cb has already been published. In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it. In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information. Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services. -- Daniel
On 10/28/05, Daniel A. Nagy
Irreversibility of transactions hinges on two features of the proposed systetm: the fundamentally irreversible nature of publishing information in the public records and the fact that in order to invalidate a secret, one needs to know it; the issuer does not learn the secret at all in some implementnations and only learns it when it is spent in others.
In both cases, reversal is impossible, albeit for different reasons. Let's say, Alice made a payment to Bob, and Ivan wishes to reverse it with the possible cooperation of Alice, but definitely without Bob's help. Alice's secret is Da, Bob's secret is Db, the corresponding challenges are, respectively, Ca and Cb, and the S message containing the exchange request Da->Cb has already been published.
In the first case, when the secret is not revealed, there is simply no way to express reverslas. There is no S message with suitable semantics semantics, making it impossible to invalidate Db if Bob refuses to reveal it.
The issuer can still invalidate it even though you have not explicitly defined such an operation. If Alice paid Bob and then convinces the issuer that Bob cheated her, the issuer could refuse to honor the Db deposit or exchange operation. From the recipient's perspective, his cash is at risk at least until he has spent it or exchanged it out of the system. The fact that you don't have an "issuer invalidates cash" operation in your system doesn't mean it couldn't happen. Alice could get a court order forcing the issuer to do this. The point is that reversal is technically possible, and you can't define it away just by saying that the issuer won't do that. If the issuer has the power to reverse transactions, the system does not have full ireversibility, even though the issuer hopes never to exercise his power.
In the second case, Db is revealed when Bob tries to spend it, so Ivan can, in principle, steal (confiscate) it, instead of processing, but at that point Da has already been revealed to the public and Alice has no means to prove that she was in excusive possession of Da before it became public information.
That is an interesting possibility, but I can think of a way around it. Alice could embed a secret within her secret. She could base part of her secret on a hash of an even-more-secret value which she would not reveal when spending/exchanging. Then if it came to where she had to prove that she was the proper beneficiary of a reversed transaction, she could reveal the inner secret to justify her claim.
Now, one can extend the list of possible S messages to allow for reversals in the first scenario, but even in that case Ivan cannot hide the fact of reversal from the public after it happened and the fact that he is prepared to reverse payments even before he actually does so, because the users and auditors need to know the syntax and the semantics of the additional S messages in order to be able to use Ivan's services.
That's true, the public visibility of the system makes secret reversals impossible. That's very good - one of the problems with e-gold was that it was never clear when they were reversing and freezing accounts. Visibility is a great feature. But it doesn't keep reversals from happening, and it still leaves doubt about how final transactions will be in this system. CP
Hi, I'm sorry for not answering to the last message in this thread for almost a month. After systematically reviewing some of the issues that came up in this discussion and talking to a friend of mine, it seems that it is possible to make governable blinded cash, using some of the ideas from the paper in question. In fact, blinded and non-blinded tokens (i.e. digital "coins" and "notes") can be successfully and conveniently used together, as they offer different advantages and different tradeoffs. A new paper, tentatively titled "Digital Cash: Notes and Coins" is being written. If there's going to be an FC++ issue in December or January, we might have a go at it before publishing the paper using a more traditional channel. The basic idea with coins (which are less traceable than notes, but are less flexible, too, and may weigh your pocket down, if you keep large sums in coins) is that the blind signature key is regularly changed (e.g. annually, so it is possible to tell a 2005 ePoint coin from a 2006 ePoint coin, just like in the "real world"), and while coins are accepted indefinitely, they are only issued during the validity period of the key. This means that one can limit the damage caused by a leaked secret key or a malicious issuer. After the validity period of the key, it is possible to keep count of the coins in circulation and accept only that limited amount (and sound alarms, if unaccounted-for coins emerge). Another important idea is that of spot-checks: from time to time (determined partly by the users, partly by the issuer in such a way that the issuer cannot control and the users cannot predict it) coins are accepted only with the user identifiing the coin's (published) proto-coin and reveal the corresponding blinding factor. If it happens rarely enough, it won't compromise the general untraceability of coins, but it may catch a counterfeit coin and thus reveal the compromise of the secret key. At ePointSystem, may very well implement this kind of coins, which can be used in conjunction with notes. I'd like to thank you for the thoughtful discussion and the valuable ideas. -- Daniel
At 1:54 AM +0100 11/24/05, Daniel A. Nagy wrote:
blind signature key is regularly changed
This is an old idea. It is not novel.
As far as I can remember, it was discussed on cypherpunks by myself and Ian
Goldberg at least 10 years ago.
Cheers,
RAH
--
-----------------
R. A. Hettinga
At 1:54 AM +0100 11/24/05, Daniel A. Nagy wrote:
spot-checks
This also is not new.
We were discussing this in relation to millidollar streaming cash at least
5 years ago. We've discussed this privately, and on public mail lists, with
the likes of Nicko van Someren, Ron Rivest, Adi Shamir, and Mark Manasse.
Even the delineation between universally-checked blind-signature "notes",
and stochastically tested "coins" is at least five years old and has been
discussed on most of the usual email lists.
Cheers,
RAH
--
-----------------
R. A. Hettinga
On Wed, Nov 23, 2005 at 08:31:46PM -0500, R. A. Hettinga wrote:
At 1:54 AM +0100 11/24/05, Daniel A. Nagy wrote:
spot-checks
This also is not new.
We were discussing this in relation to millidollar streaming cash at least 5 years ago. We've discussed this privately, and on public mail lists, with the likes of Nicko van Someren, Ron Rivest, Adi Shamir, and Mark Manasse.
Those two ideas are not new, and I know that. What is new is the publication of a signed transaction log by the issuer; the splitting of public and private information in such a way that allows for transparent issuer governance without invading privacy. In the electronic cash literature, governance issues have rarely been raised, let alone properly addressed. Systematic treatment of transparent governance in digital payments begun, AFAIK, with the research of Ian Grigg. For a (long) while, both Ian and I were convinced that transparent governance and blind signatures don't mix well. It was cyphrpunk in this discussion, who pointed out the essential similarity between the proto-coin in chaumian schemes and the cryptographic challenge in my paper. It came up in the context of invoicing, but -- as we recently realized -- it can also be used for governance, when coupled with these two old ideas. In short, the basic idea is for the issuer to _publish_ in an undeniable manner the responses (with some additional info) to exchange requests instead of sending the information back to the requesting party using a private channel. I do think (in agreement with several reviewers of my work) that the setup proposed in the discussed paper, where the communication between the users and the issuer is such that the issuer's responses to users' requests are broadcast and archived in public records is novel.
Even the delineation between universally-checked blind-signature "notes", and stochastically tested "coins" is at least five years old and has been discussed on most of the usual email lists.
We use "notes" and "coins" in a completely different sense. There are no blind signatures in notes; notes are traceable to some extent, just like IRL. Cheers, -- Daniel
Daniel A. Nagy wrote:
Those two ideas are not new, and I know that. What is new is the publication of a signed transaction log by the issuer; the splitting of public and private information in such a way that allows for transparent issuer governance without invading privacy.
In the electronic cash literature, governance issues have rarely been raised, let alone properly addressed. Systematic treatment of transparent governance in digital payments begun, AFAIK, with the research of Ian Grigg.
Hey, thanks for the credit! You raise an interesting claim. I think it is fair to say that a lot of people have looked at governance of digital cash but almost all of their efforts have proceeded from a technical crypto pov, and have thus not got very far. If you wade thru the early FC proceedings you'll see a steady stream of papers trying to make blinded tokens slightly less blind with various mixed objectives that could be interpreted as governance (often presented as control for various other purposes). My approach has not been technical but has been what we could call 'institutional' - looking at how the people and organisations could protect it, which has the advantage of being familiar to those who would be charged with the job anyway. From memory the others who've looked at the subject from an institutional perspective would be people like Mark Miller, Nick Szabo and the late Gary Howland, but they were more focused on overall ramifications than specific governance issues.
For a (long) while, both Ian and I were convinced that transparent governance and blind signatures don't mix well. It was cyphrpunk in this discussion, who pointed out the essential similarity between the proto-coin in chaumian schemes and the cryptographic challenge in my paper. It came up in the context of invoicing, but -- as we recently realized -- it can also be used for governance, when coupled with these two old ideas.
In short, the basic idea is for the issuer to _publish_ in an undeniable manner the responses (with some additional info) to exchange requests instead of sending the information back to the requesting party using a private channel. I do think (in agreement with several reviewers of my work) that the setup proposed in the discussed paper, where the communication between the users and the issuer is such that the issuer's responses to users' requests are broadcast and archived in public records is novel.
If this is the case, it would be an exciting development! I guess we have to wait for the paper to see ... it isn't obvious to me how the above would work. iang PS: In your other email:
A new paper, tentatively titled "Digital Cash: Notes and Coins" is being written. If there's going to be an FC++ issue in December or January, we might have a go at it before publishing the paper using a more traditional channel.
I have 1.5 papers for an FC++ issue, this would probably tip the balance.
On 11/23/05, Daniel A. Nagy
The basic idea with coins (which are less traceable than notes, but are less flexible, too, and may weigh your pocket down, if you keep large sums in coins) is that the blind signature key is regularly changed (e.g. annually, so it is possible to tell a 2005 ePoint coin from a 2006 ePoint coin, just like in the "real world"), and while coins are accepted indefinitely, they are only issued during the validity period of the key. This means that one can limit the damage caused by a leaked secret key or a malicious issuer. After the validity period of the key, it is possible to keep count of the coins in circulation and accept only that limited amount (and sound alarms, if unaccounted-for coins emerge).
These are good ideas to reduce the impact of a stolen key, and possibly to detect if one has been stolen.
Another important idea is that of spot-checks: from time to time (determined partly by the users, partly by the issuer in such a way that the issuer cannot control and the users cannot predict it) coins are accepted only with the user identifiing the coin's (published) proto-coin and reveal the corresponding blinding factor. If it happens rarely enough, it won't compromise the general untraceability of coins, but it may catch a counterfeit coin and thus reveal the compromise of the secret key.
As a potential user of such a system, if anonymity were important to me I would refuse to honor a request to reveal this linkage information. I would accept that the coin was lost and pay with a different one. Depending on the frequency of such spot checks, this would constitute an effective transaction cost for the use of the system.
In the electronic cash literature, governance issues have rarely been raised, let alone properly addressed. Systematic treatment of transparent governance in digital payments begun, AFAIK, with the research of Ian Grigg.
One example is the Sander and Ta-Shma paper I mentioned earlier: http://citeseer.ist.psu.edu/sander98auditable.html
In short, the basic idea is for the issuer to _publish_ in an undeniable manner the responses (with some additional info) to exchange requests instead of sending the information back to the requesting party using a private channel. I do think (in agreement with several reviewers of my work) that the setup proposed in the discussed paper, where the communication between the users and the issuer is such that the issuer's responses to users' requests are broadcast and archived in public records is novel.
It will be interesting to see more details of how this works. Sander and Ta-Shma also had the server publish information for every issued coin, and then used zero knowledge techniques for the depositor to show that the coin was on the list. This added great complexity to the system. CP
cyphrpunk wrote:
In the electronic cash literature, governance issues have rarely been raised, let alone properly addressed. Systematic treatment of transparent governance in digital payments begun, AFAIK, with the research of Ian Grigg.
One example is the Sander and Ta-Shma paper I mentioned earlier: http://citeseer.ist.psu.edu/sander98auditable.html
I wasn't aware of this paper, probably because it was published in Crypto rather than FC. Quickly flicking through it, I stopped at the end of section 3.2 which raises some interesting claims. On the face of it, it would seem that in order to operate the system, * merchants have to update frequently * merchants cannot accept real-time generated Tx, where "real-time" is inversely related to "frequently" in the first point * users have to likewise update many times per coin While the solution may be elegant, I can't see how that would work in real life. The goal for a transaction is quite simple: send one message, get one message back. (In practical engineering terms you can't get much more efficient than that.) But, the real point here is that users will use the cheapest system in preference to anything else, so a more efficient system will dominate a less-efficient system, in the long run. Sander and Ta-Shma's solution seems to propose something remarkably expensive in message terms. (Mind you, if he has done what he has claimed, that is a remarkable result!)
In short, the basic idea is for the issuer to _publish_ in an undeniable manner the responses (with some additional info) to exchange requests instead of sending the information back to the requesting party using a private channel. I do think (in agreement with several reviewers of my work) that the setup proposed in the discussed paper, where the communication between the users and the issuer is such that the issuer's responses to users' requests are broadcast and archived in public records is novel.
It will be interesting to see more details of how this works. Sander and Ta-Shma also had the server publish information for every issued coin, and then used zero knowledge techniques for the depositor to show that the coin was on the list. This added great complexity to the system.
Ah ok. So we concur on the cost aspects. As an aside, Sanders did pay a lot of attention to these areas. However, what he was focused on was "regulatory" issues, as distinct from "governance" issues. Now, some would call them the same, but I would not. Governance is about the system looking after itself and its users, where as "regulatory" issues bring in a grab bag of wider issues which have little to do with the system, other than their presence having threat effects. Hence for example, the bank robbery problem is included in governance because it steals money from in the system and threatens system collapse, whereas money laundering is an exogenous threat that only effects the system via regulation and can never damage the system or users endogenously. iang PS: it was never necessary to pay attention to ML issues any more closely, because all digital cash (including anonymous ones) systems generally had much stronger AML capabilities in comparison with classical banking systems, so it wasn't as if there was much point in improving them.
participants (4)
-
cyphrpunk -
Ian G -
nagydani＠epointsystem.org -
R. A. Hettinga