Re: Alternative algorithm for timeouts

The way I've dealt with this in my design sketches is, instead of
"timeouts" there are "deadlines." Also instead of transactions, contracts.
And instead of race conditions, atomic transactions to/from ephemeral
"purse" accounts.

I am not clear on how what I'm about to share fits with ILP as currently
designed: I think an implementation of my design would be able to
participate in ILP.

Contract creation begins with a proposal including all parties, what
currencies and how much will be put in, what currencies and how much will
go out. This is an immutable thing and can be referred to by its hash.

All ledgers that would participate approve the form of the contract.

All participants obtain (from their ledger-providers) ledger-signed purse
objects containing what they will be putting in. Submitting a purse
constitutes approval of the contract -- additional approvals on contracts
can be required by requiring supervisory entities to submit empty purses,
or submit purses containing "approval points" or something like that.

after all participants have approved, accounts are credited from the purses
-- *not* from the participants accounts.


Transaction completions are published to participants, and the channels
that constitute input to the ledgers, with crypto-signatures of all parties
to a transaction in its final form, this publication constitutes a final
transaction

all signatures have timestamps and everyone is presumed to be using NTP to
keep within two seconds of each other

when a participant to a transaction is tendering something from a ledger,
the reversible thing that times out (the provisional tender) doesn't exist
until the tender is withdrawn from the controlling ledger into a "purse"
which exists only for the transaction, and has a deadline for completion of
the transaction, and is signed by the ledger from which the purse
originated. Purse data object is something like
   { type: 'expiring purse' ,
     purse: { type: 'purse', currency: '2017 freedom points', reverts_to: '
alice@example.com', usable_in_contract: 'AbCdEfG192837BEEF', deadline:
'2018-01-01', purse_creation_time: [now] },
     originating_ledger: 'identity of originating ledger, indirectly
implying public key used for signing things such as this',
     signature: 'crypto signature of canonically B-encoded purse data field'
   }

For transaction completion purposes, the originating ledger will only honor
the purse's participation in the specified contract when it receives
signatures on AbCdEfG192837BEEF timestamped on or before the deadline on
the purse.  A reasonable communications delay policy up to a participating
ledger concerning time of receipt should be enforced, such as "anything
received more than ten minutes after its signature timestamp, or after the
deadline for the contract, will be ignored."

Ledgers periodically sweep expired (deadline plus policy extension) purses
back to their reverts_to accounts.

The race condition introduced by having a shared deadline for the whole
contract is avoided by introducing additional deadlines for
atomically-manipulated-at-the-ledger purse objects. Double-spending is not
possible because ledgers must be designed to create purses safely.



On Fri, Jun 30, 2017 at 7:07 AM, Enrique Arizon Benito <
enrique.arizon.benito@everis.com> wrote:

> At this moment the algorithm to establish a timeout is something like:
>
>    1. start transaction
>    2. set timeout as "NOW" + Constant_Timeout_time
>    3. wait
>    4. "NOW" > timeout
>    1. YES -> timeout transaction
>       2. NOW -> Got to 3
>
> This introduces random false timeouts due to race-conditions. It could be
> possible for the receiving ledger to execute the transfer and for the
> originating ledger to time out due to the finite time to propagate the
> fulfillment back through all connectors.
>