Re: holding of funds

FYI, in my opinion, this is something for an in-person discussion.  Legal,
business, and technical people discussing the terminology and rules, while
going through various scenarios.

What is a 3-party legal contract?  That doesn't exist at the moment.  This
is new "law".

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


On Sun, Jul 24, 2016 at 4:11 PM, Andrew Bransford Brown <andrewbb@gmail.com>
wrote:

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