Re: holding of funds

Thanks for your responses Andrew!

My question was more if rather than just failing the transaction other
alternatives had been explored when a legacy ledger doesn't have the
capability of *holding/authorise temporarily* funds and just admits
confirmed transactions...

I guess a plugin sitting on top of the ledger could decide depending on the
situation:

- If less than a certain value, accept the transaction even if it leaves a
negative balance
- Use a 3rd party escrow for high values
- Just fail the transaction if needed if conditions are not met.
- Write a debit movement on the way out and then a credit movement if the
payment fails on the way back.
- ...



On 24 July 2016 at 15:30, Andrew Bransford Brown <andrewbb@gmail.com> wrote:

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