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] Quick analysis of channel_update data
Hi Fabrice, happy new year to you too :-) Thanks for taking the time to collect that information. It's very much in line with what we were expecting in that most of the updates come from flapping channels. Your second observation that some updates only change the timestamp is likely due to the staggered broadcast merging multiple updates, e.g., one disabling and one enabling the channel, that are sent very close to each other. This is the very reason we introduced the staggering back in the days, as it limits the maximum rate of updates a single node may produce for each of its channels. In the second case we can probably get away with not forwarding the update, but updating the timestamp and signature for the old `channel_update` locally, so that we don't then flap back to an older one should we get that in a roundabout way. That's purely a local decision and does not warrant a spec change imho. For the ones that flap with a period that is long enough for the disabling and enabling updates being flushed, we are presented with a tradeoff. IIRC we (c-lightning) currently hold back disabling `channel_update`s until someone actually attempts to use the channel at which point we fail the HTLC and send out the stashed `channel_update` thus reducing the publicly visible flapping. For the enabling we can't do that, but we could think about a local policy on how much to delay a `channel_update` depending on the past stability of that peer. Again this is local policy and doesn't warrant a spec change. I think we should probably try out some policies related to when to send `channel_update`s and how to hide redundant updates, and then we can see which ones work best :-) Cheers, Christian Fabrice Drouin writes: > Hello All, and Happy New Year! > > To understand why there is a steady stream of channel updates, even > when fee parameters don't seem to actually change, I made hourly > backups of the routing table of one of our nodes, and compared these > routing tables to see what exactly was being modified. > > It turns out that: > - there are a lot of disable/enable/disable etc…. updates which are > just sent when a channel is disabled then enabled again (when nodes go > offline for example ?). This can happen > there are also a lot of updates that don’t change anything (just a new > timestamp and signatures but otherwise same info), up to several times > a day for the same channel id > > In both cases we end up syncing info that we already have. > I don’t know yet how best to use this when syncing routing tables, but > I thought it was worth sharing anyway. A basic checksum that does not > cover all fields, but only fees and HTLC min/max values could probably > be used to improve routing table sync ? > > Cheers, > > Fabrice > ___ > 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] Quick analysis of channel_update data
Hello All, and Happy New Year! To understand why there is a steady stream of channel updates, even when fee parameters don't seem to actually change, I made hourly backups of the routing table of one of our nodes, and compared these routing tables to see what exactly was being modified. It turns out that: - there are a lot of disable/enable/disable etc…. updates which are just sent when a channel is disabled then enabled again (when nodes go offline for example ?). This can happen there are also a lot of updates that don’t change anything (just a new timestamp and signatures but otherwise same info), up to several times a day for the same channel id In both cases we end up syncing info that we already have. I don’t know yet how best to use this when syncing routing tables, but I thought it was worth sharing anyway. A basic checksum that does not cover all fields, but only fees and HTLC min/max values could probably be used to improve routing table sync ? Cheers, Fabrice ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] visual identification of payee node id
Good morning Eugene, > > how about using of Chernoff Faces to identify node’s public key? Since humans > are best fit to recognize small changes in faces and to remember them. Why do humans have this circuitry? Such strange objects... One could wonder about sentients without such circuitry. They would not be served well by this. (Notice the use of "they" here. I am not such a sentient since I am human. Thus, the use of "they" in the above setence.) A side effect of this would be that humans would obsessively reroll their pubkey until they acquire a face they like. This will be a source of much amusement and so on. For this reason alone, I highly approve this suggestion. Regards, ZmnSCPxj > > To achieve avalanche effect from changing a private key to produce much > different face, one can just plug node’s public key into a cryptographic hash > function and then plug a result into Chernoff Face generator, thus making a > public key change very easy to notice. > > Вкл вс, дек. 23, 2018 в 21:49, Pavol Rusnak via Lightning-dev > написал(а): > > > Hi all! > > > > Currently, when I perform a payment via QR code, I usually check the > > payee node id (public key) in the send dialog. However, this is a rather > > long hex value, so for example Eclair app shows just the beginning and > > the end of the value. > > > > Idea: Can we show an identicon (for example https://jdenticon.com/) of > > payee node id (= public key) next to the QR code, so user can visually > > quickly check whether the recipient is correct? > > > > We'd need to add this to UI of all Lightning user-facing wallets to make > > sense, though. > > > > -- > > Best Regards / S pozdravom, > > > > Pavol "stick" Rusnak > > CTO, SatoshiLabs > > ___ > > 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] visual identification of payee node id
Hi, how about using of Chernoff Faces to identify node’s public key? Since humans are best fit to recognize small changes in faces and to remember them. To achieve avalanche effect from changing a private key to produce much different face, one can just plug node’s public key into a cryptographic hash function and then plug a result into Chernoff Face generator, thus making a public key change very easy to notice. Вкл вс, дек. 23, 2018 в 21:49, Pavol Rusnak via Lightning-dev написал(а): > Hi all! > > Currently, when I perform a payment via QR code, I usually check the > payee node id (public key) in the send dialog. However, this is a rather > long hex value, so for example Eclair app shows just the beginning and > the end of the value. > > Idea: Can we show an identicon (for example https://jdenticon.com/) of > payee node id (= public key) next to the QR code, so user can visually > quickly check whether the recipient is correct? > > We'd need to add this to UI of all Lightning user-facing wallets to make > sense, though. > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > CTO, SatoshiLabs > ___ > 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, > > - 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] visual identification of payee node id
Why not a confirmation phrase of a few words? This should be easier to implement and fit into a pre-existing design programme. Given a pool of enough words this would surely be as reliable as an identicon, no? Best regards, Max On 29 Dec 2018, 17:23 +0100, William Casarin , wrote: > Pavol Rusnak via Lightning-dev writes: > > > Hi all! > > > > Currently, when I perform a payment via QR code, I usually check the > > payee node id (public key) in the send dialog. However, this is a rather > > long hex value, so for example Eclair app shows just the beginning and > > the end of the value. > > > > Idea: Can we show an identicon (for example https://jdenticon.com/) of > > payee node id (= public key) next to the QR code, so user can visually > > quickly check whether the recipient is correct? > > I think it would be interesting if someone came up with a visual hashing > algorithm, where small changes in the inputs had uniformly random visual > outputs. I was testing jdenticon with my node id: > > 03f3c108ccd536b8526841f0a5c58212bb9e6584a1eb493080e7c1cc34f82dad71 > > I was surprised to see that small changes to the first digit didn't > change the visual output at all. Whether or not this is a useful > property in this use case, it's something to keep in mind. > > Cheers, > Will > > -- > https://jb55.com > ___ > 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
