[E-Lang] Security Breach: Nominee for the Stock Exchange Prize

[Marc Stiegler]

> >If I understand the ERiaSR proposal correctly (which I doubt, actually, I
> >sense nuances to the proposal I have not grokked properly), ERiaSR is
> >easier, more natural, and does not correctly model the real world, which
> >means I would spend more time trying to work around the incorrect model.
>
> The assertion that the ERiaSR model "does not correctly model the real
> world" is a silly and unsubstantiated claim. The ERiaSR model actually
does
> a much better job of representing message timelines. The LiveRef model is
> an incomplete and broken representation of the message timeline that was
> motivated solely by ill-conceived ideas about the implementation
> implications. In no way does the LiveRef model provide more information
> about the state of the world than the ERiaSR model does. In fact the
> LiveRef model provides less information, in crucially important areas, as
> you have just discovered.
>
> ( I get very annoyed when people try to argue using speculation about the
> "real world". It somehow feels like they're saying I lack the competence
to
> be presenting my side of the case. So, hopefully, you'll pardon some
> excessive rhetoric on my part ;)

Well, from my end, it looked like you were giving me the kind of argument
that would be made by a person with reliable communications, whose phone
line does not disconnect from his ISP on a regular basis. So I was incorrect
to say "real world", since the "real world" is rich and varied, but it is
correct to say that in "my personal section of the real world" disconnection
with my ISP is a real phenomenon, and E as it stands models that
relationship correctly (or am I no longer allowed to use in this august
forum the forbidden word-component "connect", even in the context of talking
about a phone that has hung up and I can hear the dial tone on it? Somehow,
when that happens, I feel that I have "lost connection". And good luck
explaining to the rest of the world that they haven't "lost connection" when
that happens. And I am happy that my windows on file servers that must be
reached across that connection (oops, that word again!)  close
automatically; I have an ocean of infrastructure way deep underneath E's
comm system that is far too crude for this event not to be significant at
the user level).

> >For example:
> >
> >I have lately been revamping eDesk to work with 089t, so I have
> >re-familiarized myself with that code. One of the clever things it does
is,
> >if an eDesk loses a connection to a file-server vat, it closes all the
> >windows on all the files and directories on that vat.
>
> This sort of functionality is easy to implement with an application level
> timeout. That this sort of functionality is somewhat easier to achieve in
> the LiveRef model, does not make up for the significant failures of the
> LiveRef model when implementing smart contracts, or other software that
> requires a complete model of the message timeline in order to fulfill its
> contract

You may be correct. The behavior of the system you described is sufficiently
different from current E that I cannot offhand see clearly all the
ramifications (though it sounds like one ramification is that a bidder
cannot burn his capability to his agentMaker onto a cd-rom and consider his
access backed up--every time he makes a bid, his "backup" is a freshly
minted capability. If he uses the capability he snagged off yesterday's
backup tape, he is out of timeline and in a world of hurt for which I still
need to write application-specific recovery software. Is this correct?).

The closest we have come so far to an interesting test case for these issues
is the 5-party salesman smart contract demo that markm and I partly designed
for OpenCola, but which has not yet been implemented. If Steve Jenson and
Dan Moniz make some good progress on that, perhaps they'll be in a position
to speak insightfully. The transaction in the demo that offhand seems most
vulnerable to timeline-breaking trouble is the moment when the buyer sends
cash to the contract server (i.e., sends the capability on a purse).  So if
and when there is code for this demo, that might be the part to scrutinize
for more knowledge.

--marcs