Re: holding of funds

That is the reason we need a standard protocol.  Those examples are all
internal functions of the application.

A protocol defines the interface, but does not decide implementation.  The
Deliver event might be Bitcoin, dollars, or any good/service.  The protocol
should verify that delivery was made and accepted, regardless of
implementation.

For example, I haven't decided how to handle 3rd party escrow services.
Note the complexity of the legal contract:

CommerceID     EventType         Description
Javier         Terms-Escrow      ABC Escrow
Andrew         Accept
Computer       Notice            "This is a binding contract, dependent on
ABC Escrow's acceptance."

ABC Escrow     Accept
Computer       Notice            "This is a 3-party legal contract."

Javier         Deliver           Lasagna
Andrew         Deliver           $25

ABC Escrow     Deliver           Lasagna
ABC Escrow     Deliver           $25

Computer       Notice            "Contract complete."


NOTE:  The "Deliver" destinations can be determined entirely via algorithm.


Andrew B. Brown
10723 River Plantation Drive
Austin, Texas  78747
(512) 947-8282
http://linkedin.com/in/keihatsu


On Sun, Jul 24, 2016 at 3:22 PM, Javier Romero <elmurci@gmail.com> wrote:

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