From ya at slamail.org  Thu Nov 14 09:32:47 2019
From: ya at slamail.org (Yaacov Akiba Slama)
Date: Thu, 14 Nov 2019 11:32:47 +0200
Subject: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers
In-Reply-To: <87o8xfnrq2.fsf@rustcorp.com.au>
References: <87zhhb2bpf.fsf@rustcorp.com.au>
	<798f31a2-fb53-a7ce-4bd6-ef06102eebba@slamail.org>
	<877e4bt678.fsf@rustcorp.com.au>
	<857a3203-6f85-b40a-9d7a-bee320180a32@slamail.org>
	<87d0dzqch4.fsf@rustcorp.com.au>
	<cef4c415-a596-8ac6-330b-d02bd412ac6d@slamail.org>
	<87y2wko2x4.fsf@rustcorp.com.au>
	<90ab0a11-e4c1-92ad-e389-18514f67f2d2@slamail.org>
	<87o8xfnrq2.fsf@rustcorp.com.au>
Message-ID: <85c9e081-da64-7fae-23b8-cf4433bed2a4@slamail.org>

On 14/11/2019 03:59, Rusty Russell wrote:
> Yaacov Akiba Slama <ya at slamail.org> writes:
>> So we can integrate between them without intermixing the semantics of
>> the protocols but we need only to define the interaction points between
>> them.
>>
>> In the previous worflow, the seller can for instance add in the LN
>> invoice H(Quotation (UBL)||Order(UBL)||Prepayment Invoice(UBL)), and use
>> H(Receipt(UBL)) as preimage. With such a workflow, the UBL documents are
>> cryptographically tied to the LN payment.
>>
>> So the property of UBL of not being machine *handlable* is not altered
>> but the LN cryptographic properties are still used to tie the workflow.
>>
>> Am I missing something?
> Sure, people can do this today: simply set your `d` field to "UBL:
> <hash>".
Exactly. But we can add a BOLT which contains 1) references to UBL as a
way to exchange the business information needed in the payer<->payee
interactions and 2) describe the process of tying the document(s) to the
payment(s).
> But it provide what we want from offers:
> 1. Does not provide a "static invoice" flow.

What do you mean by "static invoice" flow? Perhaps:

* Seller -> Buyer: Invoice (UBL)

* Seller -> Buyer: Invoice (LN)

* Buyer & Seller: Payment + Ack (LN)

* Seller -> Buyer: Receipt (UBL)


> 2. Does not provide a donation flow.

* Payer -> Payee: Order (UBL)

* Payee ->Payer: Invoice (LN)

* Payer & Payee: Payment + Ack (LN)

* Payer -> Payer: Receipt (UBL)

> 3. Does not provide a method for wallets to do recurrence.

A simplified workflow can be:

* Seller -> Buyer: Quotation (UBL) containing recurring information

* Buyer -> Seller: Order (UBL) containing recurring information

Then at every beginning/end of period (depending on the info in the
quotation/order)

* Seller -> Buyer: Invoice (UBL)

* Seller -> Buyer: Invoice (LN) (d contain the hash of the invoice +
f(previous docs))

* Buyer & Seller: Payment & Ack (LN)

* Seller -> Buyer: Receipt (UBL)


> 4. Does not provide end-to-end over LN (i.e. no HTTP(s) requests).

Yes as soon as LN support messaging (using [1] or [2] for instance)

--yas


[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html

[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html