- From: Andrew Bransford Brown <andrewbb@gmail.com>
- Date: Sun, 24 Jul 2016 09:30:08 -0500
- To: Javier Romero <elmurci@gmail.com>
- Cc: "Romero, Javier (ISBANUK)" <Javier.RomeroColomo@isbanuk.com>, "public-interledger@w3.org" <public-interledger@w3.org>
- Message-ID: <CAPS+YFKXvEohT8UUVEm9n3DQru4c7ZgHBxOTUib2PqzazechpQ@mail.gmail.com>
The "Deliver" event would not occur, of course. You could write an event to the "transaction stack": CommerceID EventType Description Andrew Deliver-Failure "Insufficient funds" The API could include a GetContractStatus(transactionID) that would return ""Undelivered", "Open", or "Partial delivery", or similar. It would be up to the application to determine who ships/delivers first. Andrew B. Brown 10723 River Plantation Drive Austin, Texas 78747 (512) 947-8282 http://linkedin.com/in/keihatsu On Sun, Jul 24, 2016 at 5:51 AM, Javier Romero <elmurci@gmail.com> wrote: > Thanks Andrew, > > But you would still need some kind of funds holding? > What would happen if, in your example, Andrew doesn't have enough balance > of funds at the time the transaction is executed? > > On 24 July 2016 at 02:02, Andrew Bransford Brown <andrewbb@gmail.com> > wrote: > >> 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 >> http://linkedin.com/in/keihatsu >> >> >> 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 14:30:38 UTC