Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-10 Thread Rusty Russell
Yaacov Akiba Slama  writes:
> Hi Rusty.
>
> On 08/11/2019 05:09, Rusty Russell wrote:
>> Hi Yaacov,
>>  I've been pondering this since reading your comment on the PR!
>>
>>  As a fan of standards, I am attracted to UBL (I've chaired an
>> OASIS TC in the past and have great respect for them); as a fan of
>> simplicity I am not.  Forcing UBL implementation on wallet providers is
>> simply not going to happen, whatever I were to propose.
>
> In fact, using UBL in LN specification is simpler than trying to 
> understand the semantic of each field needed by businesses. You are 
> right that using such a standard put the burden into wallet providers 
> instead of LN developers, but as a wallet (breez) provider, I can say that:
>
> 1) Most money transactions (currently in fiat) are between users and 
> companies and not between two users. If we want to replace FIAT by 
> bitcoin, we need to create an infrastructure which can be used by 
> businesses. That means that LN needs to be able to be integrated easily 
> into POS systems. So, as a wallet provider who want to help the 
> transition from fiat to bitcoin, I need to be able to support standards 
> even if that means that I have to implement using/parsing big and 
> complicated standards.
>
> For simple user to user transaction, the wallet can decide to use only a 
> subset of the fields defined by the standard.
>
> 2) From a technical point of view, it seems that there are already UBL 
> libraries in java and c#. I don't think such library is hard to write in 
> go, rust.., so every wallet implementation can use them.

That is not the problem.  The problem is that our order flow is simple:

Seller: Offer
Buyer: Invoice Request
Seller: Invoice (or updated Offer)
Buyer/Seller: Payment & Acknowledgement (atomic)

(This could, of course, fit into a larger business flow.)

The closest UBL flow seems to be:

Seller: Quotation
Buyer: Order
Seller: (Prepayment)Invoice (or updated Quotation)

It's also worth noting that, even compressed, none of the UBL examples
fit into the 1023 byte limit of the existing invoice format:

UBL-Quotation-2.1-Example.xml: 1864 bytes (gz)
UBL-Order-2.1-Example.xml: 2515 bytes (gz)
UBL-Invoice-2.1-Example.xml: 3163 bytes (gz)

Indeed, that Quotation alone requires a 32x32 QR code.

>>  However, since invoices/offers and UBL are both structures, we
>> should have an explicit mapping between the two.  What fields should
>> have their own existence in the invoice/offer and what should be in a
>> general UBL field is a question we have to think on further.
> I agree that we don't want duplication. This is the reason, I propose to 
> use only ubl structure and add in the ln standard invoice an ubl 
> "opaque" field which will be self-contained and only add in the 
> invoice/offer/.. the fields specific to ln.

Except we need to go through the UBL spec and indicate exactly what
fields are permitted, and which are required.

Many UBI fields are not amenable to machine interpretation (eg. note
fields).  These must be either explicitly exposed to the buyer (in case
the seller uses them) such as shipping conditions, or explicitly
forbidden/ignored.

This is not a small task, and required intimiate knowledge of the UBL
spec.  It's not enough just to make something *look* like UBL.

Does anyone have expertise in this area?  Shall we form a sub-group to
investigate this properly?

Thanks!
Rusty.

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-10 Thread Rusty Russell
Ross Dyson  writes:
> Hi Rusty,
>
> We spoke in detail about this after your presentation at LNconf. I'm one of
> the contributors to LNURL so I am a little familiar with what you're trying
> to achieve and am very grateful you're considering implementing something
> similar to the mainnet protocol.
>
> I can only see delivery address being a nightmare for the network or wallet
> providers. If you take a quick look at any Shopify website right now and
> try to buy something to be delivered you will see validation of address
> inputs before accepting payment.
>
> This is the 'expected' UX of consumer applications in 2019. If offers were
> to not validate address inputs correctly the user will not receive the
> product, lose money, and have a [very] negative review of both the
> wallet-providing and the offer-providing businesses.
>
> Handling these UX expectations will require either the wallet provider or
> the offer provider to validate the inputs before proceeding with the sale.
>
>1. If the offer provider handles validation then the network will have
>to accommodate potentially infinite validation attempts (big no no I 
> assume)
>2. If the wallet provider were to provide the UX for input validation
>they are taking on significant workload to develop a robust address input
>UI, but more importantly the responsibility to correctly validate. There is
>plenty of room to screw up and create a catastrophic user experience.
>
> So I think address validation input is only possible via 2. but I think it
> is too much workload and responsibility to expect from wallet providers.

