<br><br>
<div class="gmail_quote">On Wed, Dec 3, 2008 at 5:06 PM, John Levine <span dir="ltr"><<a href="mailto:johnl@taugh.com">johnl@taugh.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">>the 1000 recipient stamps. Each of the 1000 recipients recognize<br>>a coin wrapped in their own stamp and opens the coin and attempts<br>
>to redeem it with the bank, which only redeems the first such coin,<br>>but is alerted to attempted fraud and revokes the sender's account.<br><br>OK, that sounds like the usual micropayment token cancelling<br>
bottleneck that nobody knows how to scale.<br></blockquote>
<div>Actually, micropayment cancelling isn't the part of the story I'm </div>
<div>advocating, I'm advocating for a standard for transmission of coins. </div>
<div> </div>
<div>I really don't care how they're franked, what their value is, or how</div>
<div>they are verified. What I provided above is only a single "bank" </div>
<div>example as an extension to your question, please don't </div>
<div>forget there is the trivial example where the coin is NULL, i.e.,</div>
<div>the recipient chooses to accept stamped mail without coins.</div>
<div>Thus there is only the initial sender presentation of identity and </div>
<div>the recipient "stamp-generator" issues a stamp (or not) based</div>
<div>solely on the identity and properties of the TCP session. </div>
<div>The NULL coin example may not be very interesting, but it's</div>
<div>pretty close to what Barry's talking about with SSL-type </div>
<div>issue of identities. Where is that scaling problem when</div>
<div>no "bank" is involved in individual mail transactions, </div>
<div>only the initial set-up of identities?</div>
<div> </div>
<div>Gerald</div></div>