From ZmnSCPxj at protonmail.com Sat Dec 8 19:13:59 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sat, 08 Dec 2018 19:13:59 +0000 Subject: [Lightning-dev] OpenCAP alias integrations with invoices/destination In-Reply-To: References: Message-ID: Good morning Lane, I believe Rusty is creating a spec for reusable payment offers, which would let payers request for BOLT11 invoices over the LN network. In addition, I believe Laolu and friends are building some spontaneous-payment protocol without proof-of-payment, although I am uncertain the details. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On Friday, December 7, 2018 9:14 PM, Lane Wagner wrote: > Im working on a protocol that allows users to host crypto public addresses, using a standard DNS lookup schema. It offers some advantages over OpenAlias and I'm hopeful that we will see actual adoption. > > I want users to be able to post lightning invoices as well, although I know this is difficult because typically invoices must be generated uniquely for each payment. I was thinking maybe posting a destination could be good, so that people can open channels with you, but then people with existing channels still couldnt send to you. > > Does anyone have thoughts on this? > > Protocol: https://GitHub.com/OpenCAP/protocol (link to discord for discussion is there) > > Implementation: https://ogdolo.com > > Open source implementation: https://GitHub.com/OpenCAP/go-server > > On Fri, Dec 7, 2018, 5:00 AM >> Send Lightning-dev mailing list submissions to >> lightning-dev at lists.linuxfoundation.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> or, via email, send a message with subject or body 'help' to >> lightning-dev-request at lists.linuxfoundation.org >> >> You can reach the person managing the list at >> lightning-dev-owner at lists.linuxfoundation.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Lightning-dev digest..." >> >> Today's Topics: >> >> 1. Re: Reason for having HMACs in Sphinx (Christian Decker) >> 2. Re: Fulgurite: ideas for making a more flexible Lightning >> Network protocol (ZmnSCPxj) >> 3. Fwd: Fulgurite: ideas for making a more flexible Lightning >> Network protocol (Trey Del Bonis) >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 06 Dec 2018 16:24:20 +0100 >> From: Christian Decker >> To: Corn? Plooy , ZmnSCPxj >> Cc: "lightning-dev at lists.linuxfoundation.org" >> >> Subject: Re: [Lightning-dev] Reason for having HMACs in Sphinx >> Message-ID: <875zw6adaz.fsf at gmail.com> >> Content-Type: text/plain; charset=utf-8 >> >> Corn? Plooy writes: >> >>>> The total_decorrelation_secrets serves as the payer-generated shared >>>> secret between payer and payee. B cannot learn this, and thus cannot >>>> fake its own secret. Even if it instead offers ((I + K[A]) + k[z] * >>>> G) for a new secret k[z], it cannot know how to change >>>> total_decorrelation_secrets from k[a] + k[b] to k[a] + k[z] instead. >>>> >>> The way things are now, the ephemeral key generation and the payment >>> hash/preimage generation are completely unrelated. This is what allows >>> an attacker to use the same payment hash, and use his own ephemeral key >>> pair to create a new onion packet around it. >> >> That is correct, one is generated by the recipient (secret and preimage) >> and the other one is generated by the sender (ephemeral key). Mixing the >> two seems very unwise, since the sender has very little control over >> what the effective ephemeral key that is going to be used for the last >> hop. This is the same issue that we have with rendez-vous routing, i.e., >> that if we require the ephemeral key to be something specific at a given >> node we'd be breaking the hardness assumption of for the ephemeral key >> rotation. >> >>> Primarily, path decorrelation replaces the payment hash/preimage part. >>> Maybe I still don't understand something, but if that's the only thing >>> (without changing the ephemeral key / onion shared secret generation), >>> attacking the direct neighbor should still work; in your case, B would >>> still offer ((I + K[A]) + K[B]) to C, with an onion packet B created >>> himself. I'm not familiar enough with the path correlation to understand >>> what happens after step 6, but for C it looks the same, so she should do >>> the same. >>> >>> >>> I do see that, if you couple the "H"TLC payment secret generation to the >>> onion shared secret generation, you can make the attack impossible. Do I >>> understand correctly that this is the idea? After all, C still needs to >>> receive k somehow; my crypto math isn't that good, but my intuitive >>> guess is that i + k is the secret that allows C to claim funds locked in >>> ((I + K[A]) + K[B]) =? (i + (k[a] + k[b])) * G. If k is submitted from A >>> to C through some mechanism that replaces the current ephemeral key >>> system, then I understand what you're at. >> >> I can't quite follow where we would be mixing in the ephemeral key here, >> could you elaborate on that? >> >>> Assuming this is the case, it's pretty neat. I do wonder how it >>> interacts with rendezvous routing. If the sender and receiver each >>> create the k[..] values for their own part of the route, can the >>> receiver-generated onion packet still use points of the form ((I + K[A]) >>> + K[B]), including K[..] values related to the sender side? I need to >>> dig deeper into this path decorrelation idea. >> >> Since we have very little control over what ephemeral key will actually >> be presented to the last hop if we have a multi-hop route, we can't >> really hide any information in the ephemeral key itself. What we could >> do is change the way the last hop generates the shared secret from it, >> i.e., have a last hop mode and a forwarding hop mode, and mix in the >> payment secret somehow, but I can't think of a good way to do that, and >> it seems contorted. Let's just have the sender prove knowledge of the >> original invoice by adding a TLV field with a shared secret from the >> invoice instead. >> >> Cheers, >> Christian >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 06 Dec 2018 23:22:57 +0000 >> From: ZmnSCPxj >> To: Trey Del Bonis >> Cc: "lightning-dev at lists.linuxfoundation.org" >> >> Subject: Re: [Lightning-dev] Fulgurite: ideas for making a more >> flexible Lightning Network protocol >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Good morning Trey, >>> One thing >>> we've talked about is if you and your counterparty want to route >>> payments through each other but also want to enter into discreet log >>> contracts, it might make sense to set up a subchannel for each purpose >>> so you don't have to re-sign for all the potential outcomes for the >>> DLCs (slow!) every time you add/remove an HTLC. Only the routing >>> (sub)channel would be announced to the routing network. >> >> Of note, the routing gossip is not trust-based. >> Instead, part of the routing gossip is the block and transaction and output on which the channel is anchored onchain. >> Nodes check if the specified txo is unspent, and matches the purported capacity of the channel. >> Once a channel outpoint is spent, nodes automatically remove it from their maps. >> >> In a world with Burchert-Decker-Wattenhofer factories, the factory would have an onchain txo. >> Gossip would contain all the channels in the factory, and would be signed by the same signatories as the onchain txo. >> Nodes would check that the channels purported to be contained in the factory sum up to the value of this txo. >> >> I suppose that could be relaxed, so that the channels purported to be in the factory would sum up to less than or equal to the value of the channel factory txo instead. >> This would allow a Fulgurite system to allocate only part of its funds to Lightning-visible routing nodes. >> >> It strikes me that the issue of re-signing the DLC subcontracts could be avoided if you use `SIGHASH_NOINPUT`. >> The same signatories could be used for the DLCs, and even if the update transaction changes, you can reanchor the DLC subcontracts with `SIGHASH_NOINPUT`. >> >>> > Code speaks louder than words. >>> >>> Of course. :) >> >> Yes, so feel free to ignore whatever I say, since I have not coded for a while. >> >>> > CSV requirements are a time-based requirement that affect the behavior of absolute timelocks used by HTLCs. >>> > It is better to admit this earlier than later, since it becomes possible as an attack point if you do not take care to pay attention to the CSV requirement. >>> > In particular, timelocked contracts need to be published onchain before the timeout expires, and a N-block CSV requirement then means you have to publish onchain N+1 blocks before the absolute timelock expires. >>> >>> Restrictions regarding when to publish could be managed at a higher >>> level. What Fulgurite is trying to solve is how to manage the state >>> negotiation rather than the high-level logic about when exactly to >>> publish commitment txs. Maybe we should slightly alter the mechanics >>> for how HTLC expiry works in-channel vs on-chain for this problem? >> >> At minimum the lower-level system would have to alert the higher-level system that a time-sensitive contract needs to collapse the Fulgrite system or else it would not be possible to enforce the timelock. >> >> Since contracts inside a multiparticipant updatable system can be cancelled by the agreement of all participants, I suppose the higher layer can decide to demand an update that the timelock be followed within the multiparticipant updatable system. >> But the upper layer needs to be informed of the latest time that the contract can be enforced onchain. >> Your alternative is that the upper layer needs to know whether the lower layer is using Poon-Dryja (no CSV requirement) or Decker-Wattenhofer (CSV requirement) or Decker-Russell-Osuntokun (CSV requirement), which you can argue is a layering violation. >> Further the exact specs (how many blocks do all participants agree is reasonable for the CSV requirement?) would vary. >> >> So it seems to me better to move time-sensitivity to Fulgurite than to higher layers. >> Higher layers can simply be concerned about what contracts it wants to enter into. >> The higher layer informs the Fulgurite layer of the shortest absolute timelock in each contract it enters into. >> The Fulgurite layer then returns to the higher layer the latest blockheight at which it can still safely collapse the Fulgurite system, or an error that the absolute timelock is too near and is already not enforceable at the Fulgurite layer. >> >> Regards, >> ZmnSCPxj >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 6 Dec 2018 20:41:30 -0500 >> From: Trey Del Bonis >> To: lightning-dev at lists.linuxfoundation.org >> Subject: [Lightning-dev] Fwd: Fulgurite: ideas for making a more >> flexible Lightning Network protocol >> Message-ID: >> >> Content-Type: text/plain; charset="UTF-8" >> >> (Resubmitted because it was accidentally auto-discarded.) >> >> Hello list and ZmnSCPxj, >> >>>Non-participants cannot safely (non-custodially) use any such "shared-ownership update system" and any subsystems within it since they have no power to refuse to sign off an invalid state transition. >> >> I'm not trying to solve that problem. Although I don't foresee it >> being difficult to allow participants to cooperatively join channels >> in a procedure like a splice, the output would be to a (n+1)-of-(n+1) >> multisig address (or alternatively, -1 for leaving channels). >> >>>*However*, I wonder if Fulgurite adds more complexity than necessary. >> >> I believe that the step up in complexity is justified given the change >> in how we express information in channels. >> >>>2-party shared-ownership update systems ("channels") are best, since everyone has to sign. Fewer participants means fewer points of failure. Larger participant sets mean it is more likely somebody will be absent when any one of them wants to update the shared-ownership update system. >> >> You're right. The point of bringing multiparty channels into this >> discussion was to say "here's how we'd do it in Fulgurite if somebody >> wanted to", it just requires a lot more coordination that not every >> environment would be able to have. Points of failure, etc. >> >>>Burchert-Decker-Wattenhofer channel factories have the advantage that once the channels within the factory have been set up, participants can then be absent, and only their channels are affected. >> >> That's true. My construction should still be able to do >> Burchert-Decker-Wattenhofer exactly as described with a little work >> using the same primitives, although I haven't gone out of my way yet >> to formulate how to do it yet since it's a little auxiliary to what >> we've been wanting to do with subchannels here at the DCI. One thing >> we've talked about is if you and your counterparty want to route >> payments through each other but also want to enter into discreet log >> contracts, it might make sense to set up a subchannel for each purpose >> so you don't have to re-sign for all the potential outcomes for the >> DLCs (slow!) every time you add/remove an HTLC. Only the routing >> (sub)channel would be announced to the routing network. >> >>>Code speaks louder than words. >> >> Of course. :) >> >>>CSV requirements are a time-based requirement that affect the behavior of absolute timelocks used by HTLCs. >>>It is better to admit this earlier than later, since it becomes possible as an attack point if you do not take care to pay attention to the CSV requirement. >>>In particular, timelocked contracts need to be published onchain before the timeout expires, and a N-block CSV requirement then means you have to publish onchain N+1 blocks *before* the absolute timelock expires. >> >> Restrictions regarding when to publish could be managed at a higher >> level. What Fulgurite is trying to solve is how to manage the state >> negotiation rather than the high-level logic about when exactly to >> publish commitment txs. Maybe we should slightly alter the mechanics >> for how HTLC expiry works in-channel vs on-chain for this problem? >> >> I'll admit that there's still a few unknowns that I have yet to think >> about and figure out how to deal with, like this. But it's my >> intuition that there's probably a simple solution just by making sure >> the right checks happen in the right places. >> >> - Trey Del Bonis >> >> On Thu, Dec 6, 2018 at 6:20 AM ZmnSCPxj wrote: >>> >>> Good morning list, and also Trey, >>> >>> I confirmed that Trey accidentally replied only to me, but intended to reply to the list. >>> >>> > > Burchert-Decker-Wattenhofer channel factories are essentially multiparty (> 2 participants) "channels" ("offchain updateable cryptocurrency systems") with multiple "child" 2-party channels. In general though having multiple channels between the same 2 participants is not as valuable (which is why Burchert-Decker-Wattenhofer only has two levels in the hierarchy, and why the parent level is multiparty while the child level is 2-party). >>> > >>> > Where I was going with the paper is to figure out some of the details >>> > surrounding how to actually implement the protocols described by the >>> > more formal reasearch in the area and leave space in the design for >>> > other protocols that have yet to be designed to be implemented without >>> > having to do a large overhaul of the protocol. If we want to go and >>> > do Burchert-Decker-Wattenhofer-style channel factories we just have to >>> > describe it in terms of manipulating the Fulgurite state graph, >>> > without everyone in the channel actually having to understand >>> > Burchert-Decker-Wattenhofer. Note that Fulgurite subchannels are >>> > expected to have only a subset of the participants of their parents. >>> >>> In effect, Fulgurite simply generalizes Lightning shared-ownership update systems ("channels"). >>> The insight effectively is that: >>> >>> 1. Any contract of interest to participants of a single "shared-ownership update system" can be done, as long as the contract is enforceable onchain. >>> 2. The "shared-ownership update system" itself is a contract that is enforceable onchain. >>> 3. Therefore, a "shared-ownership update system" can contain "shared-ownership update systems" of interest to its participants. >>> >>> So "subsystems" here can have the same set of participants, or a subset of participants. >>> Non-participants cannot safely (non-custodially) use any such "shared-ownership update system" and any subsystems within it since they have no power to refuse to sign off an invalid state transition. >>> >>> *However*, I wonder if Fulgurite adds more complexity than necessary. >>> >>> 2-party shared-ownership update systems ("channels") are best, since everyone has to sign. Fewer participants means fewer points of failure. Larger participant sets mean it is more likely somebody will be absent when any one of them wants to update the shared-ownership update system. >>> >>> Burchert-Decker-Wattenhofer channel factories have the advantage that once the channels within the factory have been set up, participants can then be absent, and only their channels are affected. >>> >>> >>> > > Of note is that the existing update protocols can carry almost any Bitcoin-enforceable contract, including the same contracts used to enforce them. This is what allows update protocols to "nest" as in Burchert-Decker-Wattenhofer (or your concept of "parent" and "child" channels). >>> > >>> > Of course. But unless I'm mistaken I haven't seen any practical >>> > implentations of it yet, which is what I'm attempting to do. I know I >>> > won't get much adoption without BOLT support, but that's not a goal in >>> > the short term at least. >>> >>> Code speaks louder than words. >>> >>> > > There are some important details like the fact that Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on their transported contracts, and most contracts cannot be transported across systems (HTLCs can but with longer timelocks for each step). >>> > >>> > Building transactions might not be able to be 100% transparent to the >>> > partition behavior, but I don't really think that's a major >>> > restriction we need to worry about right now. Partitions talk about >>> > their on-chain representation at a relatively high level (see the >>> > `Contract` enum in the `core` crate) and the transaction builder (yet >>> > to be written) figures out how to implement that. >>> >>> I believe it *is* important to worry about it right now. >>> The only objection I have to Decker-Russell-Osuntokun is that it adds an additional CSV requirement to transported contracts. >>> Otherwise it is strictly superior to Poon-Dryja. >>> CSV requirements are a time-based requirement that affect the behavior of absolute timelocks used by HTLCs. >>> It is better to admit this earlier than later, since it becomes possible as an attack point if you do not take care to pay attention to the CSV requirement. >>> In particular, timelocked contracts need to be published onchain before the timeout expires, and a N-block CSV requirement then means you have to publish onchain N+1 blocks *before* the absolute timelock expires. >>> >>> Basically: >>> >>> 1. Any absolute timelocked contract implies a timeout for the lifetime of the Fulgurite system/channel it is in. >>> 2. The contract must be fulfilled via a non-timelocked branch before that lifetime. >>> 3. If not fulfilled via a non-timelocked branch, the Fulgurite system must collapse onchain 1 block before the lifetime. >>> 4. If the Fulgurite system is based on Decker-Wattenhofer or Decker-Russell-Osuntokun, it must collapse onchain N+1 blocks before the lifetime, where N is the CSV timeout for the update system used. >>> >>> >>> >>> Regards, >>> ZmnSCPxj >>> >> >> ------------------------------ >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> End of Lightning-dev Digest, Vol 40, Issue 8 >> ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: