___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
1
___
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
Good morning Lloyd,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, May 19, 2019 6:28 PM, Lloyd Fournier wrote:
> Hi ZmnSCPxj,
>
> Sorry for the late reply I only recently had time to review your comments.
> I didn't really get your motivation for multiple secret
Hi ZmnSCPxj,
Sorry for the late reply I only recently had time to review your comments.
I didn't really get your motivation for multiple secrets. In my mind,
having the last hop put collateral into the HTLC to make a *Collateralized
HTLC* solves the problem without any extra complexity (your origi
Good morning Lloyd,
I think the most generic solution is to require multiple hashlocks.
One hashlock for the payee, the other for the exchange.
Payer acquires an exchange hash from the exchange, plus specs of the collateral.
Then payer routes to the payee via the exchange using two hashlocks (has
Hi ZmnSCPxj,
I'm glad you pointed this out. I think this protocol is practical. That
talk was actually given by my colleague :).
My post in the December thread was trying to explain the same idea but as a
[A -> Exchange -> A] on-chain trade (rather than a [A -> Exchange -> B]
cross chain L2 paymen
Good morning list,
Reviving an old thread, but I saw this just recently:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
Suppose you are a BTC to WJT exchange.
I want to pay 1 BTC to send 10 WJT to YAIjbOJA.
I have a BTC channel to you.
You have a WJT channel to
Good morning CJP,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Tuesday, January 8, 2019 10:26 PM, Corné Plooy wrote:
> ZmnSCPxj,
>
> Without reading your proposed solution, I don't understand the problem
> you describe here:
>
> > David solution effectively makes th
ZmnSCPxj,
Without reading your proposed solution, I don't understand the problem
you describe here:
> David solution effectively makes the exchange node (OM in CJP terminology)
> also the RM in the route.
> However, with use of mere preimages and hashes, it is obvious that such a
> "loop" wher
Good morning,
It may be helpful to remember that "cross-asset" need not mean "cross-chain";
for example, the RGB project strives to create assets committed on the Bitcoin
blockchain, in such a way that it would be possible to put them into Lightning
channels.
Thus this "proof-of-not-my-fault" a
True, as soon as this measure gets implemented (which AFAIK is not the
case right now). However, the attack is not free.
The victim interfaces between two different Lightning networks, each
operating a different asset, possibly on a different block chain (so
that proof of channel closuse on one s
ZmnSCPxj via Lightning-dev writes:
> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across
> Assets, or, An Argument For Single-Asset Lightning Network
Interesting. FWIW, I believe that multi-asset LN will fail for a
related, but different reason: to prevent long-lived s
Happy new year lightning-dev!
This topic is my main area of research at moment so I'm really happy to see
a thread about it. In general I agree with ZmnSCPxj's analysis and
conclusions. I'd like to add a couple of ideas to this discussion and would
greatly appreciate some early peer review on them
Good morning all,
> 6. In addition, F adds to the OM onion hop packet the below information:
> 1. `payment_point`
> 2. `exchange_rate_point`
> 3. The point sum of `(om_to_s_scalar + s_to_om_scalar) * G`
> 4. A signature using the point `(om_to_s_scalar + s_to_om_scalar) * G`
Good morning David and CJP,
Although we have determined that the David solution and all classes of that
solution are insufficient, it also triggered me to mentally compare the CJP
solution to the David solution.
David solution effectively makes the exchange node (OM in CJP terminology) also
th
Good morning Lloyd,
> > I agree.
> > When I was developing American Call Options on top of onchain HTLCs, I came
> > up with a similar construction for ensuring that the premium is paid before
> > the HTLCs setting up the option appear onchain.
>
> I would be interested to see how your constructi
On Sat, Jan 05, 2019 at 07:01:18AM +, ZmnSCPxj wrote:
> Good morning David,
>
> What happens if the exchange node only sends its preimage towards the
> payer and not towards the payee?
>
> If the payer and payee do not coordinate, then it becomes possible for
> the exchange node to take the f
Hi David and ZmnSCPxj,
ZmnSCPxj,
Thanks for your response. I messed something up with my response so my
original post didn't get into the archive. I put it in a gist:
https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def for
reference.
> I agree.
> When I was developing American Call
Good morning David,
What happens if the exchange node only sends its preimage towards the payer and
not towards the payee?
If the payer and payee do not coordinate, then it becomes possible for the
exchange node to take the funds without the payee gaining the ability to claim
the payment.
This
On Thu, Dec 27, 2018 at 05:43:51AM +, ZmnSCPxj via Lightning-dev wrote:
> We can try to mitigate this, but the solutions below all have significant
> drawbacks.
An alternative is to give the person making the exchange the ability to
cancel the payment if they think the exchange rate has chang
Good morning Lawrence,
> > On re-reading your argument, no, you have misunderstood massively.
> > The two HTLCs together form a single American Call Option, issued by the
> > exchange to the initiator of the "payment".
> > It is not the initiator somehow issuing an American Call Option to itself
> On 3 Jan 2019, at 13:24, ZmnSCPxj wrote:
>
> Good morning Lawrence,
>
> On re-reading your argument, no, you have misunderstood massively.
>
> The two HTLCs together form a *single* American Call Option, issued by the
> exchange to the initiator of the "payment".
>
> It is not the initiat
Good morning,
> On 3 Jan 2019, at 13:04, ZmnSCPxj wrote:
>
> Good morning Lawrence,
>
> While true, on Lightning, interest earnings are ***tiny*** enough that the
> premium "paid" in this manner is minimal.
> Increase in alternative interest earnings for Bitcoin on non-Lightning
> alternati
Good morning Lawrence,
On re-reading your argument, no, you have misunderstood massively.
The two HTLCs together form a *single* American Call Option, issued by the
exchange to the initiator of the "payment".
It is not the initiator somehow issuing an American Call Option to itself by
routing
Good morning Lawrence,
While true, on Lightning, interest earnings are ***tiny*** enough that the
premium "paid" in this manner is minimal.
Increase in alternative interest earnings for Bitcoin on non-Lightning
alternatives would also cut down the available liquidity on Lightning and
increase L
Do cross-asset lightning nodes do not offer premium-free American call options?
=
I would argue that cross-asset lightning nodes do not offer premium-free
American call options for the following reasons.
Say I wanted to set up to purchas
Good morning CJP,
> This, and the rest of your proposal, sounds like a lot of trouble,
> while it hardly solves anything.
>
> RM can have its node surrounded by other nodes also controlled by
> itself. So it is possible that RM controls all nodes that can possibly
> fulfill the 'G' role, and ther
Regarding this subject, I believe I should disclose that my current
employer, Bitonic, operates an evil, centralized, trusted exchange, and
that the ideas discussed in this thread may be related to concepts that
are actually being developed by my employer.
So, am I biased? Who knows? Does it matte
ZmnSCPxj schreef op wo 02-01-2019 om 13:02 [+]:
> I wonder however if this is a "small enough" hole that leaving it is
> an acknowledged security vulnerability may be better than replacing
> it with a trusted third party.
> One may compare with the SSH "trust the first pubkey, verify the
> seco
Good morning CJP,
>
> - No exchange: unattractive, because there is significant demand for
> this.
>
> - Regular Lightning-based or other HTLC-like atomic swap: unattractive,
> because of the exploitable "American Call Option" nature (as we both
> described). May only function with
Good morning Lloyd,
> Therefore, the ideal abstract functionality we want is:
>
> 1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`
> 2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled it)
> and get `A` in exchange for `B`.
> 3. *Cancel Offer* If Bob hasn't t
> 1. It seems to me that there is still friction here.
> RM, being a trusted third party, may very well charge as much as
> the market will bear. https://nakamotoinstitute.org/trusted-third-par
> ties/
> This seems to me to imply that OM (i.e. exchange nodes) will be
> unable to extract a
Hi ZmnSCPxj,
You are right that an exchange can not simply embed the option into the offer
price as there is no payment in case the offer is not taken, so nothing would
pay for their hedging costs.
This however is not a unique situation, but people deal with it frequently.
Every offer has a t
Hi ZmnSCPxj,
Making an asset swap offer using HTLC ties up funds and the offer may be taken
up-until the timelock expiry.
Therefore making such an offer implies both opportunity cost and a premium for
optional exercise.
There is no mechanism in LN to require compensation for above costs, there
Good morning CJP,
>
> I think we've already addressed this issue before:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/0012
> 92.html
>
> and especially this proposal of me:
> https://bitonic.nl/public/slowdown_prevention.pdf
>
> It's not completely trustless, but I tend to
Hi ZmnSCPxj,
I think we've already addressed this issue before:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/0012
92.html
and especially this proposal of me:
https://bitonic.nl/public/slowdown_prevention.pdf
It's not completely trustless, but I tend to see trustlessness in
Good morning James,
> It seems like the router in this case is essentially short a straddle on the
> BTC vs. WJT exchange rate with almost 0 premium. One way for the router to
> hedge this is to be long an equivalent straddle by constructing their own
> cross-chain payment to themselves with s
Good morning Tamas,
> Although there is no escape from above reasoning, a market maker could still
> be profitable as long as the option is worth less than the bid-ask spread.
> Therefore the issue does not mean that LN cross asset exchange is not
> feasible, but that there is lower bound on bid
Good morning Alex,
> > 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 "no
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-ca
It seems like the router in this case is essentially short a straddle on
the BTC vs. WJT exchange rate with almost 0 premium. One way for the router
to hedge this is to be long an equivalent straddle by constructing their
own cross-chain payment to themselves with some other node, for the same
amou
ZmnSCPxj,
Brilliant reasoning. I sum it up to make it more accessible:
Failing to route on purpose can be used to opt out of a previously agreed
exchange of two differents assets.
A rational actor will opt out if the exchange is no longer fair. Anyone who
grants an option for free heads financ
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 effec
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
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
HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across
Assets, or, An Argument For Single-Asset Lightning Network
Introduction
In theory, the Lightning Network could potentially perform "seamless" currency
conversions, allowing a payer to spend one currency t
47 matches
Mail list logo