This is not the area I worry about, TBH, since every shopping website in
existence has implemented address input (and some form of validation).
I'm sure it'll be primitive to start with.

Of course, UBL has a standard 'AddressType' too:


http://docs.oasis-open.org/ubl/os-UBL-2.2/xsd/common/UBL-CommonAggregateComponents-2.2.xsd

>>From what I can see, it would not be impossible to bring delivery address
> functionality into offers retroactively after offers was already in prod.
> Perhaps icebox it?

Quite possibly something we can delay; most current goods are virtual
anyway.  However, delivery address standardization would greatly improve
the UX for such things.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


[Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

2019-11-10 Thread Takaya Imai
Hi all,

I propose Data Lightning Atomic Swap.
Anyone already have the same idea?


[Abstract]
This proposal is a way to swap data and lightning payment atomically.
It has two patterns, one is for a payer to swap data-download with
lightning payment to a payee (DLAS-down), the other is for a payer to swap
data-upload with lightning payment to a payee (DLAS-up).

The data is embedded to preimage so sending and receiving the data need
lightning payment at the same time.

-

[Motivation]
Atomic Swaps among crypto currencies has various ways to implement
(on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And
Atomic Swaps between data and crypto currencies are also proposed as a part
of TumbleBit mechanism[3], Storm mechanism[4] and so on.

Recently Joost Jager proposed Instant messages with lightning onion
routing, whatsat[5], which use recent sphinx payload change[6]. This is
very awesome but not atomic with lightning payment.

Atomic lightning mechanism for data is useful in use cases below.

-

[Pros & Cons]

* DLAS-down
** Pros
*** Atomic data download exchange with lightning payment
** Cons
*** It needs better mechanism to expand data size

* DLAS-up
** Pros
*** Atomic data upload exchange with lightning payment
** Cons
*** OG AMP[7] is needed to implement

-

[What I describe]
* A way to swap data with lightning payment atomically.

-

[What I do not describe]
* A way to detect that data is correct or not, namely zero knowledge proof
process.

For example, probabilistic checkable proof like TumbleBit[3] proposed.
Just message as data is no problem because no need to check the message is
correct or not.

* A way in case that different preimages are used in a payment route like
Multi-hop locks.

-

[Specification]

Lightning Network(LN) has a mechanism about preimage like a brief image
below.

Payer MediatorsPayee
=

Preimage
Preimage Hash  <- invoice 
 Preimage Hash
Preimage Hash  >   Preimage Hash >
 Preimage Hash
Preimage   <—-—-   Preimage  <
 Preimage

As you know, preimage Payer gets can be a proof of payment because Payer
can not get it if the payment is executed correctly.



1, Data download <->  lightning (DLAS-down)


Payer sends lightning payment and receives data from Payee atomically.


Payer MediatorsPayee
=
Payer Channel Pubkey <--->
Payee Channel Pubkey


 data(256bit, padded)

 enc_key = (Payee Channel Secret Key * Payer Channel Pubkey).x  (256bit)
enc_key = (Payer Channel Secret Key * Payee Channel Pubkey).x  (256bit)

 enc_data = data XOR enc_key
sha256(enc_data) <- invoice --
sha256(enc_data)
sha256(enc_data) > sha256(enc_data) ->
sha256(enc_data)
enc_data < enc_data <-
enc_data
data = enc_data XOR enc_key


* The size of data is restricted to 256 bits. Identically, it should be
extended to larger data and the data should be transferred in several
payment paths like DLAS-up.
* Channel Pubkey is only one for one channel and the data can be decrypted
if enc_key is leaked. So enc_key should be generated newly every time by a
way like hash chain but the protocol image above is just example for
simplicity.
* .x means X axis value of points on Elliptic Curve.
* If data is less than 256 bits, then 0x00 is padded (I am not sure which
of big endian and little endian is better).



2, Data upload <->  lightning (DLAS-down)

Payer sends data and lightning payment from Payee atomically.
This is like OG AMP(Atomic Multi-path Payment)[7] system.

Payer MediatorsPayee
=
data(512bit, padded)

share1(256bit)
share2(256bit)

base_s = share1 XOR share2
data1(256bit) ||  data2(256bit) = data(512bit)
XOR_d1 = data1 XOR base_s
XOR_d2 = data2 XOR base_s
PreImg1 = sha256(base_s || data || 1)
PreImg2 = sha256(base_s || data || 2)

sha256(PreImg1), XOR_d1, share1 -> sha256(PreImg1), XOR_d1, share1  ->
sha256(PreImg1), XOR_d1, share1
sha256(PreImg2), XOR_d2, share2 -> sha256(PreImg2), XOR_d2, share2  ->
sha256(PreImg2), XOR_d2, share1

   base
s = share1 XOR share2
   data
= (XOR_d1 XOR base_s) || (XOR_d2 XOR base_s)

 PreImg1 = sha256(base_s || data || 1)

 PreImg2 = sha256(base_s || data || 2)

PreImg1<---PreImg1

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-10 Thread Rusty Russell
Anthony Towns  writes:
> On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
>> Anthony Towns  writes:
>> [ Snip summary, which is correct ]
>
> Huzzah!
>
> This correlates all the hops in a payment when the route reaches its end
> (due to the final preimage getting propogated back for everyone to justify
> the funds they claim). Maybe solvable by converting from hashes to ECC
> as the trapdoor function?

I hadn't thought of this, but yes, once we've eliminated the trivial
preimage correlation w/scriptless scripts it'd be a shame to reintroduce
it here.

We need an accumulator with some strange properties though:

1. Alice provides tokens and a base accumulator.
2. Bob et. al can add these tokens to the accumulator.
3. They can tell if invalid tokens have been added to the accumulator.
4. They can tell how many tokens (alt: each token has a value and they
   can tell the value sum) have been added.
5. They can't tell what tokens have been added (unless they know all
   the tokens, which is trivial).

Any ideas?

> The refund amount propogating back also reveals the path, probably.
> Could that be obfusticated by somehow paying each intermediate node
> both as the funds go out and come back, so the refund decreases on the
> way back?
>
> Oh, can we make the amounts work like the onion, where it stays constant?
> So:
>
>   Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
>   400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
>
>   Success:
> Alice forwards 1500 msat to Bob   (-1500, +1500, 0, 0)
> Bob forwards 1500 msat to Carol   (-1500, 0, +1500, 0)
> Carol forwards 1500 msat to Dave  (-1500, 0, 0, +1500)
> Dave refunds 1200 msat to Carol   (-1500, 0, +1200, +300)
> Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
> Bob refunds 100 msat to Alice (-1400, +700, +400, +300)

Or, on success, upfront payment is fully refunded or not refunded at all
(since they get paid by normal fees)?  Either way, no data leak for that
case.

>   Clean routing failure at Carol/Dave:
> Alice forwards 1500 msat to Bob   (-1500, +1500, 0, 0)
> Bob forwards 1500 msat to Carol   (-1500, 0, +1500, 0)
> Carol says Dave's not talking
> Carol refunds 1100 msat to Bob(-1500, +1100, +400, 0)
> Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
>
> I think that breaks the correlation pretty well, so you just need a
> decent way of obscuring path length?

I don't see how this breaks correlation?

> In the uncooperative routing failure case, I wonder if using an ECC
> trapdoor and perhaps scriptless scripts, you could make it so Carol
> doesn't even get an updated state without revealing the preimage...

I'm not sure.  We can make it so Carol has Bob's preimage(s), etc, so
that the node which fails doesn't get paid.  I initially thought this
would just make people pair up (fake) nodes, but it's probably not worth
it since their path would be less-selected in that case.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev