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] Quick analysis of channel_update data
On Fri, 4 Jan 2019 at 04:43, ZmnSCPxj wrote: > > - in set reconciliation schemes: we could reconcile [channel id | > > timestamp | checksum] first > > Perhaps I misunderstand how set reconciliation works, but --- if timestamp is > changed while checksum is not, then it would still be seen as a set > difference and still require further communication rounds to discover that > the channel parameters have not actually changed. > > Perhaps it is better to reconcile [channel_id | checksum] instead, and if > there is a different set of channel parameters, share the set difference and > sort out which timestamp is later at that point. Ah yes of course, the `timestamp` should not be included. Cheers, Fabrice ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
