W3C home > Mailing lists > Public > public-interledger@w3.org > July 2016

Re: holding of funds

From: Andrew Bransford Brown <andrewbb@gmail.com>
Date: Sat, 23 Jul 2016 20:02:27 -0500
Message-ID: <CAPS+YFLZk3P3M0nMNNOpKA2fMJSUPt+tdg2j3Rx50kvysiOF7g@mail.gmail.com>
To: "Romero, Javier (ISBANUK)" <Javier.RomeroColomo@isbanuk.com>
Cc: "public-interledger@w3.org" <public-interledger@w3.org>
Javier, good questions.

I think the following can be useful for separating implementation from
protocol.  This conforms to contract law.  Your questions pertain to the
"Deliver" event:

*CommerceID EventType Description*
Andrew     Offer     $20
Andrew     Terms     Lasagna
Computer   Notice    "This is an open legal binding offer."

Christine  Terms     $25

Andrew     Accept
Computer   Notice    "This is a binding legal contract."

Christine  Deliver   Lasagna
Andrew     Deliver   $20
Computer   Notice    "Contract complete."

The above forms what I call a "transaction stack" of events.  So, it
functions as a data structure, a protocol, and potentially a Contract
Scripting Language (CSL).  Each event would have a "snippet" to form a
smart contract.  It will handle any transaction in any currency (or
barter).  I think this can get ALL ledgers to talk the same language (easy
to roll this into debits/credits).

FYI, I have 20+ years of IT executive and design experience, a degree in
Accounting, and a stock trading background.  Comments would be appreciated.

Andrew B. Brown
10723 River Plantation Drive
Austin, Texas  78747
(512) 947-8282

On Sat, Jul 23, 2016 at 9:51 AM, Romero, Javier (ISBANUK) <
Javier.RomeroColomo@isbanuk.com> wrote:

> When the legacy ledger does not have the capability of holding funds, what
> would be the proposed solution?
>    - Assume the risk in the same way as an offline card transaction
>    (depending on amount etc...)?
>    - Get the balance at the moment of sending the instruction and then,
>    on the way back where all the crypto conditions have been met apply the
>    transfer if there are funds or fail it in case there aren't?
>    - 3rd party escrow?
> I guess each case needs assessment but wanted to see if you guys have a
> clear view in this.
> Thanks
> **********************DISCLAIMER*****************
> This message is private and confidential and it is intended exclusively
> for the addressee. If you receive this message by mistake, you should not
> disseminate, distribute or copy this e-mail. Please inform the sender and
> delete the message and attachments from your system. No confidentiality nor
> any privilege regarding the information is waived or lost by any
> mistransmission or malfunction.
> Any views or opinions contained in this message are solely those of the
> author, and do not necessarily represent those of ISBAN, unless otherwise
> specifically stated and the sender is authorized to do so.
> E-mail transmission cannot be guaranteed to be secure, confidential, or
> error-free, as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. ISBAN does not
> accept responsibility for any changes, errors or omissions in the contents
> of this message after it has been sent.
> This message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
> *********************AVISO LEGAL **********************
> Este mensaje es privado y confidencial y solamente para la persona a la
> que va dirigido. Si usted ha recibido este mensaje por error, no debe
> revelar, copiar, distribuir o usarlo en ningun sentido. Le rogamos lo
> comunique al remitente y borre dicho mensaje y cualquier documento adjunto
> que pudiera contener. No hay renuncia a la confidencialidad ni a ningun
> privilegio por causa de transmision erronea o mal funcionamiento.
> Cualquier opinion expresada en este mensaje pertenece unicamente al autor
> remitente, y no representa necesariamente la opinion de ISBAN, a no ser que
> expresamente se diga y el remitente este autorizado para hacerlo.
> Los correos electronicos no son seguros, no garantizan la confidencialidad
> ni la
> correcta recepcion de los mismos, dado que pueden ser interceptados,
> manipulados, destruidos, llegar con demora o incompletos, o con virus.
> ISBAN no se hace responsable de los cambios, alteraciones, errores u
> omisiones que pudieran hacerse al mensaje una vez enviado.
> Este mensaje solo tiene una finalidad de informacion, y no debe
> interpretarse como una oferta de venta o de compra de valores ni de
> instrumentos financieros relacionados.
> Ref:[PDB#015]
Received on Sunday, 24 July 2016 01:02:56 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 24 July 2016 01:02:57 UTC