Re: [Lightning-dev] Quick analysis of channel_update data
Good morning, > - 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. 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
Follow-up: here's more detailed info on the data I collected and potential savings we could achieve: I made hourly routing table backups for 12 days, and collected routing information for 17 000 channel ids. There are 130 000 different channel updates :on average each channel has been updated 8 times. Here, “different” means that at least the timestamp has changed, and a node would have queried this channel update during its syncing process. But only 18 000 pairs of channel updates carry actual fee and/or HTLC value change. 85% of the time, we just queried information that we already had! Adding a basic checksum (4 bytes for example) that covers fees and HTLC min/max value to our channel range queries would be a significant improvement and I will add this the open BOLT 1.1 proposal to extend queries with timestamps. I also think that such a checksum could also be used - in “inventory” based gossip messages - in set reconciliation schemes: we could reconcile [channel id | timestamp | checksum] first Cheers, Fabrice ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reuse of payment_hash in lightning invoices
Okay so the knowledge of a preimage for a certain payment_hash is the sufficient (and only) payment proof for the payer. But in any case the reuse of payment_hashes should be strongly discouraged, in the donations scenario 2 donors will send across the network a payment for the same preimage and if the routes overlap (as it's likely to happen getting close to the recipient) an intermediate routing node can effectively steal the payment from the recipient. Shouldn't we make this clear in BOLT11? Cheers, Andrea. On Thu, 3 Jan 2019 at 14:13, ZmnSCPxj wrote: > Good morning Andrea, > > > For example a malicious receiver can provide an invoice with assisted > routes where among those he/she controls a node and that node won't forward > to the htlc but steal the funds instead (the preimage is known to the > intermediate node as well), thus it will be claimed that the payment hasn't > been received. If the above is correct then there should be at least a > warning in the spec regarding the reuse of payment_hash in invoices. > > The fact that ultimate payer has received the payment preimage is > considered sufficient proof of payment. > Thus, in case of reuse, the fact that the ultimate payer has received the > payment preimage is sufficient proof of payment, and whatever the receiver > claims is to be ignored: the payment preimage in possession of the ultimate > payee is considered the whole of the proof of payment. > > > >a malicious receiver can provide an invoice with assisted routes where > among those he/she controls a node and that node won't forward to the htlc > but steal the funds instead > > Then the receiver has received it, not on the purported final node, but on > another node it controls, and the fact that the ultimate payer has received > the payment preimage is sufficient proof of that. > > Obviously, if the receiver knows it does not control the entire Lightning > Network, it should not reuse payment hashes, since intermediate nodes it > does not control could claim the payment and give the proof-of-payment to > the ultimate payer. > This can be clarified, but in the context of proofs, the attack you > described is not possible, since the possession of the payment preimage is > itself the entirety of the proof of the payment, regardless of what the > receiver claims. > > 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] Reuse of payment_hash in lightning invoices
Good morning Andrea, > For example a malicious receiver can provide an invoice with assisted routes > where among those he/she controls a node and that node won't forward to the > htlc but steal the funds instead (the preimage is known to the intermediate > node as well), thus it will be claimed that the payment hasn't been received. > If the above is correct then there should be at least a warning in the spec > regarding the reuse of payment_hash in invoices. The fact that ultimate payer has received the payment preimage is considered sufficient proof of payment. Thus, in case of reuse, the fact that the ultimate payer has received the payment preimage is sufficient proof of payment, and whatever the receiver claims is to be ignored: the payment preimage in possession of the ultimate payee is considered the whole of the proof of payment. >a malicious receiver can provide an invoice with assisted routes where among >those he/she controls a node and that node won't forward to the htlc but steal >the funds instead Then the receiver has received it, not on the purported final node, but on another node it controls, and the fact that the ultimate payer has received the payment preimage is sufficient proof of that. Obviously, if the receiver knows it does not control the entire Lightning Network, it should not reuse payment hashes, since intermediate nodes it does not control could claim the payment and give the proof-of-payment to the ultimate payer. This can be clarified, but in the context of proofs, the attack you described is not possible, since the possession of the payment preimage is itself the entirety of the proof of the payment, regardless of what the receiver claims. 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 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
[Lightning-dev] Reuse of payment_hash in lightning invoices
Good morning list, I wanted to know your thoughts about the reuse of payment_hash in lightning invoices, currently BOLT11 uses as example a donation invoice which seems to be "permanent" i.e the payment_hash isn't changing after having received a donation.I believe the reuse of known payment_hash is a security issue because an intermediary node routing a donation for the second time already knows the preimage, thus it can decide to pull the htlc from downstream without actually forwarding it to upstream (can respond with a htlc_fulfill). For example a malicious receiver can provide an invoice with assisted routes where among those he/she controls a node and that node won't forward to the htlc but steal the funds instead (the preimage is known to the intermediate node as well), thus it will be claimed that the payment hasn't been received. If the above is correct then there should be at least a warning in the spec regarding the reuse of payment_hash in invoices. Cheers, Andrea. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] An Argument For Single-Asset Lightning Network
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
