Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

[Alexander Leishman]

There’s another potential partial solution here if we can create some 
cryptographic protocol for atomically swapping information. This would be used 
to swap the final HTLC sig for the hash preimage, preventing the optionality 
issue. This idea was inspired by a paper called “Timed Commitments” by Dan 
Boneh 
(https://www.iacr.org/archive/crypto2000/18800237/18800237.pdf). 

The high level idea is that each party swaps a commitment to the information 
they want to atomically swap and then slowly reveal verifiable “hints” that 
make it easier and easier to brute force the commitment. Each party takes turns 
revealing a hint. 

The protocol to do something like this in lightning doesn’t exist afaik but it 
seems feasible. This also may fail to work when there are intermediary nodes 
not controlled by the two trading parties. 

I also could be completely off here but I thought the idea was worth sharing. 

Best
Alex

> On Dec 27, 2018, at 10:47, Will Yager  wrote:
> 
> Very good point.
> 
> Two possible responses come to mind.
> 
> 1. Cross-asset brokers charge a standard option premium to perform the 
> brokerage. I can't tell if you think this is totally broken or if it's just 
> sad. I don't understand lightning well enough to figure that out on my own - 
> could you expand more on what effects this would have?
> 
> 2. Cross-asset brokers require counterparties to issue them a symmetric but 
> slightly more out-of-the-money call, which they can redeem in the event of a 
> large FX swing. This bounds their FX losses.
> 
> 
> Will
> 
> 
> 
> ‐‐‐ Original Message ‐‐‐
> On Thursday, December 27, 2018 1:43 PM, ZmnSCPxj via Lightning-dev 
>  wrote:
> 
> 
>>HTLCs allow creation of American Call Options.
> 
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

[Alexander Leishman]

Hello ZmnSCPxj,

> Do you mean, that if you make a swap on Lightning, which *might* be a
Bitcoin-to-WJT American Call Option, I will refuse to forward until I also
get something that is a WJT-to-Bitcoin call option, similar to a butterfly
spread?
> That implies that in the "normal", non-American-call-option case, the
payer has the target asset, which brings up the question: why would the
payer even go through the cross-asset broker in a Lightning route if the
payer already has the target asset?

No this isn't what I'm suggesting. Let me try to explain again. Apologies
if this isn't clear:

Let's assume only two parties are engaging in this interaction, you and me.
You offer me the WJT/BTC exchange rate from your mult-chain node and I
route an LN payment from my BTC node to my WJT node through your
multi-chain node. My understanding is that the main problem with this is
the free optionality I get when my WJT node does not return the hash
preimage immediately to you and instead waits to see if the market price
fluctuates out of my favor until option/HTLC expiry. But what if we could
atomically swap this preimage for the final HTLC you sent me? If this
magical atomic information swap could happen (I don't get the final HTLC
unless I reveal the preimage) the payment would settle immediately (in the
two party case, let's assume no other intermediary nodes). A timed
commitment approach could potentially be feasible if the time required to
brute force the commitment is longer than the life of the "option"/HTLC.
I'm not necessarily suggesting this the optimal solution, but I haven't
seen the idea mentioned before.

-Alex


On Thu, Dec 27, 2018 at 2:01 PM ZmnSCPxj  wrote:

> Good morning Alex and Will,
>
> > 1. Cross-asset brokers charge a standard option premium to perform the
> brokerage. I can't tell if you think this is totally broken or if it's just
> sad. I don't understand lightning well enough to figure that out on my own
> - could you expand more on what effects this would have?
>
> It is quite broken.
> We assume generally that if a payment route fails, that the payer making
> the payment route loses nothing.
>
> Unfortunately, once there is a premium involved for cross-asset swaps, it
> implies that any failures *after* the swap will now have a cost,
> specifically, the premium paid.
> Perhaps you could inform the cross-asset broker who the ultimate payee is
> so it can retry failures after it on your behalf, but now the broker has
> the ability to censor payments to payees it does not like.
>
> > 2. Cross-asset brokers require counterparties to issue them a symmetric
> but slightly more out-of-the-money call, which they can redeem in the event
> of a large FX swing. This bounds their FX losses.
>
> I am uncertain what you mean exactly.
>
> Do you mean, that if you make a swap on Lightning, which *might* be a
> Bitcoin-to-WJT American Call Option, I will refuse to forward until I also
> get something that is a WJT-to-Bitcoin call option, similar to a butterfly
> spread?
> That implies that in the "normal", non-American-call-option case, the
> payer has the target asset, which brings up the question: why would the
> payer even go through the cross-asset broker in a Lightning route if the
> payer already has the target asset?
>
>
> > There’s another potential partial solution here if we can create some
> cryptographic protocol for atomically swapping information. This would be
> used to swap the final HTLC sig for the hash preimage, preventing the
> optionality issue. This idea was inspired by a paper called “Timed
> Commitments” by Dan Boneh
> > (https://www.iacr.org/archive/crypto2000/18800237/18800237.pdf).
> >
> > The high level idea is that each party swaps a commitment to the
> information they want to atomically swap and then slowly reveal verifiable
> “hints” that make it easier and easier to brute force the commitment. Each
> party takes turns revealing a hint.
> >
> > The protocol to do something like this in lightning doesn’t exist afaik
> but it seems feasible. This also may fail to work when there are
> intermediary nodes not controlled by the two trading parties.
>
> The entire point of using HTLCs in Lightning routing is to enforce that
> the final payee actually gets paid, or nobody along the route gets paid.
> From my understanding of this, if this is used, then an intermediate node
> can try to brute force the preimage instead of actually bothering to
> forward payments or hints.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

[Alexander Leishman]

Nadav,

This is an interesting proposal, but because this still requires the
customer to trust the merchant, I am concerned that it adds complexity
without any meaningful guarantee to the customer. Perhaps it makes sense to
at least include some extension field here that allows the merchant to
include a ZKP for ZKCP-compatible data transfers? However, there are a number
of limitations  to consider
with those.

My two cents, is that the proposed standard would only be useful for the
edge case where a customer wants to pre-download the data before paying,
but still trusts the merchant. What's the main use you see for that? My gut
tells me there's a higher-level abstraction here to be standardized that
would handle more mainstream use-cases.

ZmnSCPxj,

> Putting MAC inside the encryption would help ensure that we can detect
data replacement over insecure channel, and use of shared secret ensures
only intended recipient can decrypt.

Generally you want to MAC the ciphertext + IV, otherwise you lose
ciphertext integrity guarantees. Why do you want to MAC, then encrypt?

-Alex


On Wed, Jun 26, 2019 at 4:55 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Nadav et al.,
>
> > > Any node on the route of the payment knows the preimage and can
> decrypt the data. It would be nice to tune the protocol in a way that only
> the buyer can decrypt the data. For example we could use something like
> this:
> >
> > Is this not covered by sending over the pre-image encrypted data over a
> secure channel such as HTTPS? If anyone along the route who learns the
> pre-image does intercept the message with the encrypted data, that data
> will already be encrypted for the intended recipient right?
>
> True, but the added protection allows sending the option of sending data
> over a non-secure channel.
> In particular, a secure channel like HTTPS would impose an
> encryption/decryption overhead, and then you will *also* encrypt/decrypt at
> the application layer i.e. you are encrypting twice.
> If you have the choice of using an insecure channel, you could take that
> and only have the encrypt/decrypt overhead only for the preimage-encrypted
> data.
>
> i.e. with this, you have the option of sending over both secure and
> insecure channels.
> It does not hinder use of secure channel, but enables use of insecure
> channel.
> Putting MAC inside the encryption would help ensure that we can detect
> data replacement over insecure channel, and use of shared secret ensures
> only intended recipient can decrypt.
>
> Regards,
> ZmnSCPxj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

[Alexander Leishman]

Chris,

Thanks for that explanation. I could see how this makes sense for
lightweight data payloads because it reduces the round trip count, but I
agree with ZmnSCPxj that this could pose a DoS risk for larger data
payloads. This DoS risk is even more magnified for ZKCPs.

I would guess that APIs selling data for lightning payments might take
different approaches:

1. You could purchase an auth token upfront that allows you access for some
amount of time of some number of requests (seems to be the most efficient
for APIs that would be called more than once)
2. You could pay per request (good for when you would want 1 big blob of
data)

So for the case where a customer is calling the API multiple times per day,
wouldn't it make more sense to pay upfront for future requests?

Best,
Alex

Best,
Alex



On Thu, Jul 4, 2019 at 8:36 PM ZmnSCPxj  wrote:

> Good morning Alexander,
>
> > > > Putting MAC inside the encryption would help ensure that we can
> detect data replacement over insecure channel, and use of shared secret
> ensures only intended recipient can decrypt.
> > >
> > > Generally you want to MAC the ciphertext + IV, otherwise you lose
> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>
> It is possible I simply misunderstand the proper use of MAC, so I shall
> research it in more depth.
>
>
> > I think the benefit here is in reducing the client-server interaction
> for REST apis while still ensuring payment to the merchant.
> >
> > Let's assume that we don't have this scheme, and want to provide a
> monetized REST API. The workflow looks like this, which is similar to what
> our behavior is now at Suredbits with websockets.
> >
> > 1. Client sends request to server for invoice
> > 2. Server returns invoice
> > 3. Client pays invoice
> > 4. Server sends data back, or client makes request _again_ to a server
> and then server returns data
> >
> > With Nadav's scheme this is simplified to
> >
> > 1. Client sends request to server
> > 2. Serves returns invoice, and encrypted payload
> > 3. Client pays invoice
> > 4. Client decrypts data according to Nadav's scheme
> >
> > This saves a round trip between the server and client. It also gives
> atomicity to the transaction, although as you stated before there is no
> guarantees about integrity of the encrypted data. This is generally a hard
> problem to solve in the technical sense, but I think the reputational harm
> of the server sending bad data will be enough to prevent this, who wants to
> do business with some one that isn't providing the advertised service? This
> is a interaction that is could be repeated thousands of times on a daily
> basis.
>
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
> Whereas the first would require more resources on the client side, as the
> server does not encrypt (or never encrypts at all) until the client has
> shown proof-of-payment.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev