Re: holding of funds

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]
>>>
>>
>>
>