Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
> Date: Thu, 20 Oct 2005 11:31:39 -0700 > From: cyphrpunk <[EMAIL PROTECTED]> > > 2. Cash payments are final. After the fact, the paying party has no > > means to reverse the payment. We call this property of cash > > transactions _irreversibility_. > > Certainly Chaum ecash has this property. Because deposits are > unlinkable to withdrawals, there is no way even in principle to > reverse a transaction. This is not strictly correct. The payer can reveal the blinding factor, making the payment traceable. I believe Chaum deliberately chose for one-way untraceability (untraceable by the payee but not by the payer) in order to address concerns such as blackmailing, extortion, etc. The protocol can be modified to make it fully untraceable, but that's not how it is designed. > > 3. Cash payments are _peer-to-peer_. There is no distinction between > > merchants and customers; anyone can pay anyone. In particular, anybody > > can receive cash payments without contracts with third parties. > > Again this is precisely how Chaum ecash works. Everyone can receive > ecash and everyone can spend it. There is no distinction between > buyers and vendors. Of course, transactions do need the aid of the > issuer, but that is true of all online payment systems including > Daniel's. Apart from the transferability issue, I think there are some systems that do not rely on an issuer at all (in effect any payee is an issuer). Manasse's Millicent comes to mind, but I confess that I don't fully remember the details. Ray
Re: Firm invites experts to punch holes in ballot software
> Date: Wed, 07 Apr 2004 15:42:47 -0400
> From: Ian Grigg <[EMAIL PROTECTED]>
>
> It seems to me that the requirement for after-the-vote
> verification ("to prove your vote was counted") clashes
> rather directly with the requirement to protect voters
> from coercion ("I can't prove I voted in a particular
> way.") or other incentives-based attacks.
>
> You can have one, or the other, but not both, right?
What you can have is for the voter to be able to verify that his/her
vote was properly counted without being able to prove it to anybody
else.
In that case, an individual claim that a vote was improperly counted
wouldn't be convincing, but a wide enough outcry might trigger a
recount.
I think this would add unnecessary and undesired complexity to a
political election voting system, though.
Ray
Re: Challenge to TCPA/Palladium detractors
> Date: Fri, 9 Aug 2002 19:30:09 -0700 > From: AARG!Anonymous <[EMAIL PROTECTED]> > Re the debate over whether compilers reliably produce identical object > (executable) files: > > The measurement and hashing in TCPA/Palladium will probably not be done > on the file itself, but on the executable content that is loaded into > memory. For Palladium it is just the part of the program called the > "trusted agent". So file headers with dates, compiler version numbers, > etc., will not be part of the data which is hashed. > > The only thing that would really break the hash would be changes to the > compiler code generator that cause it to create different executable > output for the same input. This might happen between versions, but > probably most widely used compilers are relatively stable in that > respect these days. Specifying the compiler version and build flags > should provide good reliability for having the executable content hash > the same way for everyone. A trivial observation: this cannot be true across hardware platforms. TCPA claims to be "platform and OS agnostic", but Palladium does not.
Re: Thanks, Lucky, for helping to kill gnutella
> Date: Fri, 9 Aug 2002 20:25:40 -0700 > From: AARG!Anonymous <[EMAIL PROTECTED]> > Right, as if my normal style has been so effective. Not one person has > given me the least support in my efforts to explain the truth about TCPA > and Palladium. Hal, I think you were right on when you wrote: But feel free to make whatever assumptions you like about my motives. All I ask is that you respond to my facts. I, for one, support your efforts, even though I don't agree with some of your conclusions. It is clear that you hold a firm opinion that differs from what many others here believe, so in making your points you can expect objections to be raised. You will be more convincing (at least to me) if you continue to respond to these dispassionately on the basis of facts and reasoned opinions (your "normal style"?). Calling Lucky a liar is no more illuminating than others calling you an idiot.
Re: Challenge to TCPA/Palladium detractors
> Date: Thu, 8 Aug 2002 21:55:40 +0200 > From: "R. Hirschfeld" <[EMAIL PROTECTED]> > > > Date: Wed, 7 Aug 2002 12:50:29 -0700 > > From: AARG!Anonymous <[EMAIL PROTECTED]> > > > I'd like the Palladium/TCPA critics to offer an alternative proposal > > for achieving the following technical goal: > > > > Allow computers separated on the internet to cooperate and share data > > and computations such that no one can get access to the data outside > > the limitations and rules imposed by the applications. > > The model and the goal are a bit different, but how about secure > multi-party computation, as introduced by Chaum, Crepeau, and Damgard > in 1988 and subsequently refined by others? Sorry, I see from an earlier message of yours that you are looking for a simple non-crypto solution, so I guess this doesn't fit the bill. The examples you gave in your earlier message all seem to be equivalent to having the participants send the data to a trusted third party who performs the computation, except that the trusted third party is transplanted to one or more of the participants computers, which are protected against their owners. I guess it boils down to whether or not the level of trust is sufficient. This seems iffy when one of the participants is also the trust provider.
Re: Challenge to TCPA/Palladium detractors
> Date: Wed, 7 Aug 2002 12:50:29 -0700 > From: AARG!Anonymous <[EMAIL PROTECTED]> > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others?
