Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
___ 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
1 ___ 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
___ 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
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 original example captures this perfectly). You wrote: The exchange can insist on getting a short timelock for receiving the > collateral (i.e. limit the time horizon that the exchange hash is valid), > to reduce the time horizon in which the payee can pay or not pay the > collateral for the exchange (as before the payee releases the collateral, > it still has the option of doing or not doing the swap, i.e. American > Option). I think this unnecessary. The "free option" time isn't limited by a timelock (if it was, we wouldn't have solved the problem). The option is limited by the exchange's willingness to wait for the other party to sign the state update (assuming the exchange signs first). The minor point I was trying to make was that normally when routing payments etc you can be willing to wait for minutes or hours for the other party to come back online if they went offline during a state update. But if you are doing a swap and your partner is meant to be signing a collateralized HTLC you shouldn't wait; you should force settlement to the blockchain within a few seconds. As soon as the state gets onto the blockchain the other party has lost any chance of getting an option. At a glance, the simplest way to enable this functionality is to add a new field to the "update_add_htlc" BOLT message [1] like "collateral_amount_sat". The receiver of "collateral_amount_sat" would have to contribute that amount to the HTLC (if they are willing to go through with the update). Obviously you should only ever agree to do this if you are last hop or are willing to risk your collateral on the honest behaviour of nodes further down. I was actually wondering if this could be a useful feature outside of swaps. e.g. if there is a new node without much reputation who you are routing a payment to, you could demand that they put up collateral into the HLTC to receive the payment. This might help prevent attacks where people try and tie up funds by receiving large payments they never release the secrets for. WRT to your final comments, it sounds a bit like [2] which also mentions that their protocol can make atomic swaps fungible. 1. https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc 2. Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability: https://eprint.iacr.org/2018/472.pdf Cheers, Lloyd On Mon, May 6, 2019 at 2:51 PM ZmnSCPxj wrote: > 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 > (hashlock for the payment hash, hashlock for the exchange hash) and from > the payee to the exchange. > The exchange onion hop includes the information that the cross-currency > swap is allowed by pointing at the hashlock that the exchange hash is on. > The exchange verifies that it is one of the exchange hashes it has issued > and it releases the agreed amount to the next hop, plus the collateral > agreed upon. > > The payee onion hop includes the information that it should proceed to > give a single hashlock to succeeding hops, as well as the agreed-upon > collateral to the exchange. > The exchange receives the payment with a single hashlock containing the > value of the collateral. > It verifies that the collateral value is equal to the agreed collateral > for that payment, then releases the exchange preimage. > The payee can then release its preimage once it has acquired the exchange > preimage. > > The above is similar to your solution, as it effectively means the payee > offers collateral to the exchange, which it can only reclaim by properly > completing the payment protocol. > The exchange can insist on getting a short timelock for receiving the > collateral (i.e. limit the time horizon that the exchange hash is valid), > to reduce the time horizon in which the payee can pay or not pay the > collateral for the exchange (as before the payee releases the collateral, > it still has the option of doing or not doing the swap, i.e. American > Option). > The advantage is that it can go over multiple hops, and the exchange and > payee do not know each other (but the payer does). > Disadvantage is that it requires two hashlocks, which is rather obvious on > the protocol and signals "this payment is a cross-currency exchange > payment!" to all intermediate nodes; also, it still allows a short time > duration for American Option shenanigans. > > The Route Maker solution by CJP is plausible, to me, only if the
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 (hashlock for the payment hash, hashlock for the exchange hash) and from the payee to the exchange. The exchange onion hop includes the information that the cross-currency swap is allowed by pointing at the hashlock that the exchange hash is on. The exchange verifies that it is one of the exchange hashes it has issued and it releases the agreed amount to the next hop, plus the collateral agreed upon. The payee onion hop includes the information that it should proceed to give a single hashlock to succeeding hops, as well as the agreed-upon collateral to the exchange. The exchange receives the payment with a single hashlock containing the value of the collateral. It verifies that the collateral value is equal to the agreed collateral for that payment, then releases the exchange preimage. The payee can then release its preimage once it has acquired the exchange preimage. The above is similar to your solution, as it effectively means the payee offers collateral to the exchange, which it can only reclaim by properly completing the payment protocol. The exchange can insist on getting a short timelock for receiving the collateral (i.e. limit the time horizon that the exchange hash is valid), to reduce the time horizon in which the payee can pay or not pay the collateral for the exchange (as before the payee releases the collateral, it still has the option of doing or not doing the swap, i.e. American Option). The advantage is that it can go over multiple hops, and the exchange and payee do not know each other (but the payer does). Disadvantage is that it requires two hashlocks, which is rather obvious on the protocol and signals "this payment is a cross-currency exchange payment!" to all intermediate nodes; also, it still allows a short time duration for American Option shenanigans. The Route Maker solution by CJP is plausible, to me, only if the exchange and the Route Maker are the same, which is effectively what is done here, but now requires multiple secrets to be revealed. I was thinking it might be possible, to use point/scalar and require the sum of the payment scalar and the exchange scalar, and thereby hide from intermediate nodes that multiple secrets are needed, but now the payer receives the sum of scalars instead of two separate preimages; this can make it difficult for protocols requiring proof-of-payment secrets (such as the offline vending machine discussed before) from working correctly. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, May 4, 2019 4:28 AM, Lloyd Fournier wrote: > 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 payment). For reference: > https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def. > > I mentioned it was possible to do it in a channel. Although looking back at > it now it seems I was somewhat confused at the time. I said: > > > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and the > > other party receiving it as asset B with some exchange node in the middle > > doing a conversion is unsound given what we are able to construct in > > Lightning. > > As you just showed, this is wrong. [A -> Exchange -> B] with the collateral > on the last hop works fine. After all, [A -> Exchange -> A] is just a special > case of [A -> Exchange -> B]. I agree that extending this idea across > multiple hops after the exchange securely looks impossible. > > Note, the Exchange should watch carefully for their counter-party delaying in > signing the channel update on the final hop (to gain value from the option > this gives them). If they notice this they should close the channel and > avoid doing business with this party. > Despite this, it's still a far better protocol than the vanilla atomic swap > because the delaying party has a far less time to realise any gains from the > option. The exchange can put an end to it by closing the channel within 1 on > chain tx. > > On naming. I think it's better to call it *collateral* rather than an *option > premium* because it is only paid on a failure to execute the trade. > I was thinking we can call them collateralized HTLCs. > > It's possible to modify the protocol slightly so that the party receiving the > option pays the *premium* regardless of whether they release x or not. This > makes it a proper cross chain option with guaranteed premium. > We made a poster
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 payment). For reference: https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def. I mentioned it was possible to do it in a channel. Although looking back at it now it seems I was somewhat confused at the time. I said: > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and the other party receiving it as asset B with some exchange node in the middle doing a conversion is unsound given what we are able to construct in Lightning. As you just showed, this is wrong. [A -> Exchange -> B] with the collateral on the last hop works fine. After all, [A -> Exchange -> A] is just a special case of [A -> Exchange -> B]. I agree that extending this idea across multiple hops after the exchange securely looks impossible. Note, the Exchange should watch carefully for their counter-party delaying in signing the channel update on the final hop (to gain value from the option this gives them). If they notice this they should close the channel and avoid doing business with this party. Despite this, it's still a far better protocol than the vanilla atomic swap because the delaying party has a far less time to realise any gains from the option. The exchange can put an end to it by closing the channel within 1 on chain tx. On naming. I think it's better to call it *collateral* rather than an *option premium* because it is only paid on a failure to execute the trade. I was thinking we can call them collateralized HTLCs. It's possible to modify the protocol slightly so that the party receiving the option pays the *premium* regardless of whether they release x or not. This makes it a proper cross chain option with guaranteed premium. We made a poster describing this idea here: https://coblox.tech/docs/financial_crypto19.pdf. Cheers, Lloyd On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > 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 YAIjbOJA. > > In order to create a properly-incentivized American Call Option with a > premium, you insist that 10% of the WJT value be the premium that is paid > if the exchange does not pull through. > > We perform this ritual: > > 1. YAIjbOJA generates a secret x and gives h(x) to me. > 2. On my channel to you, I get 1 BTC from my side and create an HTLC. > Hash is h(x) payable to you, timelock is 2 days payable to me. > 3. On your channel to YAIjbOJA, you get 10 WJT from you, and > 1 WJT (10%, the premium) from YAIjbOJA and create an HTLC. > Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to you. > > The above also forms an American Call Option, but with a premium if the > payment does not push through. > > However, extending this to beyond one hop after the exchange node is > difficult. > Problems in communicating with the next hop may cause the current hop > after the exchange node to become liable for the premium without being able > to forward the liability to the final payee, which is an avenue for attack. > And if the payee must be the hop after the exchange node, the exchange > node now knows exactly how much and when that node receives payment, and > can sell this information and/or selectively disrupt/censor some payments. > > Putting the premium before the exchange node is possible with an > additional transaction spending the HTLC (the timelock branch is payable to > a 2-of-2 with a pre-signed transaction that sends the premium to the > exchange and returns the rest of the value to the payer). > But this is unsafe, since the exchange (and any node between the payer and > the exchange) can stall the protocol deliberately and refuse to forward, > extracting the premium via the timelock branch. > This is effectively forcing fees even in a route failure, which does not > incentivize intermediate nodes to actually forward when they can do nothing > and receive fees anyway for not routing. > > 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] An Argument For Single-Asset Lightning Network
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 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" where the end payee (RM) is also an intermediate node, is foolish, > > as the end payee will simply claim the payment without letting the loop > > through. > > And since the payee (S in CJP terminology) is paid via the delta from its > > incoming to its outgoing HTLC on that loop, then if the RM is the OM then > > it is possible for the OM To simply steal the payment outright. > > (It is helpful to realize that payment routes pay not just the end payee, > > but all hops in the middle; thus the "real" target of the payment (the one > > who receives the bulk of the value) need not be at the end of the route) This is the problem with David solution. David solution requires that OM be the one that knows the preimage, and releases the preimage. Thus, it serves as the equivalent to RM. However... > > All hops on the route are linked together the same way as hops in a > regular Lightning payment. An intermediate node who is also the end > payee, and therefore knows the preimage, can indeed shortcut the payment > by accepting the payment on the intermediate node instead of forwarding > it; this is true for all Lightning payments []. Indeed. This is the problem with David solution. > I think the scenario where "the bulk of the value" ends up at one or > more intermediate nodes should not typically apply here. With a > sufficiently low spread and fees, the bulk of the value should be > roughly the same on each hop. The only thing that might be stolen is in > those fees and exchange rate differences. What I mean is that the transaction-payee S is paid, not by being the final payee in the route, but via the difference between its incoming and outgoing HTLCs. So semantically S is the transaction payee, but in terms of route, RM is the final payee. > So my proposal is not perfect, it does contain the trusted role RM, and > participants have to be somewhat careful which RMs they do business > with. However, it does have the benefit of de-coupling the trusted role > RM from the actual trading roles of OT and OM, so you only need to trust > a few parties and you can trade with lots of parties. There is another issue here. By creating the role of RM, we enforce that American Call Options pay a premium. F can route via OM to S, and S needs to forward to RM in order to acquire the preimage. Once S has acquired the preimage, however, it can stall, and the HTLCs formed are still an American Call Option equivalent. A price has been paid to acquire the preimage --- S had to forward value to RM to get the preimage. This is equivalent to paying a premium. This at least fixes the problem that OT no longer is capable of getting premium-free American Call Options. But notice who the premium is paid *to*. It is paid to RM. It is not paid to OM, who is the one who loses if the American Call Option is exercised. This is a rent paid by OM to RM. This can lead to rent-seeking behavior from RM if RM != OM. For instance, RM may acquire 8 random letters from /dev/random and start writing long articles about American Call Options on Lightning, as well as waxing lyrical about black swans and bleeder funds and cryptocurrency volatility, under those 8 random letters. This encourages people to create American Call Options that pay a premium to RM while bleeding OM when the option is exercised. What is pernicious here is that, even if we somehow derive some way of verification of RM behavior, on Lightning RM can behave perfectly correctly and release the preimage immediately. But S can still stall once it has paid the premium and acquired the preimage. Thus, RM != OM cannot be safe due to rent-seeking by RM. Regards, ZmnSCPxj ___ 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
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" where the end payee (RM) is also an intermediate node, is foolish, as > the end payee will simply claim the payment without letting the loop through. > And since the payee (S in CJP terminology) is paid via the delta from its > incoming to its outgoing HTLC on that loop, then if the RM is the OM then it > is possible for the OM To simply steal the payment outright. > > (It is helpful to realize that payment routes pay not just the end payee, but > all hops in the middle; thus the "real" target of the payment (the one who > receives the bulk of the value) need not be at the *end* of the route) All hops on the route are linked together the same way as hops in a regular Lightning payment. An intermediate node who is also the end payee, and therefore knows the preimage, can indeed shortcut the payment by accepting the payment on the intermediate node instead of forwarding it; this is true for all Lightning payments [*]. I think the scenario where "the bulk of the value" ends up at one or more intermediate nodes should not typically apply here. With a sufficiently low spread and fees, the bulk of the value should be roughly the same on each hop. The only thing that might be stolen is in those fees and exchange rate differences. By design, OT will pay the fees, so its outgoing amount will be higher than the incoming amount. RM will not want to exclude OT from its route. If RM is OM, then RM cannot exclude OM from the route either. Effectively, you end up with a RM-OT-RM route, which is OK if RM is OM. Minimizing Lightning route length to minimize fees is not a bad thing. There is a remaining issue though, that if RM is OM, then, obviously, RM and OM can cooperate to perform a delay attack on OT. I think this is acceptable, given that in section 4 of my paper[1] I already described some countermeasures OT can take. I think the attack possibility is wider: if OT and OM are anonymous / pseudonymous toward each other, then RM can either be OM and attack OT, or it can be OT and attack OM. I argued in section 4 that OM is more vulnerable than OT, but luckily the assumptions to this argument do not apply anymore. OM knows the attacker: it is RM. RM can perform a single attack on OM, and after that, OM will refuse incoming exchange transactions that are coordinated by RM. So my proposal is not perfect, it does contain the trusted role RM, and participants have to be somewhat careful which RMs they do business with. However, it does have the benefit of de-coupling the trusted role RM from the actual trading roles of OT and OM, so you only need to trust a few parties and you can trade with lots of parties. Trading parties can remain anonymous to RM, and they can hide from RM what second asset they are trading, and to what exchange rate, so there's very little that can be censored by RM. CJP [*] So it is a vulnerability for the idea where you anonymously donate to an intermediate node by giving it a huge fee. The vulnerability does not apply if you are the final payee, since nobody else but the final payee can perform the attack. Other parties might control multiple nodes on the route, but they only learn the preimage after HTLC acceptance on all hops. [1] https://bitonic.nl/public/slowdown_prevention.pdf ___ 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
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" apply to cross-asset swaps on the same blockchain? How about same-asset swaps across blockchains, e.g. RSK to Liquid? Of course the most obvious way, to create a unique assets, involves creating a unique blockchain for it, but the argument applies regardless for a multi-asset blockchain. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, January 8, 2019 9:27 PM, Corné Plooy via Lightning-dev wrote: > 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 side cannot be understood on the > other side) or even using a completely different technology. The problem > of the victim arises when an exchange transaction arrives from network > A, the victim forwards it on network B, and then the transaction gets > stalled. The victim can demand a proof that something went wrong on > network B, but cannot propagate that proof on network A. Since the > victim cannot propagate a valid proof, the victim will be penalized on > network A. > > My point is: the victim can still demand a proof that something went > wrong on network B. To stall the transaction, the attacker must be > controlling the node on network B that is doing the stalling. The same > anti-spam measure that penalizes the victim on network A also > penalizes the attacking node on network B. > > The penalties may not be the same: maybe on-chain fees are much lower on > chain B than on chain A. Still, the anti-spam measure should somewhat > reduce the attractiveness of this attack. > > CJP > > On 08-01-19 06:11, Rusty Russell wrote: > > > ZmnSCPxj via Lightning-dev lightning-dev@lists.linuxfoundation.org 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 spam payments we > > > may require proof that something went wrong (ie. channel unilateral > > > close tx). That won't be valid if it's from a different network, > > > resulting in the exchange point itself being penalized. Thus they are > > > vulnerable to such a DoS. > > > > Cheers, > > Rusty. > > > > 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 ___ 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
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 spam payments we may require proof that something went wrong (ie. channel unilateral close tx). That won't be valid if it's from a different network, resulting in the exchange point itself being penalized. Thus they are vulnerable to such a DoS. Cheers, Rusty. ___ 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
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 :) HTLCs as American call options = I think the "option problem" is actually caused by protocols using HTLCs in a naive way rather than the use of HTLCs themselves. Consider the atomic swap protocol described in the OP: >1. You provide me a hash of some secret preimage that only you know. >2. You make an HTLC on the Bitcoin blockchain. >The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day. >3. I make an HTLC on the WJT blockchain. >The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`. If we take this protocol and draw out its abstract functionality we get: 1. *Up for sale* Alice puts Asset `A` up for sale to Bob for some time period `Eb` + `Ea` 2. *Make expiring offer* Bob makes an offer of asset `B` which expires at time `Eb` 3. *Take offer* Alice may take the offer up until time `Eb` As has been pointed out, Alice has an "option" for the duration of `Eb` (and she didn't pay a premium). This is because Bob made her an offer he cannot cancel (an offer you can't cancel but has an expiration is basically the definition of being short an option contract). In order to remedy this, the party that makes the offer must be able to cancel their offer at any point after they have made it (before the counterparty has taken it). This should be intuitive because it's how centralised exchanges work. 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 taken the offer, Alice may get back `A` by cancelling the offer I developed the protocol below which comes pretty close to realising this. Let - α and β and be two bitcoin-like blockchains - Alice own asset `A` on the α blockchain and `C` on the β blockchain - Bob own asset `B` on the β blockchain 1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per usual) 2. Alice creates a partial β blockchain transaction by signing one input and one output (using SIGHASH_SINGLE for example): - The input is the asset `C` - The output is a HTLC which gives `B` and `C` to herself with the secret or gives them both to Bob on timeout She sends this partial transaction to Bob. (This gives us the "Make Offer" functionality) 3. If Bob wants to accept the offer, he adds asset `B` to another input of the transaction and posts it to β. (This gives us "Take Offer" functionality) 4. If Alice wishes to cancel the trade before Bob has confirmed this transaction she double spends the `C` output and then reclaims `A` on α after the timeout. (This gives us the "Cancel Offer" functionality) 5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the HTLC before the timeout or Bob will gain `C` AND get back `B`. 6. Once she reveals the secret, she both gets back `C` and gains `B` on β. 7. Bob can now take `A` on α in the usual manner now that he has learned the secret. Bob is not guaranteed to get `A` after he "takes" the offer but he is guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously, `C` is Alice's collateral for the trade. Bob should only take the offer if he wants `A` more than `B` and if he is sure that the value of gaining `C` will be greater than any loss he could experience from `B` depreciating relative to `A` during the execution of the protocol. I believe this shows that HTLCs do not in cause options but rather uncancelable offers + uncollateralized HTLCs cause the option problem. I think this protocol works in payment channels in the case that Alice and Bob have direct channels to each other. The issue is that if Alice decides she wants to cancel at the same time Bob decides he wants to take it you have to go to the blockchain to resolve the issue (which will be rather arbitrary). CJP's idea of having a 3rd party who is trusted simply to compute the outcome of a offer (cancelled or taken) in layer 2 networks seems like a promising direction because this would avoid on-chain resolution in this case. Cross Asset Payments Don't Make Sense As ZmnSCPxj demonstrated, the idea of sending a payment in asset `A` and the other party receiving it as asset `B` with some exchange node in the middle doing a conversion is unsound given what we are able to construct in Lightning. But this doesn't necessarily mean that Lightning has to be single asset. Theoretically, a single two-party channel could record multiple asset types with a state transaction that has distinct outputs for
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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` > of the serialization of the `payment_point` and `exchange_rate_point`. > 7. The OM verifies: > 1. That `exchange_rate_point` is a point corresponding to some exchange > rate quotation it issued before. > 2. That the exchange rate is still economically viable for it. > 3. That the sum of the `payment_point`, `exchange_rate_point`, and > `(om_to_s_scalar + s_to_om_scalar) * G` correspond to the point that OM will > need to learn the scalar of. Of course, this is susceptible to a key cancellation attack; `payment_point` may be `secret * G - exchange_rate_point`, which removes the exchange from controlling when the payment completes. A simple, naive mitigation would be for invoices to include a signature using the `payment_point` of an empty string. Then this signature also needs to be provided to OM in order to assure it that `payment_point` does not cancel its point. This is a simple proof-by-example that you should not trust your money to cryptosystems created by random people on the Internet. Regards, ZmnSCPxj ___ 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
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 the RM in the route. However, with use of mere preimages and hashes, it is obvious that such a "loop" where the end payee (RM) is also an intermediate node, is foolish, as the end payee will simply claim the payment without letting the loop through. And since the payee (S in CJP terminology) is paid via the delta from its incoming to its outgoing HTLC on that loop, then if the RM is the OM then it is possible for the OM To simply steal the payment outright. (It is helpful to realize that payment routes pay not just the end payee, but all hops in the middle; thus the "real" target of the payment (the one who receives the bulk of the value) need not be at the *end* of the route) But there is a way to safely loop through the end payee, and that is if the final payee has insufficient knowledge to perform the claim unless it lets the payment through via the loop. Suppose we can somehow make a route that requires two secrets: a secret known by the final payee (RM == OM) and a separate secret known by the "actual" payee (S). One way is to use points and scalars, another is to require two hashes from F to OM to S, then a single hash from OM to RM (RM == OM). Points and scalars are probably better since it obscures to intermediate hop nodes whether they are before S in a cross-asset payment or not. Below I describe the solution using points and scalars, and also including decorrelation. It should be trivial to convert it to two-hash form. 1. First, F contacts the OM (i.e. the exchange, who is also the RM) to acquire an exchange rate quotation. The OM provides 1. An exchange rate between BTC and WJT. 2. An exchange fee. 3. A one-time-use "exchange rate point". 4. A signature of the exchange rate and fee, signed using the scalar of the exchange rate point. This proves that the OM knows the scalar of the exchange rate point. 2. F creates a route from F to S via OM, and a route from S to OM. The route from F to S should pay the desired amount to S, plus the routing fees and exchange fee for the S to OM route. 3. As is typical for decorrelation, for every hop (including itself as a hop), F generates a random scalar. F sums up the decorrelation scalars of various parts of the total route: 1. F to OM: `f_to_om_scalar` 2. OM to S: `om_to_s_scalar` 3. S to OM: `s_to_om_scalar` 4. F offers a payment to the first hop node (can be OM, can be an independent hop node on BTC side) for the point: f_to_om_scalar * G + om_to_s_scalar * G + s_to_om_scalar * G + payment_point + exchange_rate_point 5. When the payment reaches OM from F, it gets paid if it is able to acquire the scalar corresponding to: om_to_s_scalar * G + s_to_om_scalar * G + payment_point + exchange_rate_point 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` of the serialization of the `payment_point` and `exchange_rate_point`. 7. The OM verifies: 1. That `exchange_rate_point` is a point corresponding to some exchange rate quotation it issued before. 2. That the exchange rate is still economically viable for it. 3. That the sum of the `payment_point`, `exchange_rate_point`, and `(om_to_s_scalar + s_to_om_scalar) * G` correspond to the point that OM will need to learn the scalar of. 8. The OM forwards the route (which is still opaque to it, thus cannot know S or F) subtracting its decorrelation scalar. 9. When the payment reaches S from OM, it gets paid if it is able to acquire the scalar corresponding to: s_to_om_scalar * G + payment_point + exchange_rate_point 10. S then subtracts `payment_scalar` (which it should know, with `payment_point = payment_scalar * G`) and its decorrelation scalar, and forwards it to the next hop. Note that S does not learn the identity of OM, and does not learn the exact `exchange_rate_point`. Only F knows who both OM and S are. This is appropriate is it is the one that sets up all the routes. 11. When the payment reaches OM from S, it gets paid if it is able to acquire the scalar corresponding to: exchange_rate_point When a payment terminates at OM, OM checks if it is also one of its exchange rate quotations. If the exchange rate is still economically viable for it, then it claims the payment. If not, it fails the payment, probably with an error for F that the exchange rate has gone out of synch and it should reacquire a new exchange rate.
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 construction worked. You can actually > modify the construction I gave before (in the gist) to create a fair option > too. You just change it so the asset `C` is paid on both branches of the > HTLC. This changes `C` from collateral to a premium. This sounds a bit > different to what you describe as the premium isn't paid before the HTLCs go > onto the chain. > > The only other proposal for options I've seen is: > https://www.ics.uci.edu/~jamesal1/Swaptions.pdf. I could be missing > something, but this seems to give Alice a free option on an option in this > one. The premium payment has the option problem: Bob cannot cancel his offer > of an option but Alice can take her time to accept it. I have not read the swaptions yet, but in any case, for the onchain American Call Option, I came up with the below, which I call roughly "pay for contract". In this, construction, we promise to publish a contract, but only if we are paid to do such a publication. This construction does not work well as a solution to the problem on Lightning (as it essentially resolves to "failed routes cost the payer money", a bad UX for payments in a network with partial information of channel status), but may be of interest otherwise. Suppose the below situation: I am selling you a contract that crosses multiple cryptocurrency systems (blockchains or state update channels or etc). You will be willing to pay me for such a contract, contingent on the contract being able to appear completely on all cryptocurrency systems involved. So we need to make the below UTXOs appear on the BTC and WJT blockchains: 1. BTC: `P` BTC, HTLC: hashlock me and preimage of hash, timelock you at time `E`+1. 2. WJT: 1 WJT, HTLC: hashlock you and preimage of hash, timelock me at time `E`. The above is an American Call Option as before, with you having the option to claim 1 WJT for `P` BTC at any time on or before `E`. The setup is that we first have a little ritual. 1. I generate a *different* preimage and hash. Let us differentiate it from the option preimage by calling this the contract-setup preimage and hash. 2. I prepare on the WJT blockchain the UTXO: 1 WJT, HTLC: hashlock (you+me) and preimage of contract-setup hash, timelock me at time `S`+1. The time `S` is the contract setup time, which should be nearer (much nearer) than time `E`. 3. On top of that, I create a transaction spending that UTXO on WJT, and outputting: 1 WJT, HTLC: hashlock you and preimage of option hash, timelock me at time `E`. This is one part of the American Call Option. I sign this transaction and give it to you. Notice, that this transaction cannot be confirmed: it is lacking your signature and the contract-setup preimage. 4. You prepare on the BTC blockchain the UTXO: `P`+`C` BTC, HTLC: hashlock (you+me) and preimage of contract-setup hash, timelock you at time `S`. `C` is the premium on the American Call Option. 5. On top of that, you create a transaction spending that UTXO on BTC, with two outputs: 1. `C` BTC, pubkey: me. This is my premium. 2. `P` BTC, HTLC: hashlock me and preimage of option hash, timelock you at time `E`+1. You sign this transaction and give it to me; again the transaction is incomplete as it lacks my signature and the contract-setup preimage. 6. I take your transaction and sign it, then add the contract-setup preimage that I know, and publish it on the BTC blockchain. The BTC side of the American Call Option has now been set up. I can now use my premium immediately, and can take the BTC if you ever publish the option preimage. 7. You take my transaction and sign it. Since I published the contract-setup preimage in the above step, you can get that preimage and attach it to the WJT transaction and publish it on the WJT blockchain. This now causes the WJT side of the American Call Option to become set up. If either of us stalls before step 6, or if I stall at step 6, then our assets revert back to us at time `S` or `S`+1. I assume we can safely set `S` to something within a few hours or less. If you stall at step 7 then you have already paid the premium to me at this point and have no incentive to just not continue the protocol, and at step 7 I can no longer stall the protocol since you will have everything to continue the setup of the American Call Option. Regards, ZmnSCPxj ___ 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
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 funds without the payee gaining the > ability to claim the payment. Indeed, you are correct. I had not taken that into account. Thinking about it from that perspective, there's no way to depend on proof that the someone received something (e.g. a payment) without also allowing the receiver to block payment by refusing to provide that proof. That invalidates this class of solutions. Thanks, -Dave signature.asc Description: PGP signature ___ 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
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 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 construction worked. You can actually modify the construction I gave before (in the gist) to create a fair option too. You just change it so the asset `C` is paid on both branches of the HTLC. This changes `C` from collateral to a premium. This sounds a bit different to what you describe as the premium isn't paid before the HTLCs go onto the chain. The only other proposal for options I've seen is: https://www.ics.uci.edu/~jamesal1/Swaptions.pdf. I could be missing something, but this seems to give Alice a free option on an option in this one. The premium payment has the option problem: Bob cannot cancel his offer of an option but Alice can take her time to accept it. > However, can such a scheme scale on-Lightning? The scalability issue with the scheme in payment channels is the lack of objective ordering of events in layer 2. If Alice and Bob disagree on whether "Take Offer" or "Cancel Offer" happened first, they will have to close their channel and resolve their dispute on the blockchain. This means that channels may have to go to the blockchain much more often than if you were just doing payments. In practice, this problem might not be so severe. Parties that have frequent disputes will just tend to stop opening channels with each other. It still guarantees that in the worst case there are no long options for either party. --- David, > Instead of Alice's node just locally constructing this path and trying > to pay it like normal, she first sends a special probe to Charlie > requesting a new hash for which only he knows the preimage. With this > hash plus the hash Alice received from Eliza, Alice sends a payment that > requires both hashlocks be unlocked before anyone can claim the payment. Moving the option from the random anonymous person (Alice) to the exchange node is a good improvement. If participants become good at identifying exchange nodes that delay in revealing the secret that might be enough to make the cross asset payment idea practical. As you hinted at, I think there is a simpler construction that is more compatible with today's lightning: 1. Alice given `A` wants to send `B` to Bob with Charlie doing the exchange. 2. Charlie generates a secret `s` and makes a payment of `B` to Bob locked under H(s) 3. Once Bob has the locked payment of `B` he sends H(s) to Alice 4. Alice then makes the payment of `A` under H(s) to Charlie. 5. Charlie now unlocks Alice's payment with `s` and receives `A` 6. Alice then learns `s` and sends it to Bob 7. Bob unlocks Charlie's payment with `s` and receives `B` > In ZmnSCPxj's terminology, the option is now no longer > free because Charlie must decide between potential routing income and > potential option income I didn't really get why the exchange would get any routing income from this? The exchange is the receiver of a payment of BTC on one leg and the sender of WJT on another. I'd expect the exchange would gain profit from spreads rather than fees in these protocols. Lloyd \n On Sat, Jan 5, 2019 at 6:01 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> 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 funds without the payee gaining the ability to > claim the payment. > This might be used by a node to take proofs of payment without paying, by > simulating the payer and exchange nodes. > This may be important if the proof of payment is valuable, such as, the > mentioned offline Lightning vending machines, or if the preimage is the > decryption key for valuable data (e.g. ransomware; now the ransomware > author may find it is scammed off their potential earnings). > > Regards, > ZmnSCPxj > > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, January 5, 2019 5:05 AM, David A. Harding > wrote: > > > 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 changed > > unfavorably for them. I think you could do that by adding an extra > > hashlock to the HTLC that's controlled by the exchanger. For example, > > here's what we'd expect a cross-asset
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 might be used by a node to take proofs of payment without paying, by simulating the payer and exchange nodes. This may be important if the proof of payment is valuable, such as, the mentioned offline Lightning vending machines, or if the preimage is the decryption key for valuable data (e.g. ransomware; now the ransomware author may find it is scammed off their potential earnings). Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, January 5, 2019 5:05 AM, David A. Harding wrote: > 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 changed > unfavorably for them. I think you could do that by adding an extra > hashlock to the HTLC that's controlled by the exchanger. For example, > here's what we'd expect a cross-asset path to look like: > > Alice Bob Charlie Dan Eliza > 1.3 mBTC -> 1.3 mBTC -> 1.2 mBTC > > 1.2 mWJT -> 1.1 mWJT -> 1.0 mWJT > > > Instead of Alice's node just locally constructing this path and trying > to pay it like normal, she first sends a special probe to Charlie > requesting a new hash for which only he knows the preimage. With this > hash plus the hash Alice received from Eliza, Alice sends a payment that > requires both hashlocks be unlocked before anyone can claim the payment. > > 1. When this payment reaches the exchanger, Charlie, he checks that the > payment includes a hashlock he controls before routing the payment on to > a different asset. > > 2. When the payment reaches receiver Eliza's node, she releases her > PreImage (PI0) back along the path. > > 3. When Eliza's preimage reaches exchanger Charlie's node, he releases > his preimage (PI1) in both directions along the path and continues > forwarding PI0 backwards. Eventually everyone receives both preimages > through the usual offchain or onchain mechanisms. > > Alice Bob Charlie Dan Eliza > PI0 <- PI0 <- PI0 <- PI0 <- PI0 (start here) > PI1 <- PI1 <- PI1 -> PI1 -> PI1 > > > However, if the exchange rate changes too much for Charlie's comfort > before both preimages have been released, Charlie can unilaterally > decide to cancel the payment by simply not releasing his preimage. > > Note that by making the payment contingent on the approval of the > exchanger, the ability to create an underhanded call option is > transferred to the exchanger. However, this may be less concerning > because the exchanger can only keep this option open by refusing to > immediately claim the routing fees. > > For example, our exchanger Charlie is being offered 0.1 mBTC to route > the payment (a made up number). If he can route 100 such payments in a > day (another made up number), he can earn 10.0 mBTC from routing. By > comparison, if he delays a payment of 1.2 mBTC, he'd need to expect the > exchange rate to change by an order of magnitude within a day to earn > the same amount. In ZmnSCPxj's terminology, the option is now no longer > free because Charlie must decide between potential routing income and > potential option income. Whether or not exchangers play the option game > will therefore likely be based on the amount of honest routing income > they can earn relative to the exchange rate volatility (and also on how > good nodes get at tracking reliable routes). > > This idea certainly complicates the current protocol (both routing and > transaction construction), but maybe there are simplifications > available. > > -Dave ___ 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
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 changed unfavorably for them. I think you could do that by adding an extra hashlock to the HTLC that's controlled by the exchanger. For example, here's what we'd expect a cross-asset path to look like: Alice Bob Charlie Dan Eliza 1.3 mBTC -> 1.3 mBTC -> 1.2 mBTC 1.2 mWJT -> 1.1 mWJT -> 1.0 mWJT Instead of Alice's node just locally constructing this path and trying to pay it like normal, she first sends a special probe to Charlie requesting a new hash for which only he knows the preimage. With this hash plus the hash Alice received from Eliza, Alice sends a payment that requires both hashlocks be unlocked before anyone can claim the payment. 1. When this payment reaches the exchanger, Charlie, he checks that the payment includes a hashlock he controls before routing the payment on to a different asset. 2. When the payment reaches receiver Eliza's node, she releases her PreImage (PI0) back along the path. 3. When Eliza's preimage reaches exchanger Charlie's node, he releases his preimage (PI1) in both directions along the path and continues forwarding PI0 backwards. Eventually everyone receives both preimages through the usual offchain or onchain mechanisms. Alice Bob Charlie Dan Eliza PI0<- PI0 <-PI0 <- PI0<- PI0 (start here) PI1<- PI1 <-PI1 -> PI1-> PI1 However, if the exchange rate changes too much for Charlie's comfort before both preimages have been released, Charlie can unilaterally decide to cancel the payment by simply not releasing his preimage. Note that by making the payment contingent on the approval of the exchanger, the ability to create an underhanded call option is transferred to the exchanger. However, this may be less concerning because the exchanger can only keep this option open by refusing to immediately claim the routing fees. For example, our exchanger Charlie is being offered 0.1 mBTC to route the payment (a made up number). If he can route 100 such payments in a day (another made up number), he can earn 10.0 mBTC from routing. By comparison, if he delays a payment of 1.2 mBTC, he'd need to expect the exchange rate to change by an order of magnitude within a day to earn the same amount. In ZmnSCPxj's terminology, the option is now no longer free because Charlie must decide between potential routing income and potential option income. Whether or not exchangers play the option game will therefore likely be based on the amount of honest routing income they can earn relative to the exchange rate volatility (and also on how good nodes get at tracking reliable routes). This idea certainly complicates the current protocol (both routing and transaction construction), but maybe there are simplifications available. -Dave signature.asc Description: PGP signature ___ 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
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 a payment to itself. > > It is the initiator forcing the exchange to give it the equivalent of an > > American Call Option by routing a payment to itself. > > In particular, the cost of locking the WJT asset is paid by the exchange, > > not the initiator of the contract. > > The initiator of the contract must deposit 1 WJT into the exchange before the > exchange will create the contract. Therefore the opportunity costs are borne > by the initiator. You still have not understood. We are discussing here a non-custodial exchange that acts as a Lightning Node on both BTC and WJT networks. Suppose I know of such a non-custodial exchange. I create a BTC channel to this. Then I create a WJT channel. In both cases, yes, I have to lock my assets into the channels created (unless we now have dual-funded channels and I convince the exchange node to fund the WJT channel). What I do then is to send out via the WJT channel to any WJT-accepting merchant and get something in value equivalent to the WJT I send out. It can be something as trivial as a submarine swap, where I get ***onchain WJT*** by paying my ***offchain WJT*** over Lightning. In this way, the WJT in the channel is ***no longer mine***, and given a fungible WJT asset then a submarine swap means I have reacquired the WJT I put in the channel in the first place; it is now available to me onchain to dispose of as I wish. If the WJT in the channel is locked up in an HTLC, ***I am not paying the opportunity costs for locking WJT***. It is the exchange which pays the opportunity cost since I have already paid the WJT to the exchange for a separate "unrelated" payment. Afterwards, I can coerce the exchange to issue me an American Call Option by routing a BTC payment from myself to a WJT payment to myself. Since the CLTV will be a future time and date, I can always delay failing or accepting the incoming HTLC until just before the indicated locktime. All your analysis means is precisely that nobody will rationally act as a Lightning node swap exchange, since being an exchange implicitly means you are offering American Call Options that are premium-free. If there are no Lightning node swap exchanges, then cross-asset swaps over Lightning cannot be done: nobody will enable the swap. Hence the conclusion: Lightning Network will remain single asset. Regards, ZmnSCPxj ___ 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
> 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 initiator somehow issuing an American Call Option to itself by > routing a payment to itself. > It is the initiator forcing the exchange to give it the equivalent of an > American Call Option by routing a payment to itself. > In particular, the cost of locking the WJT asset is paid *by the exchange*, > not the initiator of the contract. > The initiator of the contract must deposit 1 WJT into the exchange before the exchange will create the contract. Therefore the opportunity costs are borne by the initiator. >> If x_p = 0 then the issuer is guaranteed a loss. Therefore no rational >> contract issuer will issue an American call option for free. > > This implies that the nobody will act as an exchange (since it could be > coerced into issuing an American Call Option for free), hence the argument > that Lightning Network will always have a single asset. > Note that this is one trivial way for your conclusion: > >> lightning nodes do not offer premium-free American call options > > to be true, i.e. there will be no cross-asset nodes. > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, January 3, 2019 8:07 PM, Lawrence Deacon > wrote: > >> 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 purchase 1 WJT for P bitcoins at time t < T where >> t is the time I close the contract and T is the expiry time. >> >> In order to set up the contract I must pay P bitcoins to the contract, >> incurring an opportunity cost of x_i1. Assuming we set up the contract at >> time t_0=0, this will be equivalent to the money I could have earned by >> loaning the currency at interest during the period t. >> >> I must also pay the issuer of the contract a premium x_p (in the case where >> I am both recipient and issuer, see further down). >> >> If S(t) is the spot price at time t and K = S(t) - P then the payoff for me >> is as follows: >> >> S(t) > P:K - x_p - x_i1 >> S(t) < P:-x_i1 - x_p >> >> If x_i2 is the opportunity cost of paying 1 WJT to the contract for time t >> then the payoff for the other party (issuer) is as follows: >> >> S(t) > P:-K + x_p - x_i2 >> S(t) < P: x_p - x_i2 >> >> If x_p = 0 then the issuer is guaranteed a loss. Therefore no rational >> contract issuer will issue an American call option for free. >> >> In the case where I am both recipient and issuer of the contract, to get the >> payoff we add the above payoffs: >> >> S(t) > P: -x_i1 - x_i2 >> S(t) < P: -x_i1 - x_i2 >> >> This is a guaranteed loss. >> >> Conclusion >> >> Lightning nodes do not offer premium-free American call options because >> whether or not the contract and issuer are the same person, setting up a >> premium free American call option using a HTLC guarantees a loss for one or >> both parties. Even if the opportunity costs were 0, then setting up a >> contract with myself would have a guaranteed 0 payoff. > > ___ 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
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 > alternatives would also cut down the available liquidity on Lightning and > increase Lightning fees. If the contract issuer and recipient are different people, the issuer would charge an option price or premium, x_p, which would depend on volatility. If the issuer and recipient are the same person, they are guaranteed a loss. > > Further, the current nature of cryptocurrency assets is highly speculative > and large swings in exchange rates in short time frames are typical. > Thus the premium paid is minimal compared to the upside of the speculative > call option. This would be reflected in the premium calculated by the contract issuer; x_p increases with volatility. > > Finally, the massive problem here is that the exchange, which enables > cross-asset swap, is itself obligated to lock the asset to be called in the > contract. > In particular, the "premium" is ***not paid*** to the exchange node; instead, > the "premium", such as it is, is split between both the exchange and the user > of the American Call Option, and is paid as a temporary decrease in the > supply of both assets to the rest of the economy. > The galling part is that it violates the principle of "initiator pays", since > the exchange, which passively advertises its service, does not initiate the > creation of the American Call Option yet is forced to pay for its existence > by locking its own assets. > The initiator pays an opportunity cost by depositing funds into the exchange. > Given this, the logical consequence is that on-Lightning exchanges will > increase, probably greatly, their bid/ask spreads on Lightning compared to > custodial exchanges, increasing market friction on cross-asset payments on > Lightning. > This means that rational payees may find it more lucrative to accept the more > popular asset, identify a "trustworthy" custodial exchange, and use the lower > bid/ask spread on such a trust-based exchange to get more of their desired > target asset compared to being paid on Lightning. > > The end result is the Lightning network primarily settling on the most > popular of the assets, i.e. Bitcoin. > > Regards, > ZmnSCPxj > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, January 3, 2019 8:07 PM, Lawrence Deacon > wrote: > >> 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 purchase 1 WJT for P bitcoins at time t < T where >> t is the time I close the contract and T is the expiry time. >> >> In order to set up the contract I must pay P bitcoins to the contract, >> incurring an opportunity cost of x_i1. Assuming we set up the contract at >> time t_0=0, this will be equivalent to the money I could have earned by >> loaning the currency at interest during the period t. >> >> I must also pay the issuer of the contract a premium x_p (in the case where >> I am both recipient and issuer, see further down). >> >> If S(t) is the spot price at time t and K = S(t) - P then the payoff for me >> is as follows: >> >> S(t) > P:K - x_p - x_i1 >> S(t) < P:-x_i1 - x_p >> >> If x_i2 is the opportunity cost of paying 1 WJT to the contract for time t >> then the payoff for the other party (issuer) is as follows: >> >> S(t) > P:-K + x_p - x_i2 >> S(t) < P: x_p - x_i2 >> >> If x_p = 0 then the issuer is guaranteed a loss. Therefore no rational >> contract issuer will issue an American call option for free. >> >> In the case where I am both recipient and issuer of the contract, to get the >> payoff we add the above payoffs: >> >> S(t) > P: -x_i1 - x_i2 >> S(t) < P: -x_i1 - x_i2 >> >> This is a guaranteed loss. >> >> Conclusion >> >> Lightning nodes do not offer premium-free American call options because >> whether or not the contract and issuer are the same person, setting up a >> premium free American call option using a HTLC guarantees a loss for one or >> both parties. Even if the opportunity costs were 0, then setting up a >> contract with myself would have a guaranteed 0 payoff. > > ___ 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
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 a payment to itself. It is the initiator forcing the exchange to give it the equivalent of an American Call Option by routing a payment to itself. In particular, the cost of locking the WJT asset is paid *by the exchange*, not the initiator of the contract. > If x_p = 0 then the issuer is guaranteed a loss. Therefore no rational > contract issuer will issue an American call option for free. This implies that the nobody will act as an exchange (since it could be coerced into issuing an American Call Option for free), hence the argument that Lightning Network will always have a single asset. Note that this is one trivial way for your conclusion: >lightning nodes do not offer premium-free American call options to be true, i.e. there will be no cross-asset nodes. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 3, 2019 8:07 PM, Lawrence Deacon wrote: > 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 purchase 1 WJT for P bitcoins at time t < T where t > is the time I close the contract and T is the expiry time. > > In order to set up the contract I must pay P bitcoins to the contract, > incurring an opportunity cost of x_i1. Assuming we set up the contract at > time t_0=0, this will be equivalent to the money I could have earned by > loaning the currency at interest during the period t. > > I must also pay the issuer of the contract a premium x_p (in the case where I > am both recipient and issuer, see further down). > > If S(t) is the spot price at time t and K = S(t) - P then the payoff for me > is as follows: > > S(t) > P: K - x_p - x_i1 > S(t) < P: -x_i1 - x_p > > If x_i2 is the opportunity cost of paying 1 WJT to the contract for time t > then the payoff for the other party (issuer) is as follows: > > S(t) > P: -K + x_p - x_i2 > S(t) < P: x_p - x_i2 > > If x_p = 0 then the issuer is guaranteed a loss. Therefore no rational > contract issuer will issue an American call option for free. > > In the case where I am both recipient and issuer of the contract, to get the > payoff we add the above payoffs: > > S(t) > P: -x_i1 - x_i2 > S(t) < P: -x_i1 - x_i2 > > This is a guaranteed loss. > > Conclusion > > Lightning nodes do not offer premium-free American call options because > whether or not the contract and issuer are the same person, setting up a > premium free American call option using a HTLC guarantees a loss for one or > both parties. Even if the opportunity costs were 0, then setting up a > contract with myself would have a guaranteed 0 payoff. ___ 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
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 Lightning fees. Further, the current nature of cryptocurrency assets is highly speculative and large swings in exchange rates in short time frames are typical. Thus the premium paid is minimal compared to the upside of the speculative call option. Finally, the massive problem here is that the exchange, which enables cross-asset swap, is itself obligated to lock the asset to be called in the contract. In particular, the "premium" is ***not paid*** to the exchange node; instead, the "premium", such as it is, is split between both the exchange and the user of the American Call Option, and is paid as a temporary decrease in the supply of both assets to the rest of the economy. The galling part is that it violates the principle of "initiator pays", since the exchange, which passively advertises its service, does not initiate the creation of the American Call Option yet is forced to pay for its existence by locking its own assets. Given this, the logical consequence is that on-Lightning exchanges will increase, probably greatly, their bid/ask spreads on Lightning compared to custodial exchanges, increasing market friction on cross-asset payments on Lightning. This means that rational payees may find it more lucrative to accept the more popular asset, identify a "trustworthy" custodial exchange, and use the lower bid/ask spread on such a trust-based exchange to get more of their desired target asset compared to being paid on Lightning. The end result is the Lightning network primarily settling on the most popular of the assets, i.e. Bitcoin. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 3, 2019 8:07 PM, Lawrence Deacon wrote: > 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 purchase 1 WJT for P bitcoins at time t < T where t > is the time I close the contract and T is the expiry time. > > In order to set up the contract I must pay P bitcoins to the contract, > incurring an opportunity cost of x_i1. Assuming we set up the contract at > time t_0=0, this will be equivalent to the money I could have earned by > loaning the currency at interest during the period t. > > I must also pay the issuer of the contract a premium x_p (in the case where I > am both recipient and issuer, see further down). > > If S(t) is the spot price at time t and K = S(t) - P then the payoff for me > is as follows: > > S(t) > P: K - x_p - x_i1 > S(t) < P: -x_i1 - x_p > > If x_i2 is the opportunity cost of paying 1 WJT to the contract for time t > then the payoff for the other party (issuer) is as follows: > > S(t) > P: -K + x_p - x_i2 > S(t) < P: x_p - x_i2 > > If x_p = 0 then the issuer is guaranteed a loss. Therefore no rational > contract issuer will issue an American call option for free. > > In the case where I am both recipient and issuer of the contract, to get the > payoff we add the above payoffs: > > S(t) > P: -x_i1 - x_i2 > S(t) < P: -x_i1 - x_i2 > > This is a guaranteed loss. > > Conclusion > > Lightning nodes do not offer premium-free American call options because > whether or not the contract and issuer are the same person, setting up a > premium free American call option using a HTLC guarantees a loss for one or > both parties. Even if the opportunity costs were 0, then setting up a > contract with myself would have a guaranteed 0 payoff. ___ 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
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 thereby stop any evidence being generated > against the RM node. If you then want to build evidence against the G > nodes, you end up recursively involving every single Lightning node in > trying to solve your problem. Maybe it is possible, but I'd like not to > do that. I like to see the exchange function as a higher layer (layer > 3) on top of the Lightning layer, and have each layer solve its own > problems in a clean and elegant way. I prefer that nodes that aren't > involved in exchanging assets don't need to deal with its complexities > either. Which is why I later say: > > Note that since the path from S to RM is selected by RM, though, S must > > serve as G, and every node in-between that is honestly not a sockpuppet of > > RM should be prepared to shut down their channels immediately in case of > > slow response from the next node. Assuming S is a payee, it has every incentive to follow this protocol. Of course, now OM needs to know G, and thus knows S, the payee, and now has the power to censor payments. Heavy sigh. Further, if S is not a payee, but is secretly a sockpuppet of F who is setting up an American Call Option, S can simply not forward to RM until much later. Heavy sigh. Regards, ZmnSCPxj ___ 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
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 matter? Can you trust me? Maybe, but I guess you shouldn't anyway. In my view, words should be convincing or unconvincing regardless of who speaks them. CJP CJP schreef op vr 28-12-2018 om 09:27 [+0100]: > Hi ZmnSCPxj, > > I think we've already addressed this issue before: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/00 > 12 > 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 a > very pragmatic sense anyway. Trust creates a risk, but if the > alternative trustless system is very impractical, and the risk is > small > enough, the benefits might simply be worth the risks. Note that this > is > a completely subjective trade-off, so it is only acceptable on an > individual, voluntary basis. > > CJP > ___ 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
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 > second onwards" weakness, to SSL "trust the certificate authority to > say whose pubkey is whose". SSH's problem (non-authenticated initial key exchange) is small, because there is a very small time window for an attack, and an attacker has to place itself in the route *and* stay in the route to not be detected later. SSL's problem (trusted third parties for key authentication) is big, because each website only uses a single certificate issuer, so you need to trust every certificate issuer to be able to visit every website, even the more questionable certificate issuers; the combined security is as strong as the weakest certificate issuer. Route Makers (RM) (maybe I should change that name) are not a big problem, because, unlike websites, OMs and OTs are very fungible towards each other, especially on popular asset pairs: it's not a big deal if you lose, say, 10% of potential trading partners because you don't want to use a certain RM. Also, a single attack by a RM is not typically a big deal, and it is easily detectable. False positives are possible though (both accidental and deliberate), so you might want to suspend a RM after abuse detection for a while, and then give it another chance after some time. > The hop node just before the RM can provide proof that it offered an > HTLC and the RM allowed the HTLC offer to be made. > It can provide a commitment transaction signed by itself and the RM, > with that commitment transaction containing the HTLC in question. > This is proof that the RM *could* pull the HTLC, but did not do so > quickly enough. > > Since RM nodes are publicly known, perhaps we can make a different > routing from S to RM, one that reveals (to hop nodes) their distance > to RM, but not to S. > RM nodes provide a service to the network and we can argue that the > loss of their privacy here is acceptable, as long as the payee S is > still able to keep its privacy, as an acceptable cost to ensuring > that RM behaves honestly. > > If the just-before-last node (let us call this G or "guard" node) can > monitor the time that RM pulls the HTLC, then it can provide proof > that RM had the ability to pull the HTLC but did not do so. 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 thereby stop any evidence being generated against the RM node. If you then want to build evidence against the G nodes, you end up recursively involving every single Lightning node in trying to solve your problem. Maybe it is possible, but I'd like not to do that. I like to see the exchange function as a higher layer (layer 3) on top of the Lightning layer, and have each layer solve its own problems in a clean and elegant way. I prefer that nodes that aren't involved in exchanging assets don't need to deal with its complexities either. CJP ___ 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
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 a very high spread, compensating for > OM's risk. > > - Regular, centralized exchanges: current situation. Third party is > trusted with holding funds and executing trade orders. > > - My proposal: third party is trusted with executing transactions > properly (not performing the delay attack). > > - Trustless exchange: holy grail, but I don't know how to do that. > > So I don't claim my proposal is perfect, but I'd like to argue it is > the best known system because it's an improvement over the current > situation where most people use centralized exchanges, at least in > terms of trust required(*). You may be right. 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 second onwards" weakness, to SSL "trust the certificate authority to say whose pubkey is whose". OMs do have mitigations, specifically: (1) reducing the allowed forwarded CLTV distance and (2) increasing the bid-ask spread; perhaps that can be enough to enable a somewhat-multiasset network. > Now, if an RM can be punished, it would be even better. I was thinking in the > direction of collecting proof of misbehavior, which can then help make the RM > lose its (lucrative!) business, but I doubt this is possible. The hop node just before the RM can provide proof that it offered an HTLC and the RM allowed the HTLC offer to be made. It can provide a commitment transaction signed by itself and the RM, with that commitment transaction containing the HTLC in question. This is proof that the RM *could* pull the HTLC, but did not do so quickly enough. Since RM nodes are publicly known, perhaps we can make a different routing from S to RM, one that reveals (to hop nodes) their distance to RM, but not to S. RM nodes provide a service to the network and we can argue that the loss of their privacy here is acceptable, as long as the payee S is still able to keep its privacy, as an acceptable cost to ensuring that RM behaves honestly. If the just-before-last node (let us call this G or "guard" node) can monitor the time that RM pulls the HTLC, then it can provide proof that RM had the ability to pull the HTLC but did not do so. The G cannot attack the RM, since if G then stalls after the RM releases the preimage to it, the RM can just publish the commitment transaction with the HTLC onchain, together with the release of the preimage. In the onchain case, proof of RM malfeasance reduces to checking if the preimage appears onchain "fast enough". However, this could be attacked by stuffing blocks and increasing onchain fees, a risk whose cost the RM will pass to F and S nodes. Under Poon-Dryja, we can do: 1. After a new commitment transaction is signed, the old commitment transaction is still publishable onchain. 2. The old commitment transaction only becomes unpublishable (via punishment) if it is revoked, which is done after the new commitment transaction is signed. 3. Thus, if G node wishes to show malfeasance by RM, it must show that it revoked the commitment transaction just before that one by publishing the new commitment transaction (containing the HTLC to RM as proof that RM could have claimed but did not) onchain instead of the old commitment transaction (since what is published onchain becomes true, that is sufficient). 4. The RM must defend against the claim of malfeasance by claiming the HTLC immediately, publishing the preimage. 5. The OM must know the channel by which the RM gets paid (and thus the identity of G and RM) in order to monitor that channel and get its input asset immediately when a malfeasance claim is responded to by the RM. Under Decker-Russell-Osuntokun, we cannot perform the claim of malfeasance, and the RM defense, onchain. This is because of the CSV in-between the update and settlement transactions, which prevents timely publication of the HTLC and the preimage claiming it onchain. This is compensated for somewhat in that the signing of a new update transaction is sufficient to prevent publication (via gainsaying) of older update transactions, so we can perform the claim of malfeasance and the RM defense offchain completely. The G node publishes (via some non-blockchain protocol somehow, wave hands here) the update transaction and corresponding settlement transaction with the HTLC in question as a claim-of-malfeasance. The RM node defends against this by publishing (via some uncensorable method) the transaction that claims the HTLC with a preimage. The need for some
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 taken the offer, Alice may get back `A` by > cancelling the offer > > I developed the protocol below which comes pretty close to realising this. > Let > - α and β and be two bitcoin-like blockchains > - Alice own asset `A` on the α blockchain and `C` on the β blockchain > - Bob own asset `B` on the β blockchain > > 1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per usual) > 2. Alice creates a partial β blockchain transaction by signing one input and > one output (using SIGHASH_SINGLE for example): > - The input is the asset `C` > - The output is a HTLC which gives `B` and `C` to herself with the secret > or gives them both to Bob on timeout > She sends this partial transaction to Bob. (This gives us the "Make Offer" > functionality) > 3. If Bob wants to accept the offer, he adds asset `B` to another input of > the transaction and posts it to β. (This gives us "Take Offer" functionality) > 4. If Alice wishes to cancel the trade before Bob has confirmed this > transaction she double spends the `C` output and then reclaims `A` on α after > the timeout. (This gives us the "Cancel Offer" functionality) > 5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the > HTLC before the timeout or Bob will gain `C` AND get back `B`. > 6. Once she reveals the secret, she both gets back `C` and gains `B` on β. > 7. Bob can now take `A` on α in the usual manner now that he has learned the > secret. > > Bob is not guaranteed to get `A` after he "takes" the offer but he is > guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously, `C` > is Alice's collateral for the trade. Bob should only take the offer if he > wants `A` more than `B` and if he is sure that the value of gaining `C` will > be greater than any loss he could experience from `B` depreciating relative > to `A` during the execution of the protocol. > > I believe this shows that HTLCs do not in cause options but rather > uncancelable offers + uncollateralized HTLCs cause the option problem. 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. However, can such a scheme scale on-Lightning? > > I think this protocol works in payment channels in the case that Alice and > Bob have direct channels to each other. The issue is that if Alice decides > she wants to cancel at the same time Bob decides he wants to take it you have > to go to the blockchain to resolve the issue (which will be rather > arbitrary). CJP's idea of having a 3rd party who is trusted simply to compute > the outcome of a offer (cancelled or taken) in layer 2 networks seems like a > promising direction because this would avoid on-chain resolution in this case. > > Cross Asset Payments Don't Make Sense > > > As ZmnSCPxj demonstrated, the idea of sending a payment in asset `A` and the > other party receiving it as asset `B` with some exchange node in the middle > doing a conversion is unsound given what we are able to construct in > Lightning. > > But this doesn't necessarily mean that Lightning has to be single asset. > Theoretically, a single two-party channel could record multiple asset types > with a state transaction that has distinct outputs for different > asset-type/party combinations. This would allow you to buy an amount of the > desired asset in one of your channels by simply doing a state update where > you lose `A` in exchange for `B` with your direct peer (no HTLCs needed). You > can then just send `B` normally to the receiver. This is not quite as good as > a cross asset payment but it could still be useful*. It may be possible with RGB. However, you still need some kind of route from yourself to the payee, and the entire route from payer to payee needs to be liquid for the target asset. If there is no viable route where all channels have the asset, then the payment cannot push through. In addition, this cannot be a cross-blockchain asset, since channels can exist on exactly one blockchain or other cryptocurrency system. Regards, ZmnSCPxj ___ 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
> 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 any sizable fee, i.e. any fees that the market > would be willing to pay to exchange between assets will be taken by > RM as rent, and not by the OM who actually makes the market exist in > the first place. You may be right about the fees, but that doesn't necessarily make it an unattractive proposition for the OM party. When looking at different alternatives by sorting them in a better/worse fashion rather than a perfect/imperfect fashion, I see this: * 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 a very high spread, compensating for OM's risk. * Regular, centralized exchanges: current situation. Third party is trusted with holding funds and executing trade orders. * My proposal: third party is trusted with executing transactions properly (not performing the delay attack). * Trustless exchange: holy grail, but I don't know how to do that. So I don't claim my proposal is perfect, but I'd like to argue it is the best known system because it's an improvement over the current situation where most people use centralized exchanges, at least in terms of trust required(*). To compare the two: I'd like to compare the RM role in my proposal to that of a centralized exchange. Both need to be trusted to some degree, and since trust doesn't scale very well (you can't keep track of thousands of parties), both are probably a natural oligopoly market. As you wrote, these are the parties that are capable of extracting the majority of transaction fees. Still, as centralized exchanges show, people are prepared to trade this way, so apparently it's still an attractive market for both offer-makers and -takers. I think the market for RM services in my proposal is more competitive (and therefore has lower fees) than regular, centralized exchanges, because: * trust requirements are lower, so people are more likely to trust a small, unknown company offering RM services. People using smaller parties = more parties in the market = lower fees. * OMs can easily offer the same funds for use with different RM parties. This is not possible with regular exchanges(**): if you deposit funds on one exchange, you can't also deposit them on another exchange, so you have to commit your funds to a single exchange. Finally, I think the attack RMs can perform on trading parties is an order of magnitude smaller than the attack a regular exchange can perform by stealing deposited funds: a RM can only steal the *exchange rate change* of funds offered for trade, not the full value. Now, if an RM can be punished, it would be even better. I was thinking in the direction of collecting proof of misbehavior, which can then help make the RM lose its (lucrative!) business, but I doubt this is possible. CJP (*) not necessarily in latency: the low latency of centralized exchanges can be hard to match, even on Lightning. (**) as long as you can't go short ___ 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
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 timespan within which the market maker can not back out, and in your language writes a free option. That timespan might be very short on an electronic trading platform or rather long in trade finance. Bid-ask spreads of the offer reflect that and those making the offers manage or at least limit the market and liquidity risk of outstanding offers. Just because there is no trustless automated solution in sight, we should not assume things will not exist. In contrary, this imperfection will invite people offering a service for profit. Tamas Blummer > On Dec 28, 2018, at 22:22, Tamas Blummer wrote: > > 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, > therefore you imply that no sane person would make such an offer. > > I think, that instead exchanges will still make such offers but with an > exchange rate between the assets that compensate them for the cost they > incure by making the offer. > Exchanges will also limit the quantity of outstanding offers, so they can > manage the risk of options written. This might lead to making offers only to > known traders or to those, > who pay for receiving an offer with a regular LN payment in-advance. > > Tamas Blummer > > > >> On Dec 28, 2018, at 04:34, ZmnSCPxj wrote: >> >> 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-ask spread, that of the >>> option premium. >> >> The option premium cannot be charged in the not-exercised branch. >> This is effectively a premium-free option. >> This means that rational entities who know of this technique will create >> options "for free" until the exchange runs out of liquidity. >> This is because, even if the exchange rate does not go beyond the bid-ask >> spread, the not-exercised branch is free of charge. >> >> Since all their liquidity is tied up in premium-free American Call Options, >> exchange nodes cannot usefully bridge between a BTC Lightning Network and >> any other asset. >> Routing attempts will usually fail. >> In a very practical sense, it would not be possible to create a multi-asset >> LN. >> >> >> -- >> >> I had long ago figured out that HTLCs can create American Call Options (more >> than a year ago). >> The problem was that they tied up the assets involved into the contract, so >> I never bothered to publish this insight. >> However, on LN, HTLCs are created "for free" with no payment, which is a >> significant advantage to the user of an American Call Option, who would be >> quite willing to tie up their funds in HTLCs since the not-exercised branch >> of the American Call Option formed was free of premium. >> Their only cost is opportunity cost, and on the LN, with tiny tiny tiny >> fees, opportunity cost of having the funds free is very small. >> One can say that the opportunity cost is the premium paid, but note that it >> is not paid to the exchange, since the exchange itself is also forced to tie >> up its other asset into another HTLC (meaning it also pays the opportunity >> cost). >> >> What I suspect will happen is that the LN on the weaker asset (i.e. less >> popular, fewer users, etc.) will find itself unable to be paid by the LN on >> the stronger asset. >> This will weaken the weaker asset even further (users will leave it for the >> stronger asset). >> This creates a shift in exchange rate, which is precisely what the American >> Call Options are waiting for. >> These American Call Options drain funds from the exchange, until the >> exchange stops being profitable and stops operating as an exchange, again >> further weakening the weaker asset as it is now even harder to pay from the >> stronger asset network to the weaker asset network, and so on. >> >> >> Regards, >> ZmnSCPxj > ___ 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
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, therefore you imply that no sane person would make such an offer. I think, that instead exchanges will still make such offers but with an exchange rate between the assets that compensate them for the cost they incure by making the offer. Exchanges will also limit the quantity of outstanding offers, so they can manage the risk of options written. This might lead to making offers only to known traders or to those, who pay for receiving an offer with a regular LN payment in-advance. Tamas Blummer > On Dec 28, 2018, at 04:34, ZmnSCPxj wrote: > > 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-ask spread, that of the >> option premium. > > The option premium cannot be charged in the not-exercised branch. > This is effectively a premium-free option. > This means that rational entities who know of this technique will create > options "for free" until the exchange runs out of liquidity. > This is because, even if the exchange rate does not go beyond the bid-ask > spread, the not-exercised branch is free of charge. > > Since all their liquidity is tied up in premium-free American Call Options, > exchange nodes cannot usefully bridge between a BTC Lightning Network and any > other asset. > Routing attempts will usually fail. > In a very practical sense, it would not be possible to create a multi-asset > LN. > > > -- > > I had long ago figured out that HTLCs can create American Call Options (more > than a year ago). > The problem was that they tied up the assets involved into the contract, so I > never bothered to publish this insight. > However, on LN, HTLCs are created "for free" with no payment, which is a > significant advantage to the user of an American Call Option, who would be > quite willing to tie up their funds in HTLCs since the not-exercised branch > of the American Call Option formed was free of premium. > Their only cost is opportunity cost, and on the LN, with tiny tiny tiny fees, > opportunity cost of having the funds free is very small. > One can say that the opportunity cost is the premium paid, but note that it > is not paid to the exchange, since the exchange itself is also forced to tie > up its other asset into another HTLC (meaning it also pays the opportunity > cost). > > What I suspect will happen is that the LN on the weaker asset (i.e. less > popular, fewer users, etc.) will find itself unable to be paid by the LN on > the stronger asset. > This will weaken the weaker asset even further (users will leave it for the > stronger asset). > This creates a shift in exchange rate, which is precisely what the American > Call Options are waiting for. > These American Call Options drain funds from the exchange, until the exchange > stops being profitable and stops operating as an exchange, again further > weakening the weaker asset as it is now even harder to pay from the stronger > asset network to the weaker asset network, and so on. > > > Regards, > ZmnSCPxj signature.asc Description: Message signed with OpenPGP ___ 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
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 see trustlessness in a > very pragmatic sense anyway. Trust creates a risk, but if the > alternative trustless system is very impractical, and the risk is small > enough, the benefits might simply be worth the risks. Note that this is > a completely subjective trade-off, so it is only acceptable on an > individual, voluntary basis. Thank you very much your information! It seems to me "trust" is a five-letter word, so I am very hesitant to use it. I have only skimmed the paper thus far, so... 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-parties/ This seems to me to imply that OM (i.e. exchange nodes) will be unable to extract any sizable fee, i.e. any fees that the market would be willing to pay to exchange between assets will be taken by RM as rent, and not by the OM who actually makes the market exist in the first place. I worry this friction may be too much, so I am hesitant to support this, especially as trusted third parties have not behaved well historically, as per Szabo. However, if we can somehow make RM punishable for breaches in timing attacks, or some similar mechanism, then it may become workable. Regards, ZmnSCPxj ___ 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
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 a very pragmatic sense anyway. Trust creates a risk, but if the alternative trustless system is very impractical, and the risk is small enough, the benefits might simply be worth the risks. Note that this is a completely subjective trade-off, so it is only acceptable on an individual, voluntary basis. CJP ZmnSCPxj via Lightning-dev schreef op do 27-12-2018 om 05:43 [+]: > 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 to pay a > payee requesting for another currency. > However, a significant technical barrier prevents implementation of > such feature as of current designs (late 2018) for Lightning. > > The root cause of this significant technical barrier is the use of > hashlocked timelocked contracts to route payments. > HTLCs can be used across cryptocurrency systems to transfer value > between them. > From this point-of-view, every single Lightning Network channel is a > cryptocurrency system whose custodians are two entities, who are the > only entities who can use the system (the single Lightning Network > channel). > HTLCs allow cross-system trades to be performed, so that > participation on any single Lightning Network channel can be > leveraged to participation over the entire Lightning Network. > > However, HTLCs can also be used to construct American Call Options. > Further, due to UX concerns, on the Lightning Network, there is no > cost incurred in merely setting up HTLCs for routing. > By using the low-level HTLCs provided as primitives by Lightning > Network, one can set up American Call Options. > These on-Lightning American Call Options, however, can be "purchased" > for free (gratis), thus potentially earning money in a completely > risk-free manner. > Abusing this gratis ability means that any Lightning Network node > advertising cross-asset on-Lightning exchange will find large amounts > of its liquidity tied up in stalled forwarding payments (in reality, > American Call Options) with a risk of monetary loss in case of large > fluctuations in exchange rate. > > Hashlocked Timelocked Contracts as American Call Options > > > An American CallOption is a right (but not obligation) to purchase an > asset at a specific price, on or before an expiration date. > HTLCs allow building American Call Options. > > Suppose we have Bitcoin, and some other asset, and both are on > blockchains that support the same hash function and can define HTLCs. > It is unimportant if both are on the same blockchain, or on different > blockchains, since HTLCs can work across cryptocurrency systems. > > An American Call Option has these properties: > > 1. `P` = the price at which the asset can be purchased. > 2. `E` = the date at which the option expires. > > Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for > 1 Widget (WJT) on the WJT blockchain. > We would then do the below ritual: > > 1. You provide me a hash of some secret preimage that only you know. > 2. You make an HTLC on the Bitcoin blockchain. > The value of this HTLC is `P`, the hash is the hash you gave > above, and the timelock is `E` + 1 day. > 3. I make an HTLC on the WJT blockchain. > The value of this HTLC is 1, the hash is the hash you gave, and > the timelock is `E`. > > On or before `E`, you can claim the WJT on the WJT blockchain by > providing a transaction that reveals the preimage. > Since the preimage is now revealed, I can then claim the Bitcoins of > price `P` on the Bitcoin blockchain. > Alternately, you can simply not exercise this right, and at time `E` > I would then reclaim my WJT, and at time `E` + 1 day you would > reclaim your bitcoins. > > Of course, I want to *sell* this contract to you, so you would have > to pay me some bitcoins before we set up the above. > A multi-stage construction of transactions that go through HTLC-like > constructs can be done on both blockchains to ensure that the above > contracts appear on both chains only if the payment for the actual > contract (i.e. the "premium") is done, and to enforce that both > contracts appear if the premium is paid, but that is beyond the scope > of *this* writeup, which will focus on how Lightning Network HTLCs > can form the above construction without any premium being paid. > > HTLCs For Routing > = > > HTLCs can be used to enforce trades across different cryptocurrency > systems. > This property
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 some other node, for the same amount. Suppose there are two nodes on the LN who provide a BTC/WJT exchange. Now suppose one of those nodes is selected as an intermediate hop node for somebody paying using BTC somebody who wants WJT. That node uses the other node to construct an American Call Option to construct a straddle. The other node, in response, uses the first node to construct a straddle. The first node, now being short a straddle, uses the other node to construct an American Call Option to construct a straddle. This goes on until both nodes now have all their liquidity locked up in hedges. If the payment that originally started this whole monstrosity turns out to be an American Call Option in the first place, then neither exchange node will be willing to "disarm" any of their hedges. The liquidity of the exchange nodes is tied up and nobody can make any BTC->WJT and WJT->BTC exchanges on Lightning. In short, this simply attempts to make it a problem of somebody else, not solve the problem. Regards, ZmnSCPxj ___ 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
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 "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 solutio n, but I haven't seen the idea mentioned before. The issue is that it is impossible for the exchange node to determine if it is talking to one other entity, or several distinct self-interested entities. If you and YAIjbOJO were distinct entities, then this issue would not happen. Because of Onion routing and the use of pseudonymous public keys, ZmnSCPxj cannot determine if you and YAIjbOJO are different entities. Thus, your proposal must work both in the case where there is multiple hop nodes, and in the case where you and YAIjbOJO are the same entity actually. So let us consider the case where you are using BTC to pay a node, randomly named bQqZrrEM, 1.0 WJT. You have found the below route: you ->BTC-> ZmnSCPxj ->WJT-> YAIjbOJO ->WJT-> bQqZrrEM Because ZmnSCPxj is an exchange node, ZmnSCPxj demands a timed commitment so that the payment pushes through. Now suppose that the following sequence of events occurs. 1. Zeus has an affair. 2. bQqZrrEM generates a random preimage and provides the hash to you. 3. In the domestic argument after Hera finds out about the affair, Zeus randomly throws a lightning bolt that by chance hits and destroys bQqZrrEM. 4. You initiate payment starting with ZmnSCPxj. What happens then? If the payment does not push through, then you could instead do: 1. you/YAIjbOJO/bQqZrrEM (really the same entity) generate a preimage and its hash. 2. You delete the bQqZrrEM identity. 3. You inititate payment starting with ZmnSCPxj This still lets you make an American Call Option by suddenly "reviving" the bQqZrrEM identity later in the "exercise" branch, or deciding to not revive the bQqZrrEM identity in the "not exercise" branch. On the other hand, if the payment pushes through regardless of whether or not bQqZrrEm survives, then in the world where bQqZrrEm dies of stray lover quarrel lightning bolt, YAIjbOJO gets paid and I get the money from you, and you are sad because you paid for something you will never get. > If this magical atomic information swap could happen (I don't get the final > HTLC unless I reveal the preimage) What mechanism creates this? If this mechanism involves timelocks also, then what prevents the same American Call Option from being created using the timelock of this magic mechanism? The timelocks could be shorter, but it is still the same riskless free-of-premium American Call Option, so rational entities will continuosly spam exchange nodes with such attempts even if the timelock is short. Does this mechanism require that the exchange know who the final destination will be? What happens if while negotiating this information, one of the intermediate nodes drops? If we disallow intermediate nodes, then I know who the final destination will be (it will be the next hop) and I can then exercise my newfound right to censor transactions. Regards, ZmnSCPxj ___ 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
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] An Argument For Single-Asset Lightning Network
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 amount. This obviously can't scale to all participants, but can possibly provide a hedge for a single node. On Thu, Dec 27, 2018 at 1:33 PM Tamas Blummer wrote: > 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 financial disaster. > > This is not an issue for same asset exchange, as in payment routing, since > the exchange remains fair at any later time point. > > 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-ask spread, that of the > option premium. > > Tamas Blummer > > > > On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > > > 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 to pay a payee > requesting for another currency. > > However, a significant technical barrier prevents implementation of such > feature as of current designs (late 2018) for Lightning. > > > > The root cause of this significant technical barrier is the use of > hashlocked timelocked contracts to route payments. > > HTLCs can be used across cryptocurrency systems to transfer value > between them. > > From this point-of-view, every single Lightning Network channel is a > cryptocurrency system whose custodians are two entities, who are the only > entities who can use the system (the single Lightning Network channel). > > HTLCs allow cross-system trades to be performed, so that participation > on any single Lightning Network channel can be leveraged to participation > over the entire Lightning Network. > > > > However, HTLCs can also be used to construct American Call Options. > > Further, due to UX concerns, on the Lightning Network, there is no cost > incurred in merely setting up HTLCs for routing. > > By using the low-level HTLCs provided as primitives by Lightning > Network, one can set up American Call Options. > > These on-Lightning American Call Options, however, can be "purchased" > for free (gratis), thus potentially earning money in a completely risk-free > manner. > > Abusing this gratis ability means that any Lightning Network node > advertising cross-asset on-Lightning exchange will find large amounts of > its liquidity tied up in stalled forwarding payments (in reality, American > Call Options) with a risk of monetary loss in case of large fluctuations in > exchange rate. > > > > Hashlocked Timelocked Contracts as American Call Options > > > > > > An American CallOption is a right (but not obligation) to purchase an > asset at a specific price, on or before an expiration date. > > HTLCs allow building American Call Options. > > > > Suppose we have Bitcoin, and some other asset, and both are on > blockchains that support the same hash function and can define HTLCs. > > It is unimportant if both are on the same blockchain, or on different > blockchains, since HTLCs can work across cryptocurrency systems. > > > > An American Call Option has these properties: > > > > 1. `P` = the price at which the asset can be purchased. > > 2. `E` = the date at which the option expires. > > > > Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 > Widget (WJT) on the WJT blockchain. > > We would then do the below ritual: > > > > 1. You provide me a hash of some secret preimage that only you know. > > 2. You make an HTLC on the Bitcoin blockchain. > >The value of this HTLC is `P`, the hash is the hash you gave above, > and the timelock is `E` + 1 day. > > 3. I make an HTLC on the WJT blockchain. > >The value of this HTLC is 1, the hash is the hash you gave, and the > timelock is `E`. > > > > On or before `E`, you can claim the WJT on the WJT blockchain by > providing a transaction that reveals the preimage. > > Since the preimage is now revealed, I can then claim the Bitcoins of > price `P` on the Bitcoin blockchain. > > Alternately, you can simply not exercise this right, and at time `E` I > would then reclaim my WJT, and at time `E` + 1 day you would reclaim
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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 financial disaster. This is not an issue for same asset exchange, as in payment routing, since the exchange remains fair at any later time point. 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-ask spread, that of the option premium. Tamas Blummer > On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev > wrote: > > 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 to pay a payee > requesting for another currency. > However, a significant technical barrier prevents implementation of such > feature as of current designs (late 2018) for Lightning. > > The root cause of this significant technical barrier is the use of hashlocked > timelocked contracts to route payments. > HTLCs can be used across cryptocurrency systems to transfer value between > them. > From this point-of-view, every single Lightning Network channel is a > cryptocurrency system whose custodians are two entities, who are the only > entities who can use the system (the single Lightning Network channel). > HTLCs allow cross-system trades to be performed, so that participation on any > single Lightning Network channel can be leveraged to participation over the > entire Lightning Network. > > However, HTLCs can also be used to construct American Call Options. > Further, due to UX concerns, on the Lightning Network, there is no cost > incurred in merely setting up HTLCs for routing. > By using the low-level HTLCs provided as primitives by Lightning Network, one > can set up American Call Options. > These on-Lightning American Call Options, however, can be "purchased" for > free (gratis), thus potentially earning money in a completely risk-free > manner. > Abusing this gratis ability means that any Lightning Network node advertising > cross-asset on-Lightning exchange will find large amounts of its liquidity > tied up in stalled forwarding payments (in reality, American Call Options) > with a risk of monetary loss in case of large fluctuations in exchange rate. > > Hashlocked Timelocked Contracts as American Call Options > > > An American CallOption is a right (but not obligation) to purchase an asset > at a specific price, on or before an expiration date. > HTLCs allow building American Call Options. > > Suppose we have Bitcoin, and some other asset, and both are on blockchains > that support the same hash function and can define HTLCs. > It is unimportant if both are on the same blockchain, or on different > blockchains, since HTLCs can work across cryptocurrency systems. > > An American Call Option has these properties: > > 1. `P` = the price at which the asset can be purchased. > 2. `E` = the date at which the option expires. > > Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 Widget > (WJT) on the WJT blockchain. > We would then do the below ritual: > > 1. You provide me a hash of some secret preimage that only you know. > 2. You make an HTLC on the Bitcoin blockchain. >The value of this HTLC is `P`, the hash is the hash you gave above, and > the timelock is `E` + 1 day. > 3. I make an HTLC on the WJT blockchain. >The value of this HTLC is 1, the hash is the hash you gave, and the > timelock is `E`. > > On or before `E`, you can claim the WJT on the WJT blockchain by providing a > transaction that reveals the preimage. > Since the preimage is now revealed, I can then claim the Bitcoins of price > `P` on the Bitcoin blockchain. > Alternately, you can simply not exercise this right, and at time `E` I would > then reclaim my WJT, and at time `E` + 1 day you would reclaim your bitcoins. > > Of course, I want to *sell* this contract to you, so you would have to pay me > some bitcoins before we set up the above. > A multi-stage construction of transactions that go through HTLC-like > constructs can be done on both blockchains to ensure that the above contracts > appear on both chains only if the payment for the actual contract (i.e. the > "premium") is done, and to enforce that both contracts appear if the premium > is paid, but that is beyond the scope of *this* writeup, which will focus on > how Lightning Network HTLCs can form the above
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
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] An Argument For Single-Asset Lightning Network
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
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
