Re: holding of funds

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