<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Honestly, it would be better if software designers hadn't taken that<br class="">
"ubiquitous network connectivity" thing to heart.  There is nothing<br class="">
better for security and privacy (and in many cases functionality!)<br class="">
than avoiding unnecessary connections.<br class=""></blockquote><div class=""><br class=""></div><div class="">Maybe so.</div><div class=""><br class=""></div><div class="">But preventing double spending pretty much makes some form of network connectivity a requirement....</div></div></div></div></div></blockquote>You have to give up *something* to prevent double spending, but not necessarily network connectivity.  You could, for example, insist on attested hardware/software to carry out the transactions.  If I can trust that the payment fob you present is running unmodified official software on unmodified official hardware, and you can trust the same about my fob; and, of course, we trust that that software "does the right thing"; then trusted movement of money between my fob and yours is no big deal.</div><div><br class=""></div><div>The last couple of decades of work on cryptography has mainly concentrated on a model in which (a) endpoints don't trust each other; (b) there are no trusted third parties; (c) communications mechanisms can't be guaranteed to deliver messages unmodified or un-intercepted, but they *can* be trusted to be available and actually deliver messages between the parties as specified.  (Early on, the "positive" sides of (c) weren't assumed because they couldn't be provided in the real world.  That led an an even weaker and more limited model.)</div><div><br class=""></div><div>As we've learned, you can accomplish much more within this model than anyone would have thought possible 50 years ago  - but there are costs and tradeoffs.</div><div><br class=""></div><div>If you modify or eliminate any of the assumptions, you can get different solutions.  The blockchain is a quasi-trusted-third-party, for example.</div><div><br class=""></div><div>A big part of (a) is the assumption that endpoints are just software running on general-purpose machines.  This turns out to have all kinds of costs, both in terms of the difficulty of others trusting you - and even of *you* trusting your own endpoint.  In fact, that last bit - your inability to really gain trust in your own endpoint - is a topic of a huge amount of discussion on this list!  This is an area that's been explored, but proposed solutions have been rejected by many because of the potential for abuse.  How to keep the good features without *allowing* the bad is ... unknown.  It may simply not be possible.</div><div><br class=""></div><div>It's curious, BTW, that those who reject solutions with many good properties "because they can be used to enforce DRM" are perfectly happy to accept solutions that allow for, say, truly anonymous extortion. I'm not recommending one set of solutions over the other - looking back, I'd have include myself among those who had both of these reactions.  An honest appraisal of the pluses and minuses is the only way forward.</div><div><div>                                                        -- Jerry</div><div class=""><br class=""></div></div><br class=""></body></html>